From report at bugs.python.org  Fri Feb  1 01:17:29 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Feb 2013 00:17:29 +0000
Subject: [issue17093] Make importlib.abc more inheritance-friendly
In-Reply-To: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za>
Message-ID: <1359677849.01.0.37630534965.issue17093@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Feb  1 01:21:22 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Feb 2013 00:21:22 +0000
Subject: [issue13590] extension module builds fail with python.org OS X
	installers on OS X 10.7 and 10.6 with Xcode 4.2
In-Reply-To: <1323724978.51.0.015987933964.issue13590@psf.upfronthosting.co.za>
Message-ID: <1359678082.93.0.722893777412.issue13590@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From report at bugs.python.org  Fri Feb  1 02:23:39 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Feb 2013 01:23:39 +0000
Subject: [issue13592] repr(regex) doesn't include actual regex
In-Reply-To: <1323772944.14.0.269599775604.issue13592@psf.upfronthosting.co.za>
Message-ID: <1359681819.44.0.440494344998.issue13592@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

See also issue 17087 which is essentially the same issue but for match objects.

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Fri Feb  1 02:45:25 2013
From: report at bugs.python.org (Thomas Grainger)
Date: Fri, 01 Feb 2013 01:45:25 +0000
Subject: [issue17096] the system keyring should be used instead of ~/.pypirc
Message-ID: <1359683125.78.0.593949491252.issue17096@psf.upfronthosting.co.za>


New submission from Thomas Grainger:

Having the password stored in a plain-text configuration file is not great security.

A better choice would be to try to use the OS keyring and then fall back to a plaintext file

An example implementation of a generic keyring python interface is available at: http://pypi.python.org/pypi/keyring/

----------
assignee: eric.araujo
components: Distutils2
messages: 181052
nosy: alexis, eric.araujo, graingert, tarek
priority: normal
severity: normal
status: open
title: the system keyring should be used instead of ~/.pypirc
type: security

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

From report at bugs.python.org  Fri Feb  1 03:23:48 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Feb 2013 02:23:48 +0000
Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za>
Message-ID: <1359685428.64.0.674539668025.issue16809@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Fri Feb  1 03:24:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 02:24:14 +0000
Subject: [issue17080] A better error message for float()
In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za>
Message-ID: <1359685454.59.0.226062222823.issue17080@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Attached a new patch with tests.  I added the quotes around the type and fixed complex() too.

----------
Added file: http://bugs.python.org/file28929/issue17080-2.diff

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

From report at bugs.python.org  Fri Feb  1 03:36:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 02:36:43 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359686203.09.0.586667599452.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

If there are no comments I'll commit this during the weekend.

----------

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

From report at bugs.python.org  Fri Feb  1 03:59:46 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 Feb 2013 02:59:46 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359687586.51.0.676916148628.issue6972@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

the patch looks good, thanks!  one minor comment in a test but i'll take care of that as i submit.

----------

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

From report at bugs.python.org  Fri Feb  1 04:02:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 03:02:31 +0000
Subject: [issue17040] Document context manager support for shelf objects
In-Reply-To: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za>
Message-ID: <3Yy35L1RmfzQ12@mail.python.org>


Roundup Robot added the comment:

New changeset 935a286b8066 by Ezio Melotti in branch 'default':
#17040: document that shelve.open() and the Shelf object can be used as context managers.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/935a286b8066

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  1 04:04:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:04:29 +0000
Subject: [issue17040] Document context manager support for shelf objects
In-Reply-To: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za>
Message-ID: <1359687869.7.0.714356224156.issue17040@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Fri Feb  1 04:12:15 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Feb 2013 03:12:15 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359688335.59.0.495524855361.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I would like to request again that these changes be proposed and committed in smaller chunks.

I have comments of a basic nature that would be much easier to discuss and address in the context of smaller patches.  Otherwise, the discussion isn't manageable because too much is up in the air at once.  I was waiting for smaller patches before raising these comments.  Also, some of my suggestions above weren't addressed.

----------

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

From report at bugs.python.org  Fri Feb  1 04:15:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:15:30 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359688530.71.0.984506526848.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

On the repo I created (https://bitbucket.org/ezio_melotti/devguide-14468) there are separate commits that include smaller changes.  The patches attached to this issue are outdated.

----------

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

From report at bugs.python.org  Fri Feb  1 04:20:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 03:20:41 +0000
Subject: [issue16128] hashable documentation error
In-Reply-To: <1349350634.9.0.571993653286.issue16128@psf.upfronthosting.co.za>
Message-ID: <3Yy3VJ5mHCzM75@mail.python.org>


Roundup Robot added the comment:

New changeset 79a021beaf58 by Ezio Melotti in branch '2.7':
#16128: clarify that instances of user-defined classes compare equal with themselves.
http://hg.python.org/cpython/rev/79a021beaf58

New changeset e84c5cf92b6f by Ezio Melotti in branch '3.2':
#16128: clarify that instances of user-defined classes compare equal with themselves.
http://hg.python.org/cpython/rev/e84c5cf92b6f

New changeset d9255c100971 by Ezio Melotti in branch '3.3':
#16128: merge with 3.2.
http://hg.python.org/cpython/rev/d9255c100971

New changeset 1890c63f6153 by Ezio Melotti in branch 'default':
#16128: merge with 3.3.
http://hg.python.org/cpython/rev/1890c63f6153

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  1 04:21:09 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Feb 2013 03:21:09 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359688869.44.0.285456390546.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

My understanding is that the commits are all or nothing.  In other words, they all need to be reviewed before any are committed.  I would like for the patches to be reviewed and committed individually so the review process is more manageable and people can participate more easily.  As I commented above, I offered suggestions on how to do this.

----------

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

From report at bugs.python.org  Fri Feb  1 04:22:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:22:59 +0000
Subject: [issue16128] hashable documentation error
In-Reply-To: <1349350634.9.0.571993653286.issue16128@psf.upfronthosting.co.za>
Message-ID: <1359688979.47.0.43116108659.issue16128@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I addressed the first comment.  The paragraph in datamodel.html looks ok to me, so I left it unchanged.  Feel free to reopen the issue if you have a specific suggestion that could improve that section.

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  1 04:27:37 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Feb 2013 03:27:37 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359689257.82.0.126141145237.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Also, I would be happy to start that process using the work that you have done.

----------

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

From report at bugs.python.org  Fri Feb  1 04:29:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:29:22 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359689362.58.0.575140374841.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Yes, I was planning to collapse them in a single patch and push only that.  I don't think they can be further divided.  In the moment I add the paragraph about setting up the multiple repos using "hg share" the old description becomes unnecessary, the instructions needs to be updated, and the FAQs don't need to mention hg share anymore.
I made all these things in separate commits to make it easy to review, but they have to be committed together (unless you prefer to have intermediate commits that contained duplicated informations).

----------

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

From report at bugs.python.org  Fri Feb  1 04:34:05 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Feb 2013 03:34:05 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359689645.78.0.581885481488.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I see ways that the changes can be proposed and committed incrementally.  I can start proposing those.

----------

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

From report at bugs.python.org  Fri Feb  1 04:38:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:38:48 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359689928.1.0.652665116641.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm not sure what's the point though.  The repo on bitbucket provides an easy way to review individual changes, and pushing everything at once prevents history pollution (assuming you consider 8 related changesets as pollution).  That's similar to the process we follow for feature branches, except that this is trivial enough that I didn't create a branch.

----------

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

From report at bugs.python.org  Fri Feb  1 04:46:02 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 01 Feb 2013 03:46:02 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359690362.4.0.107503671296.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The point is to allow a manageable discussion to take place around points of contention while making forward commit progress along the way.  I have suggestions right now, but the current massive batch of changes makes it too unwieldy.  The incremental commits I'm proposing wouldn't be "pollutive."  Each would be forward progress towards what we want with a commit message explaining the change.

----------

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

From report at bugs.python.org  Fri Feb  1 04:59:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:59:54 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359691194.48.0.317375601725.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The point is to allow a manageable discussion to take place around 
> points of contention

That can be done as (possibly inline) comments on bitbucket on the individual commits.

> while making forward commit progress along the way.

I'm not sure how you intend to do that, but feel free to propose what you have in mind.  As I see it, there's a bunch of text written assuming that there is a single clone or multiple not shared clones, and all this needs to be replaced and updated.  You can probably extract a couple of chunks, but that won't make a difference IMHO.

> the current massive batch of changes makes it too unwieldy.

Maybe you are overestimating it.  It's really not so massive: it's 8 changesets, 2 just remove stuff, other 2 just move existing content without adding/removing anything (so there's nothing much to review here).  Of the remaining 4 changesets, the first only adds 85 lines, the other 3 change about 20 lines each.

----------

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

From report at bugs.python.org  Fri Feb  1 06:09:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 05:09:46 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>
Message-ID: <1359695386.52.0.288601621305.issue13756@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Is this still an issue on 3.3/3.4?  Does the patch still work?

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

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

From report at bugs.python.org  Fri Feb  1 06:25:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 05:25:55 +0000
Subject: [issue13515] Consistent documentation practices for security concerns
	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1359696355.25.0.913950125802.issue13515@psf.upfronthosting.co.za>


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


----------
nosy: +christian.heimes
type:  -> enhancement

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

From report at bugs.python.org  Fri Feb  1 08:42:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 07:42:34 +0000
Subject: [issue9445] Fix undefined symbol errors on VS8.0 build
In-Reply-To: <1280627576.04.0.298775706484.issue9445@psf.upfronthosting.co.za>
Message-ID: <1359704554.19.0.428009053535.issue9445@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Is this issue still valid?

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

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

From report at bugs.python.org  Fri Feb  1 09:02:06 2013
From: report at bugs.python.org (Gabriel Nistor)
Date: Fri, 01 Feb 2013 08:02:06 +0000
Subject: [issue17022] Inline assignment uses the newly created object
In-Reply-To: <1359019855.42.0.818555984965.issue17022@psf.upfronthosting.co.za>
Message-ID: <1359705726.12.0.654944033202.issue17022@psf.upfronthosting.co.za>


Gabriel Nistor added the comment:

Thanks for the fast reply. The explanation seems valid, but the behavior is not consistent with other high level languages, and also with plain reasoning. I have a big java background experience and I am now with python for almost 3 years doing really hard core stuff, and I am still surprised by some solutions that you have adopted (like GIL for instance) and really happy about others, anyway thank you for a great language.

----------

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

From report at bugs.python.org  Fri Feb  1 10:16:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Feb 2013 09:16:41 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359710201.0.0.859882725814.issue6972@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Feel free to change the patch as you see fit.

----------

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

From report at bugs.python.org  Fri Feb  1 11:09:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Feb 2013 10:09:49 +0000
Subject: [issue17080] A better error message for float()
In-Reply-To: <1359534793.39.0.291653711097.issue17080@psf.upfronthosting.co.za>
Message-ID: <1359713389.56.0.529417109477.issue17080@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Feb  1 11:43:44 2013
From: report at bugs.python.org (lvroyce)
Date: Fri, 01 Feb 2013 10:43:44 +0000
Subject: [issue17097] baseManager serve_client() not check EINTR when recv
	request
Message-ID: <1359715424.77.0.356613938118.issue17097@psf.upfronthosting.co.za>


New submission from lvroyce:

We create our customised manager which will fork child process with baseManager. Because we registered SIGCHLD to reap the zombie for manager, we found this causes baseManager raise RemoteError when called twice.(Test script attached.)

After look at baseManager.py we found recv() in handling the request has been interrupted by comming SIGCHLD, not retry recv(), but raise to client side directly.
try:

                methodname = obj = None

                request = recv()<------------------this line been interrupted by SIGCHLD

                ident, methodname, args, kwds = request

                obj, exposed, gettypeid = id_to_obj[ident]

                if methodname not in exposed:

                    raise AttributeError(

                        'method %r of %r object is not in exposed=%r' %

                        (methodname, type(obj), exposed)

                        )

                function = getattr(obj, methodname)
                try:

                    res = function(*args, **kwds)

                except Exception, e:

                    msg = ('#ERROR', e)

                else:

                    typeid = gettypeid and gettypeid.get(methodname, None)

                    if typeid:

                        rident, rexposed = self.create(conn, typeid, res)

                        token = Token(typeid, self.address, rident)

                        msg = ('#PROXY', (rexposed, token))

                    else:

                        msg = ('#RETURN', res)
            except AttributeError:
                if methodname is None:
                    msg = ('#TRACEBACK', format_exc())
                else:
                    try:
                        fallback_func = self.fallback_mapping[methodname]
                        result = fallback_func(
                            self, conn, ident, obj, *args, **kwds
                            )
                        msg = ('#RETURN', result)
                    except Exception:
                        msg = ('#TRACEBACK', format_exc())

            except EOFError:
                util.debug('got EOF -- exiting thread serving %r',
                           threading.current_thread().name)
                sys.exit(0)

            except Exception:<------does not handle IOError,INTR here should retry recv() 
                msg = ('#TRACEBACK', format_exc())

----------
files: fakesupervdsm.py
messages: 181074
nosy: lvroyce
priority: normal
severity: normal
status: open
title: baseManager serve_client() not check EINTR when recv request
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file28930/fakesupervdsm.py

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

From report at bugs.python.org  Fri Feb  1 12:17:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 11:17:29 +0000
Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h
In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za>
Message-ID: <3YyG4T0RywzNyM@mail.python.org>


Roundup Robot added the comment:

New changeset 6074530b526f by Serhiy Storchaka in branch '2.7':
Issue #1783: Remove declarations of nonexistent private variables.
http://hg.python.org/cpython/rev/6074530b526f

New changeset 349419bb6283 by Serhiy Storchaka in branch '3.2':
Issue #1783: Remove declarations of nonexistent private variables.
http://hg.python.org/cpython/rev/349419bb6283

New changeset 9d68f705e25f by Serhiy Storchaka in branch '3.3':
Issue #1783: Remove declarations of nonexistent private variables.
http://hg.python.org/cpython/rev/9d68f705e25f

New changeset 905b4e3cf6d0 by Serhiy Storchaka in branch 'default':
Issue #1783: Remove declarations of nonexistent private variables.
http://hg.python.org/cpython/rev/905b4e3cf6d0

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  1 12:24:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Feb 2013 11:24:47 +0000
Subject: [issue1783] nonexistent data items declared as exports in sysmodule.h
In-Reply-To: <1199980462.14.0.466582779842.issue1783@psf.upfronthosting.co.za>
Message-ID: <1359717887.59.0.409057469171.issue1783@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the report, Jukka Laurila.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb  1 13:04:09 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 01 Feb 2013 12:04:09 +0000
Subject: [issue17053] pydoc should use inspect.signature instead of
	inspect.getfullargspec
In-Reply-To: <1359292632.3.0.760417514127.issue17053@psf.upfronthosting.co.za>
Message-ID: <1359720249.45.0.636002912798.issue17053@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The attached patch is a very rough prototype which seems to work (but wasn't tested beyond running pydoc on a number of function(-like) objects.

With the patch the documentation for a callable defined in C but with a __signature__ property shows argument names in the rendered prototype instead of just '(...)' while the documentation for python functions and C functions without a __signature__ also works.

Issues:

* Rendering to HTML is broken if a function has POSITIONAL_ONLY arguments
  (the names of those arguments are rendered as '<arg>' and that value
  is not escaped in the HTML output)

* This adds a "render" method to inspect.Signature and inspect.Param
  to be able to pass custom render function for elements of a signature
  and I'm not convinced that this is the right solution.

* There are no unittests for the new code (and I haven't run the existing
  tests to check if anything else has broken)

----------
stage: needs patch -> test needed

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

From report at bugs.python.org  Fri Feb  1 14:10:42 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 01 Feb 2013 13:10:42 +0000
Subject: [issue17097] baseManager serve_client() not check EINTR when recv
	request
In-Reply-To: <1359715424.77.0.356613938118.issue17097@psf.upfronthosting.co.za>
Message-ID: <1359724242.13.0.887432403697.issue17097@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy: +sbt

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

From report at bugs.python.org  Fri Feb  1 14:32:24 2013
From: report at bugs.python.org (Stan Seibert)
Date: Fri, 01 Feb 2013 13:32:24 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1359725544.76.0.412374662551.issue8713@psf.upfronthosting.co.za>


Changes by Stan Seibert <stan at mtrr.org>:


----------
nosy: +Stan.Seibert

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

From report at bugs.python.org  Fri Feb  1 14:39:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 13:39:27 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
Message-ID: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. _frozen_importlib, builtins, signal.

----------
components: Interpreter Core
messages: 181078
nosy: brett.cannon, theller
priority: normal
severity: normal
stage: test needed
status: open
title: Set __loader__ on modules imported by the C level
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  1 14:44:37 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 13:44:37 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
Message-ID: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>


New submission from Brett Cannon:

If __loader__ is None then ValueError is raised, but if it is not defined then AttributeError is raised instead. Probably should harmonize around ValueError even in the missing attribute case since __loader__ = None is equivalent to the attribute not existing.

I'm on the fence about considering this a bug, though, since the docs say if __loader__ == None then ValueError but does not directly mention what happens if the attribute is missing. Since anyone who has written code for this probably is catching both attributes (if at all since all but three modules coming from Python will have __loader__ defined ATM), it should be fine, but it is still a change in API/semantics that doesn't contradict the docs.

----------
components: Library (Lib)
messages: 181079
nosy: brett.cannon, ncoghlan, theller
priority: normal
severity: normal
stage: test needed
status: open
title: Raise ValueError when __loader__ not defined for importlib.find_loader()
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  1 15:07:06 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Feb 2013 14:07:06 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359727626.79.0.759607026424.issue17098@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

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

From report at bugs.python.org  Fri Feb  1 15:07:23 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 01 Feb 2013 14:07:23 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1359727643.91.0.271858799686.issue17099@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

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

From report at bugs.python.org  Fri Feb  1 15:35:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Feb 2013 14:35:03 +0000
Subject: [issue17022] Inline assignment uses the newly created object
In-Reply-To: <1359019855.42.0.818555984965.issue17022@psf.upfronthosting.co.za>
Message-ID: <1359729303.64.0.369882498196.issue17022@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it is consistent with plain reasoning if you remember that (a) python is a dynamic language and (b) python assignments do not return values (this is a core principle in the language design), which means that (c) the chained assignment form is a shorthand.  Of course, you do then have to look up what it is a shorthand *for*, but if you approached another language's chained assignment with a Python mindset, you'd also have to look it up to find out what rules applied to that language.

It is hard not to make assumptions based on other languages you've learned.  Interestingly, when I did a quick google for what other languages do for chained assignment I didn't come up with much.  Looks like most don't support it, or if they do they do so as a side effect of an assignment returning a value.

So, yes, Python is a unique language.  There are usually good underlying reasons for the various design decision made (not always, but very very often).

----------

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

From report at bugs.python.org  Fri Feb  1 15:47:38 2013
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 01 Feb 2013 14:47:38 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1359730058.52.0.100324811204.issue17032@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Does fixing this ticket require anything more than making a change in the string that Python uses for this exception?

----------

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

From report at bugs.python.org  Fri Feb  1 16:17:03 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 01 Feb 2013 15:17:03 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359731823.45.0.0379740790266.issue17098@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Fri Feb  1 16:17:22 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 01 Feb 2013 15:17:22 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1359731842.59.0.0646546187751.issue17099@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Fri Feb  1 16:47:50 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 15:47:50 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359733670.86.0.272542385393.issue14468@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Let?s stay friends here :)  Why not remove the existing patches here, export the 8 changesets as patches, attach them here, let people comment?  (I?m not keen on having discussion outside of our system)

----------

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

From report at bugs.python.org  Fri Feb  1 17:23:48 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 16:23:48 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359735828.7.0.248245371413.issue17098@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Should probably check the state of sys.modules in importlib._bootstrap._setup() and see if the missing modules are there and then just retroactively set __loader__ to BuiltinImporter (as is already done in that function for sys and _imp): http://hg.python.org/cpython/file/905b4e3cf6d0/Lib/importlib/_bootstrap.py#l1709 .

----------

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

From report at bugs.python.org  Fri Feb  1 17:24:30 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 16:24:30 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1359735870.52.0.814825574588.issue17099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Should mention that this is probably no harder than changing a key getattr() call to None (as pointed out by Nick).

----------

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

From report at bugs.python.org  Fri Feb  1 17:24:35 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 16:24:35 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1359735875.74.0.344115535705.issue17099@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Fri Feb  1 17:25:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 16:25:10 +0000
Subject: [issue17093] Make importlib.abc more inheritance-friendly
In-Reply-To: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za>
Message-ID: <1359735910.74.0.677956974984.issue17093@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Blog post I wrote explaining what I plan to do: http://sayspy.blogspot.ca/2013/02/remember-to-use-super-in-your-abcs.html

----------

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

From report at bugs.python.org  Fri Feb  1 17:32:03 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2013 16:32:03 +0000
Subject: [issue17100] rotating an ordereddict
Message-ID: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It can be useful to rotate an OrderedDict (for example when managing a circular playlist). I haven't found any efficient way to do so from user code, without poking at the internals.

Actually, I envision three methods:

 OrderedDict.rotate(self, n):

   rotate n steps to the right (similarly to deque.rotate())

 OrderedDict.rotate_at(self, key):

   rotate so that the given key ends up in first position

 OrderedDict.rotate_after(self, key):

   rotate so that the given key ends up in last position

(rotate_at, rotate_after could be merged in a single method with a "last" argument, if deemed more elegant)

Note: another solution to the playlist problem would be to have insert_after() and insert_before() methods.

----------
messages: 181086
nosy: pitrou, rhettinger
priority: normal
severity: normal
status: open
title: rotating an ordereddict
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Feb  1 17:35:40 2013
From: report at bugs.python.org (Benjamin Ash)
Date: Fri, 01 Feb 2013 16:35:40 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1359736540.6.0.19376281947.issue12502@psf.upfronthosting.co.za>


Benjamin Ash added the comment:

Hi,

I am still seeing this issue even with the patches applied. I see 100% CPU utilization, and strace shows the process is in same kind of select() loop as msg139899.

Any help would be greatly appreciated.

Thanks,

-ben

strace output:
"""
select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999998})
select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999998})
select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999998})
select(4, [3], [3], [3], {30, 0})       = 1 (out [3], left {29, 999998})
"""

----------
nosy: +Benjamin.Ash

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

From report at bugs.python.org  Fri Feb  1 17:49:56 2013
From: report at bugs.python.org (Philip Thiem)
Date: Fri, 01 Feb 2013 16:49:56 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1359737396.59.0.55987366973.issue8094@psf.upfronthosting.co.za>


Philip Thiem added the comment:

As an alternative, see http://bugs.python.org/issue10845

It contains a patch for the 3.X series which fixes the infinity loop.

Applying it to the 2.X series will fix the issue and make a change the documentation unnecessary.

----------
nosy: +pthiem

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

From report at bugs.python.org  Fri Feb  1 17:53:29 2013
From: report at bugs.python.org (Philip Thiem)
Date: Fri, 01 Feb 2013 16:53:29 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1359737609.33.0.675392424788.issue8094@psf.upfronthosting.co.za>


Philip Thiem added the comment:

Actually sorry, now that I reread the details a second time, I'm not sure that is this the same deal.  I'll just file a separate bug.

----------

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

From report at bugs.python.org  Fri Feb  1 17:54:16 2013
From: report at bugs.python.org (Philip Thiem)
Date: Fri, 01 Feb 2013 16:54:16 +0000
Subject: [issue17101] Multiprocessing on Windows
Message-ID: <1359737656.57.0.323890943093.issue17101@psf.upfronthosting.co.za>


New submission from Philip Thiem:

http://bugs.python.org/issue10845 also applies to the 2.X series.

this is multiprocessing on windows has issues with __main__.py

----------
components: Windows
messages: 181090
nosy: pthiem
priority: normal
severity: normal
status: open
title: Multiprocessing on Windows
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Feb  1 17:55:03 2013
From: report at bugs.python.org (Philip Thiem)
Date: Fri, 01 Feb 2013 16:55:03 +0000
Subject: [issue17101] __main__.py Multiprocessing on Windows
In-Reply-To: <1359737656.57.0.323890943093.issue17101@psf.upfronthosting.co.za>
Message-ID: <1359737703.61.0.704541653086.issue17101@psf.upfronthosting.co.za>


Changes by Philip Thiem <ptthiem at gmail.com>:


----------
title: Multiprocessing on Windows -> __main__.py Multiprocessing on Windows

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

From report at bugs.python.org  Fri Feb  1 19:47:58 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 18:47:58 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359744478.64.0.358325747901.issue17098@psf.upfronthosting.co.za>


Brett Cannon added the comment:

All cases but signal can be fixed by importlib._bootstrap._setup() by simply iterating over sys.modules and setting __loader__. Nice and simple. Thanks, abstraction!

The problem is signal who gives the finger to abstraction. That module gets imported directly by C code which cheats by calling PyInit_signal() directly and then calling _PyImport_FixupBuiltin(). I tried setting __loader__ in there but I'm actually triggering a segfault in PyErr_Format()! This is probably because I/O streams are not set up yet at this point in interpreter startup. Anyway, I'm trying to simply not have the code cheat and instead just import the signal module through the proper abstractions.

----------

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

From report at bugs.python.org  Fri Feb  1 19:53:00 2013
From: report at bugs.python.org (Jason Tishler)
Date: Fri, 01 Feb 2013 18:53:00 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>
Message-ID: <1359744780.73.0.720333207075.issue13756@psf.upfronthosting.co.za>


Jason Tishler added the comment:

> Is this still an issue on 3.3/3.4?

I presume so.

> Does the patch still work?

I haven't tried it on 3.3 yet, so I don't know if it will apply cleanly.

----------

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

From report at bugs.python.org  Fri Feb  1 20:03:09 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 19:03:09 +0000
Subject: [issue17078] string.Template.safe_substitute hard-wires "braces" as {}
In-Reply-To: <1359495046.85.0.635388190725.issue17078@psf.upfronthosting.co.za>
Message-ID: <1359745389.61.0.304673639327.issue17078@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Barry, I read that passage in the PEP to explain why the default style uses ${}, but the bug here is about a Template class with an overriden placeholder pattern.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Feb  1 20:05:45 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 19:05:45 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1359745545.73.0.6512367007.issue17069@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ezio.melotti

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

From report at bugs.python.org  Fri Feb  1 20:05:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 19:05:55 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1359745555.51.0.381869530928.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Because this is a patch for the devguide, so we cannot use Rietveld for the review.

----------

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

From report at bugs.python.org  Fri Feb  1 20:06:49 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 01 Feb 2013 19:06:49 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1359745609.02.0.768392801219.issue17069@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Fri Feb  1 20:07:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 19:07:43 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <3YySW262QZzNgq@mail.python.org>


Roundup Robot added the comment:

New changeset 05747d3bcd9c by Brett Cannon in branch '3.3':
Issue #17098: Make sure every module has __loader__ defined.
http://hg.python.org/cpython/rev/05747d3bcd9c

New changeset 1f1a1b3cc416 by Brett Cannon in branch 'default':
Issue #17098: all modules should have __loader__
http://hg.python.org/cpython/rev/1f1a1b3cc416

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  1 20:08:48 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 19:08:48 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359745728.09.0.199656596943.issue17098@psf.upfronthosting.co.za>


Brett Cannon added the comment:

OK, so my solution for signal worked. All fixed now. If any other modules pop up with __loader__ not set from now on it's because they cheated on import. =)

----------
assignee:  -> brett.cannon
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Feb  1 20:13:58 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 19:13:58 +0000
Subject: [issue17035] Use new style classes in {class, static}method examples
In-Reply-To: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>
Message-ID: <1359746038.05.0.305209561785.issue17035@psf.upfronthosting.co.za>


?ric Araujo added the comment:

LGTM.

----------
nosy: +eric.araujo
stage:  -> patch review

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

From report at bugs.python.org  Fri Feb  1 20:15:51 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Feb 2013 19:15:51 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1359746151.71.0.0895941354071.issue17099@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Feb  1 20:16:44 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 19:16:44 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1359746204.88.0.488140626339.issue16555@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I have a busy week-end ahead but I could sneak a little time for this.

----------
nosy: +doerwalter

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

From report at bugs.python.org  Fri Feb  1 20:20:31 2013
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 01 Feb 2013 19:20:31 +0000
Subject: [issue17083] can't specify newline string for readline for binary
	files
In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za>
Message-ID: <1359746431.81.0.148386907107.issue17083@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

I think Bryant's request is reasonable, for consistency in functionality. If line oriented operations are allowed on binary files, then a binary newline value should be permitted at the time of open.

I think, for handling binary files, that it would also be interesting to have a version of readline that takes a binary newline file as a parameter to each readline call, because in binary files, the concept of newline can vary from section to section of the file... here, null-terminated records, there CR LF terminated encoded text records, elsewhere fixed-length records, and another place might have records delimited by some binary token of one or more bytes.  Readline with a newline parameter could be useful in three of those cases, read in the fixed-length case.  But this paragraph would be a new feature.

However, simpler binary files, which may have only one type of "terminated" records, could effectively use the operations Bryant is suggesting, which seems quite reasonable to me, along with a mix of read calls for non-delimited data, fixed-length data, or data requiring complex logic to decode.

----------
nosy: +v+python

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

From report at bugs.python.org  Fri Feb  1 20:31:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Feb 2013 19:31:03 +0000
Subject: [issue17083] can't specify newline string for readline for binary
	files
In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za>
Message-ID: <1359747063.69.0.294780227622.issue17083@psf.upfronthosting.co.za>


R. David Murray added the comment:

Anything we do here is a new feature.

I have no objection to adding features in this area myself, but I will note that I was shot down for proposing (in another issue) that the newline attribute for text files be allowed to be an arbitrary string.

----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Fri Feb  1 20:39:56 2013
From: report at bugs.python.org (Bryant)
Date: Fri, 01 Feb 2013 19:39:56 +0000
Subject: [issue17083] can't specify newline string for readline for binary
	files
In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za>
Message-ID: <1359747596.25.0.977820241499.issue17083@psf.upfronthosting.co.za>


Bryant added the comment:

While my original description of this issue discussed arbitrary strings, I'd like to limit the scope of this issue down to just supporting the newline parameter to builtin.open() for binary files, just as it's supported for regular files. This adds no real new functionality, just makes the treatment of the concept of a "line" consistent between binary files and regular text files, since that concept *does* exist in many cases in binary files.

Given that everyone here seems to think this is at least reasonable at this point, what would the next step be given this is somewhere between a library fix and a feature addition? I haven't contributed to Python before, but the developer FAQ mentions either python-ideas or a PEP, or should this move right towards a patch?

----------

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

From report at bugs.python.org  Fri Feb  1 20:40:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 19:40:31 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3YyTDv1qYWzRH0@mail.python.org>


Roundup Robot added the comment:

New changeset 0c5fa35c9f12 by Gregory P. Smith in branch '3.2':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/0c5fa35c9f12

New changeset 483488a1dec5 by Gregory P. Smith in branch '3.3':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/483488a1dec5

New changeset 249e0b47b686 by Gregory P. Smith in branch 'default':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/249e0b47b686

New changeset 4d1948689ee1 by Gregory P. Smith in branch '2.7':
Fixes Issue #6972: The zipfile module no longer overwrites files outside of
http://hg.python.org/cpython/rev/4d1948689ee1

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  1 20:40:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 19:40:54 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359747654.8.0.674463818026.issue17098@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Looks like I spoke too soon. I realized I had not written a test so I did it quickly and it turns out that while this is fixed for 3.3 it isn't for 3.4.

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

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

From report at bugs.python.org  Fri Feb  1 20:41:20 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 Feb 2013 19:41:20 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359747680.15.0.123569104492.issue6972@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  1 20:42:51 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Feb 2013 19:42:51 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359747771.09.0.57421078763.issue17098@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Feb  1 21:03:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Feb 2013 20:03:29 +0000
Subject: [issue17083] can't specify newline string for readline for binary
	files
In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za>
Message-ID: <1359749009.33.0.662586931778.issue17083@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it's a feature by our policy, since it currently works as documented.

Probably the first thing would be to get the opinion of someone who works on the IO module, so I've nosied Antoine.  Note that this was obviously a conscious design decision, as it is documented clearly.

Another possible first step is the one I suggested: posting a recipe on the recipe site and seeing if there is any uptake.  Python-ideas would be another option.  For this level of change, I don't believe a PEP is required :)

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

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

From report at bugs.python.org  Fri Feb  1 21:04:14 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Feb 2013 20:04:14 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359749054.64.0.912877715238.issue17100@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Feb  1 21:47:45 2013
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 01 Feb 2013 20:47:45 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359751665.25.0.0268372663454.issue17098@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I have only tried my code with 3.4; but still get problems with the modules 'builtins' and '_frozenimportlib'.

----------

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

From report at bugs.python.org  Fri Feb  1 22:07:14 2013
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 01 Feb 2013 21:07:14 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359752834.17.0.128179264335.issue6972@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

does anyone know if the same issue has been fixed in the tarfile module?

----------

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

From report at bugs.python.org  Fri Feb  1 22:12:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 21:12:25 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <3YyWGw64lrzSP4@mail.python.org>


Roundup Robot added the comment:

New changeset a5e7b38caee2 by Gregory P. Smith in branch '2.7':
Additional fix for Issue #12268: The io module file object writelines() methods
http://hg.python.org/cpython/rev/a5e7b38caee2

New changeset 2fd669aa4abc by Gregory P. Smith in branch '3.2':
Additional fix for Issue #12268: The io module file object writelines() methods no longer abort early when one of its write system calls is interrupted (EINTR).
http://hg.python.org/cpython/rev/2fd669aa4abc

New changeset 30fc620e240e by Gregory P. Smith in branch '3.3':
Additional fix for issue #12268: The io module file object write methods no
http://hg.python.org/cpython/rev/30fc620e240e

New changeset 8f72519fd0e9 by Gregory P. Smith in branch 'default':
Additional fix for issue #12268: The io module file object write methods no
http://hg.python.org/cpython/rev/8f72519fd0e9

----------

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

From report at bugs.python.org  Fri Feb  1 22:17:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Feb 2013 21:17:13 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <3YyWGw64lrzSP4@mail.python.org>
Message-ID: <CAMpsgwais3fLG=eM_bXnrU2fW4Q=92ofdZQcym6YqiFb4vS5hQ@mail.gmail.com>


STINNER Victor added the comment:

Oh, so we can now implement a version of writelines() using writev()!

2013/2/1 Roundup Robot <report at bugs.python.org>:
>
> Roundup Robot added the comment:
>
> New changeset a5e7b38caee2 by Gregory P. Smith in branch '2.7':
> Additional fix for Issue #12268: The io module file object writelines() methods
> http://hg.python.org/cpython/rev/a5e7b38caee2
>
> New changeset 2fd669aa4abc by Gregory P. Smith in branch '3.2':
> Additional fix for Issue #12268: The io module file object writelines() methods no longer abort early when one of its write system calls is interrupted (EINTR).
> http://hg.python.org/cpython/rev/2fd669aa4abc
>
> New changeset 30fc620e240e by Gregory P. Smith in branch '3.3':
> Additional fix for issue #12268: The io module file object write methods no
> http://hg.python.org/cpython/rev/30fc620e240e
>
> New changeset 8f72519fd0e9 by Gregory P. Smith in branch 'default':
> Additional fix for issue #12268: The io module file object write methods no
> http://hg.python.org/cpython/rev/8f72519fd0e9
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12268>
> _______________________________________

----------

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

From report at bugs.python.org  Fri Feb  1 22:19:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 Feb 2013 21:19:52 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1359753592.47.0.596839254604.issue12268@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

it was easier to just take care of auditing the write calls as part of this given the code change was directly related to it.

On Python 2.7 most of the write calls in the builtin file object (Objects/fileobject.c) rather than the new io module use the libc fwrite() call which, in linux man pages at least, is non-specific about what happens on EINTR (does it retry internally or does it return the number of bytes written so far?).  Those could well abort leading to an error.

Setting up a testcase fo to confirm that with is painful (time consuming) so I can't claim the non io module based write's do not still have an EINTR issue on 2.7.

Workaround: Use the io module instead of the builtin open() or file() calls in Python 2.7.

If someone can confirm that with a test case, it'd make another good issue to open.

As for the writev comment... go ahead. :)

----------

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

From report at bugs.python.org  Fri Feb  1 22:20:00 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 Feb 2013 21:20:00 +0000
Subject: [issue12268] file readline,
	readlines & readall methods can lose data on EINTR
In-Reply-To: <1307306343.57.0.342192724444.issue12268@psf.upfronthosting.co.za>
Message-ID: <1359753600.14.0.752775444618.issue12268@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb  1 22:37:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 21:37:59 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <3YyWrQ6dbrzSQH@mail.python.org>


Roundup Robot added the comment:

New changeset 4a4688b865ff by Brett Cannon in branch '3.3':
Add a test for fix of issue #17098
http://hg.python.org/cpython/rev/4a4688b865ff

New changeset 19ea454ccdf7 by Brett Cannon in branch '3.3':
Issue #17098: Be more stringent of setting __loader__ on early imported
http://hg.python.org/cpython/rev/19ea454ccdf7

New changeset 306f066e6a33 by Brett Cannon in branch 'default':
Merge w/ 3.3 more fixes thanks to issue #17098
http://hg.python.org/cpython/rev/306f066e6a33

----------

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

From report at bugs.python.org  Fri Feb  1 22:40:56 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:40:56 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359754856.05.0.39865394362.issue17098@psf.upfronthosting.co.za>


Brett Cannon added the comment:

OK, 3.3 and 3.4 now have tests and verify everything is working fine.

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

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

From report at bugs.python.org  Fri Feb  1 22:46:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:46:08 +0000
Subject: [issue17093] Make importlib.abc more inheritance-friendly
In-Reply-To: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za>
Message-ID: <1359755168.46.0.192782877889.issue17093@psf.upfronthosting.co.za>


Brett Cannon added the comment:

OK, rewrote that blog post as Thomas pointed out my thinking was worrying about stuff I shouldn't be: http://sayspy.blogspot.ca/2013/02/remember-to-use-super-in-your-abcs.html

----------

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

From report at bugs.python.org  Fri Feb  1 22:46:56 2013
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 01 Feb 2013 21:46:56 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359755216.19.0.0805750045429.issue17098@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I confirm that the bug is fixed, my test-code works now (a modulefinder using importlib instead of imp to find modules).

----------

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

From report at bugs.python.org  Fri Feb  1 22:47:29 2013
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 01 Feb 2013 21:47:29 +0000
Subject: [issue17098] Set __loader__ on modules imported by the C level
In-Reply-To: <1359725967.87.0.894727021697.issue17098@psf.upfronthosting.co.za>
Message-ID: <1359755249.08.0.843861842644.issue17098@psf.upfronthosting.co.za>


Thomas Heller added the comment:

Thanks for the very fast fix Brett :-)

----------

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

From report at bugs.python.org  Fri Feb  1 22:48:03 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:48:03 +0000
Subject: [issue17093] Make importlib.abc more inheritance-friendly
In-Reply-To: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za>
Message-ID: <1359755283.01.0.408063792176.issue17093@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And as part of this I need to update the docstrings to mention default reactions.

----------

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

From report at bugs.python.org  Fri Feb  1 22:53:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:53:38 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1359755618.06.0.625908807425.issue13192@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Is this still an issue in (at least) 3.4 with the new I/O exceptions? And I feel like there was another bug about this.

----------

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

From report at bugs.python.org  Fri Feb  1 22:54:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:54:27 +0000
Subject: [issue13184] Multi-layered symlinks to python cause runtime error.
	sys.path is malformed.
In-Reply-To: <1318655680.83.0.71543236392.issue13184@psf.upfronthosting.co.za>
Message-ID: <1359755667.64.0.0769486173182.issue13184@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/issue13184>
_______________________________________

From report at bugs.python.org  Fri Feb  1 22:55:30 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:55:30 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
In-Reply-To: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za>
Message-ID: <1359755730.51.0.773746319109.issue13306@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Did you still plan to write this code, Nick? Or were you just thinking about loud and don't need this bug here anymore?

----------

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

From report at bugs.python.org  Fri Feb  1 22:56:14 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:56:14 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1359755774.47.0.650176456443.issue8623@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/issue8623>
_______________________________________

From report at bugs.python.org  Fri Feb  1 22:56:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:56:27 +0000
Subject: [issue13819] _warnings settings are process-wide
In-Reply-To: <1326919817.29.0.252163037725.issue13819@psf.upfronthosting.co.za>
Message-ID: <1359755787.07.0.650718930992.issue13819@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/issue13819>
_______________________________________

From report at bugs.python.org  Fri Feb  1 22:57:25 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:57:25 +0000
Subject: [issue13829] exception error in _scproxy.so
In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>
Message-ID: <1359755845.38.0.672953466991.issue13829@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/issue13829>
_______________________________________

From report at bugs.python.org  Fri Feb  1 22:58:01 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:58:01 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1359755881.86.0.492741773682.issue13124@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Did you want to commit this patch yourself, Eric, since you have commit privs now?

----------

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

From report at bugs.python.org  Fri Feb  1 22:59:16 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:59:16 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1359755956.6.0.105048907123.issue4010@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/issue4010>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:05:16 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:05:16 +0000
Subject: [issue8754] quote bad module name in ImportError-like messages
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1359756316.98.0.955161732543.issue8754@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Over time I have fixed this issue in various patches.

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

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

From report at bugs.python.org  Fri Feb  1 23:06:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 22:06:50 +0000
Subject: [issue16256] permissions wrong on Mac doc dir
In-Reply-To: <1350428962.56.0.21849680877.issue16256@psf.upfronthosting.co.za>
Message-ID: <3YyXTk1HrlzSSF@mail.python.org>


Roundup Robot added the comment:

New changeset d64e0cf5f1a7 by Ned Deily in branch '2.7':
Issue #16256: OS X installer now sets correct permissions for doc directory.
http://hg.python.org/cpython/rev/d64e0cf5f1a7

New changeset e8a1b5757067 by Ned Deily in branch '3.2':
Issue #16256: OS X installer now sets correct permissions for doc directory.
http://hg.python.org/cpython/rev/e8a1b5757067

New changeset 1db5ed6a2dc2 by Ned Deily in branch '3.3':
Issue #16256: merge from 3.2
http://hg.python.org/cpython/rev/1db5ed6a2dc2

New changeset bc2c40e84b58 by Ned Deily in branch 'default':
Issue #16256: merge from 3.3
http://hg.python.org/cpython/rev/bc2c40e84b58

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Feb  1 23:07:59 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:07:59 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1359756479.61.0.878905154813.issue12919@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This would tie into PEP 432 at this point.

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

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

From report at bugs.python.org  Fri Feb  1 23:08:12 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Feb 2013 22:08:12 +0000
Subject: [issue16256] permissions wrong on Mac doc dir
In-Reply-To: <1350428962.56.0.21849680877.issue16256@psf.upfronthosting.co.za>
Message-ID: <1359756492.38.0.216078853704.issue16256@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report and the patch.  Committed for 2.7.4, 3.2.4, and 3.3.1.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb  1 23:11:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:11:09 +0000
Subject: [issue14285] Traceback wrong on ImportError while executing a package
In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za>
Message-ID: <1359756669.08.0.67392753038.issue14285@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/issue14285>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:14:05 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:14:05 +0000
Subject: [issue11085] expose _abcoll as collections.abc
In-Reply-To: <1296503066.28.0.738947830383.issue11085@psf.upfronthosting.co.za>
Message-ID: <1359756845.94.0.426875188415.issue11085@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm closing this again as 3.3 actually starts up faster than 3.2 thanks to importlib so this slowdown is no longer noticeable.

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

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

From report at bugs.python.org  Fri Feb  1 23:19:16 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Feb 2013 22:19:16 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
In-Reply-To: <1359755730.51.0.773746319109.issue13306@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dbb0OfwVrT_uUPG2k5FioQEZeai-_AUwo99wzFakb5pQ@mail.gmail.com>


Nick Coghlan added the comment:

I still think it would be a good feature to offer, but have no plans to
write it myself.

----------

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

From report at bugs.python.org  Fri Feb  1 23:28:01 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:28:01 +0000
Subject: [issue14580] imp.reload can fail for sub-modules
In-Reply-To: <1334429743.69.0.840922249937.issue14580@psf.upfronthosting.co.za>
Message-ID: <1359757681.6.0.565692681426.issue14580@psf.upfronthosting.co.za>


Brett Cannon added the comment:

This is no longer a problem:

>>> import imp
>>> import collections
>>> import collections.abc
<module 'collections.abc' from '/Users/bcannon/Developer/repo/cpython/py3k/Lib/collections/abc.py'>

----------
assignee:  -> brett.cannon
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Feb  1 23:28:58 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:28:58 +0000
Subject: [issue12598] Move sys variable initialization from import.c to
	sysmodule.c
In-Reply-To: <1311204284.83.0.766064550687.issue12598@psf.upfronthosting.co.za>
Message-ID: <1359757738.01.0.611232124202.issue12598@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/issue12598>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:30:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:30:38 +0000
Subject: [issue13473] Add tests for files byte-compiled by distutils[2]
In-Reply-To: <1322145911.61.0.528651769931.issue13473@psf.upfronthosting.co.za>
Message-ID: <1359757838.11.0.748747511868.issue13473@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/issue13473>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:31:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:31:09 +0000
Subject: [issue14689] make PYTHONWARNINGS variable work in libpython
In-Reply-To: <1335606965.58.0.412104204254.issue14689@psf.upfronthosting.co.za>
Message-ID: <1359757869.87.0.299458712158.issue14689@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/issue14689>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:33:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:33:11 +0000
Subject: [issue14724] kill imp.load_dynamic's third argument
In-Reply-To: <1336164511.78.0.519044801225.issue14724@psf.upfronthosting.co.za>
Message-ID: <1359757991.16.0.829482548464.issue14724@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Turns out this was used in the wild and has now been fixed to be useful. =)

----------
resolution:  -> works for me
status: open -> closed
superseder:  -> importlib.machinery.ExtensionFileLoader cannot load several modules from the same shared object

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

From report at bugs.python.org  Fri Feb  1 23:33:35 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:33:35 +0000
Subject: [issue12937] distutils2: install action should support same options
	as install command
In-Reply-To: <1315504187.52.0.368275649699.issue12937@psf.upfronthosting.co.za>
Message-ID: <1359758015.75.0.0661772113555.issue12937@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/issue12937>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:34:43 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:34:43 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1359758083.04.0.0522707915959.issue4011@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Would this still be useful to do? Thanks to my latest import talk I have experience with graphviz but I don't want to waste my time if people don't need it.

----------
assignee: larry -> 

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

From report at bugs.python.org  Fri Feb  1 23:41:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:41:49 +0000
Subject: [issue15344] devinabox: failure when running make_a_box multiple times
In-Reply-To: <1342154945.64.0.517159061832.issue15344@psf.upfronthosting.co.za>
Message-ID: <1359758509.85.0.58761259917.issue15344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Since you got this with a clean run and I had dev_in_a_box.py work for me in November I'm closing this.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Feb  1 23:42:06 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:42:06 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1359758526.32.0.575532118921.issue10342@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/issue10342>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:43:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:43:08 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1359758588.02.0.64891937637.issue15369@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/issue15369>
_______________________________________

From report at bugs.python.org  Fri Feb  1 23:56:17 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 22:56:17 +0000
Subject: [issue8754] quote bad module name in ImportError-like messages
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1359759377.73.0.781686659693.issue8754@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Great!

----------
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Sat Feb  2 00:30:47 2013
From: report at bugs.python.org (Christopher Barker)
Date: Fri, 01 Feb 2013 23:30:47 +0000
Subject: [issue16256] permissions wrong on Mac doc dir
In-Reply-To: <1359756492.38.0.216078853704.issue16256@psf.upfronthosting.co.za>
Message-ID: <CALGmxEL82J-_uuQOdvgW_OiV221QjeF3mybEmfW4bLyeh_91Gg@mail.gmail.com>


Christopher Barker added the comment:

On Fri, Feb 1, 2013 at 2:08 PM, Ned Deily <report at bugs.python.org> wrote:
> Thanks for the report and the patch.  Committed for 2.7.4, 3.2.4, and 3.3.1.

Did I actually submit a patch? but thanks to you for getting it done
-- and all else you do for pythonmac.

-Chris

> ----------
> resolution:  -> fixed
> stage:  -> committed/rejected
> status: open -> closed
> versions: +Python 3.2, Python 3.3, Python 3.4
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16256>
> _______________________________________

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

----------

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

From report at bugs.python.org  Sat Feb  2 00:48:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2013 23:48:02 +0000
Subject: [issue17083] can't specify newline string for readline for binary
	files
In-Reply-To: <1359570725.1.0.7766942653.issue17083@psf.upfronthosting.co.za>
Message-ID: <1359762482.51.0.309055918329.issue17083@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think readline() is quite clear in its current intent (it reads a line, which conventionally is delimited by '\n').
We mau want to add another method, say read_until_delimiter(), but it's not the same as readline() ;-) I think it would be best for it to be discussed, say on python-ideas (*), before any decision is made.

(*) http://mail.python.org/mailman/listinfo/python-ideas

----------

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

From report at bugs.python.org  Sat Feb  2 04:49:12 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 02 Feb 2013 03:49:12 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359776952.63.0.257386707192.issue17100@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Will attach patch when I get free (10 hours from now)

----------
nosy: +ramchandra.apte

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

From report at bugs.python.org  Sat Feb  2 07:02:27 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Feb 2013 06:02:27 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
	path
Message-ID: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Create a malicious .tar file with entries containing absolute or relative paths and the tarfile module happily uses them as is without sanity checking.

filed in response to http://bugs.python.org/issue6972 which fixed the zipfile module for this.

I'm attaching an example tar file to demonstrate this (safely) but much worse things could obviously be done.

----------
files: absolute_path.tar
messages: 181133
nosy: gregory.p.smith
priority: high
severity: normal
status: open
title: tarfile extract can write files outside the destination path
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28931/absolute_path.tar

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

From report at bugs.python.org  Sat Feb  2 07:03:08 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Feb 2013 06:03:08 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359784988.23.0.459955854277.issue6972@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

yes, tarfile appears to have the same problem.  http://bugs.python.org/issue17102 filed.

----------

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

From report at bugs.python.org  Sat Feb  2 07:08:46 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Feb 2013 06:08:46 +0000
Subject: [issue17097] multiprocessing BaseManager serve_client() does not
	check EINTR on recv
In-Reply-To: <1359715424.77.0.356613938118.issue17097@psf.upfronthosting.co.za>
Message-ID: <1359785326.54.0.952345155421.issue17097@psf.upfronthosting.co.za>


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


----------
title: baseManager serve_client() not check EINTR when recv request -> multiprocessing BaseManager serve_client() does not check EINTR on recv

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

From report at bugs.python.org  Sat Feb  2 07:36:45 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 Feb 2013 06:36:45 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1359787005.75.0.887780660322.issue13192@psf.upfronthosting.co.za>


Eric Snow added the comment:

Are you thinking of issue 15833?

----------

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

From report at bugs.python.org  Sat Feb  2 07:45:13 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 Feb 2013 06:45:13 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1359787513.52.0.700027897701.issue13124@psf.upfronthosting.co.za>


Eric Snow added the comment:

Yeah, at some point I will. :)  I've been pretty focused on implementing a C-OrderedDict, which I'm (hopefully) wrapping up pretty soon.  Once that happens I'm going to revisit a bunch of the open tickets I have.  If you want to push this sooner than that, feel free. :)

----------

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

From report at bugs.python.org  Sat Feb  2 07:55:53 2013
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 02 Feb 2013 06:55:53 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
	path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1359788153.05.0.29173413368.issue17102@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <python-bugs at systemexit.de>:


----------
nosy: +schmir

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

From report at bugs.python.org  Sat Feb  2 08:18:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 07:18:14 +0000
Subject: [issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
In-Reply-To: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za>
Message-ID: <3Yymjx3Dw8zPrk@mail.python.org>


Roundup Robot added the comment:

New changeset 2274f3196a44 by Ned Deily in branch '2.7':
Issue #15587: Enable Tk high-resolution text rendering on Macs with
http://hg.python.org/cpython/rev/2274f3196a44

New changeset 7dfd84021494 by Ned Deily in branch '3.2':
Issue #15587: Enable Tk high-resolution text rendering on Macs with
http://hg.python.org/cpython/rev/7dfd84021494

New changeset 8fbab6648309 by Ned Deily in branch '3.3':
Issue #15587: merge from 3.2
http://hg.python.org/cpython/rev/8fbab6648309

New changeset d8dcf87b8e49 by Ned Deily in branch 'default':
Issue #15587: merge from 3.3
http://hg.python.org/cpython/rev/d8dcf87b8e49

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Feb  2 08:21:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 07:21:04 +0000
Subject: [issue13192] ImportError silences low-level OS errors
In-Reply-To: <1318796716.98.0.562997558521.issue13192@psf.upfronthosting.co.za>
Message-ID: <1359789664.08.0.0100231479312.issue13192@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

In 3.3 and 3.4, exceptions are not silenced anymore:

>>> import resource
>>> resource.setrlimit(resource.RLIMIT_NOFILE, (2, 100))
>>> import encodings.idna
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 1584, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1551, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 586, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1049, in load_module
  File "<frozen importlib._bootstrap>", line 1030, in load_module
  File "<frozen importlib._bootstrap>", line 562, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 883, in _load_module
  File "<frozen importlib._bootstrap>", line 1008, in get_code
  File "<frozen importlib._bootstrap>", line 1058, in get_data
OSError: [Errno 24] Too many open files: '/home/antoine/cpython/default/Lib/encodings/idna.py'


Given that fixing the issue in bugfix branches would be a slight behaviour change, I think we can close this issue.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7 -Python 3.3

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

From report at bugs.python.org  Sat Feb  2 08:28:01 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Feb 2013 07:28:01 +0000
Subject: [issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
In-Reply-To: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za>
Message-ID: <1359790081.86.0.443312891845.issue15587@psf.upfronthosting.co.za>


Ned Deily added the comment:

I've updated the plists for both IDLE.app and the framework Python.app to enable the high-resolution rendering.  That should affect IDLE.app and bin/idle and any other Tkinter-based program, as long as they all are being run from a framework build of Python such as provided by the python.org OS X installers.  Again, since I don't have access to a Retina display Mac, I cannot test the changes myself.  The fixes will appear in the upcoming 2.7.4 and 3.2.4 releases as well as 3.3.1 and 3.4.0.  It would be nice if someone with a Retina Mac could install one or both of the release candidates for 2.7.4 and 3.2.4 when available and report the results of testing.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
type: enhancement -> behavior
versions: +Python 3.4

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

From report at bugs.python.org  Sat Feb  2 08:32:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 07:32:53 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359790373.16.0.802564479647.issue17100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is trivial.

def rotate(od, n):
    for i in range(n):
        k, v = od.popitem(False)
        od[k] = v

And those functions look too specialized.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Feb  2 08:38:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 07:38:40 +0000
Subject: [issue16601] Restarting iteration over tarfile continues from where
	it left off.
In-Reply-To: <1354564872.87.0.0661195327337.issue16601@psf.upfronthosting.co.za>
Message-ID: <1359790720.32.0.898866291741.issue16601@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Michael, what's the status of your contributor form?

----------

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

From report at bugs.python.org  Sat Feb  2 08:41:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 07:41:19 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
	path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1359790879.88.0.286376221468.issue17102@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Feb  2 08:56:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 07:56:56 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359790373.16.0.802564479647.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359791643.3476.2.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> It is trivial.
> 
> def rotate(od, n):
>     for i in range(n):
>         k, v = od.popitem(False)
>         od[k] = v

That's O(n), with many spurious insertions and deletions.

> And those functions look too specialized.

How so? rotating sounds quite generic to me. deques already allow
rotating.

----------

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

From report at bugs.python.org  Sat Feb  2 09:21:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 08:21:19 +0000
Subject: [issue15116] remove out-of-date Mac application scripting
	documentation
In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>
Message-ID: <3Yyp6k4HYjzPvC@mail.python.org>


Roundup Robot added the comment:

New changeset 7ca742d808b2 by Ned Deily in branch '2.7':
Issue #15116: Remove references to appscript as it is no longer being
http://hg.python.org/cpython/rev/7ca742d808b2

New changeset 0f0256e4a1ef by Ned Deily in branch '3.2':
Issue #15116: Remove references to appscript as it is no longer being
http://hg.python.org/cpython/rev/0f0256e4a1ef

New changeset 1b1f7ec5ddb8 by Ned Deily in branch '3.3':
Issue #15116: merge from 3.2
http://hg.python.org/cpython/rev/1b1f7ec5ddb8

New changeset 6053e0e1f05b by Ned Deily in branch 'default':
Issue #15116: merge from 3.3
http://hg.python.org/cpython/rev/6053e0e1f05b

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Feb  2 09:23:29 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Feb 2013 08:23:29 +0000
Subject: [issue15116] remove out-of-date Mac application scripting
	documentation
In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>
Message-ID: <1359793409.82.0.341823242792.issue15116@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Sat Feb  2 09:40:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 08:40:54 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1359794454.55.0.774772229962.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

These are correct as they are:

Lib/tkinter/tix.py:149:        """Locates a bitmap file of the name name.xpm or name in one of the
Lib/tkinter/tix.py:160:        """Locates an image file of the name name.xpm, name.xbm or name.ppm

Modules/_io/iobase.c:79:    "Change the stream position to byte offset offset. offset is\n"
<I believe the 2nd and 3rd 'offset' are argument names, which would be specially marked in .rst>

Modules/socketmodule.c:3547:           ensures that that doesn't happen. */
Modules/binascii.c:41:** I have attempted to break with this tradition, but I guess that that
Doc/c-api/intro.rst:436::c:func:`sum_sequence` example above.  It so happens that that example doesn't
<'that that' is awkward, but the two 'that's are different>

Modules/posixmodule.c:9747:Return the value of extended attribute attribute on path.\n\
Modules/posixmodule.c:9825:Set extended attribute attribute on path to value.\n\
Modules/posixmodule.c:9890:Remove extended attribute attribute on path.\n\
PC/msvcrtmodule.c:133:Create a C runtime file descriptor from the file handle handle. The\n\
<much like byte offset offset>

Doc/c-api/long.rst:206:   Return a C :c:type:`size_t` representation of of *pylong*.  *pylong* must be
<the re missed the '.'.>

False doubles from typos (which should also be changed):
Lib/test/test_socket.py:845:        # Try udp, but don't barf it it doesn't exist
/it it/if it/

?ric, I am puzzled by your comment. The only two 'the the's in Serhiy's report (that Firefox finds) are

python-gdb.py:1466:        '''Is this frame "collect" within the the garbage-collector?'''
<I suspect 'collect' should be 'collected', but I cannot tell without a link. I am sure 'the the' is wrong.>

Misc/HISTORY:3055:  environment after Distutils set it.  Instead, have Distutils set the the

and both look like wrong doubles and not 'that the'.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  2 09:44:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 08:44:34 +0000
Subject: [issue11159] Sax parser crashes if given unicode file name
In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>
Message-ID: <3YypdY6Fh9zMr7@mail.python.org>


Roundup Robot added the comment:

New changeset d3e7aea8a550 by Serhiy Storchaka in branch '2.7':
Issue #11159: SAX?parser now supports unicode file names.
http://hg.python.org/cpython/rev/d3e7aea8a550

New changeset d2622ca8493a by Serhiy Storchaka in branch '3.2':
Issue #11159: Add tests for testing SAX?parser support of non-ascii file names.
http://hg.python.org/cpython/rev/d2622ca8493a

New changeset b85ba45b9579 by Serhiy Storchaka in branch '3.3':
Issue #11159: Add tests for testing SAX?parser support of non-ascii file names.
http://hg.python.org/cpython/rev/b85ba45b9579

New changeset 107a06f1a542 by Serhiy Storchaka in branch 'default':
Issue #11159: Add tests for testing SAX?parser support of non-ascii file names.
http://hg.python.org/cpython/rev/107a06f1a542

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Feb  2 09:53:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 08:53:03 +0000
Subject: [issue11159] Sax parser crashes if given unicode file name
In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>
Message-ID: <1359795183.23.0.842510214507.issue11159@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed. Thank you for the report.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  2 09:53:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 08:53:29 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359795209.13.0.483546013846.issue17100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> That's O(n), with many spurious insertions and deletions.

Any implementation is O(n).

> deques already allow rotating.

I agree that the rotation makes some sense for such collections as deque or OrderedDict (although it is easy implemented in user code). But there are no rotate_at() and rotate_after() in deque.

----------

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

From report at bugs.python.org  Sat Feb  2 09:53:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 08:53:53 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1359795233.02.0.986167062044.issue12568@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Sat Feb  2 10:02:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 09:02:56 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359795209.13.0.483546013846.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359795604.3476.6.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > That's O(n), with many spurious insertions and deletions.
> 
> Any implementation is O(n).

For rotate() perhaps (but still, it can be more efficient in that it can
just move the list head once instead of repeatedly deleting and
inserting elements). But rotate_at() / rotate_after() can probably be
O(1), unless I'm missing something.

> > deques already allow rotating.
> 
> I agree that the rotation makes some sense for such collections as
> deque or OrderedDict (although it is easy implemented in user code).
> But there are no rotate_at() and rotate_after() in deque.

That's because a deque is not a mapping ;-) In other words, if a deque
was enough I'd be using a deque, not a OrderedDict.

----------

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

From report at bugs.python.org  Sat Feb  2 10:05:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 09:05:19 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1359795919.85.0.165954264571.issue12568@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In this part of width.py,
        w = unicodedata.east_asian_width(c)
        if c == 'A':
            # ambiguous
            raise ValueError("ambiguous character %x" % (ord(c)))

I presume that 'c' should be 'w'.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  2 10:11:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 09:11:19 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359796279.24.0.604271302584.issue17100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> But rotate_at() / rotate_after() can probably be O(1), unless I'm missing something.

Hmm, perhaps. But only for current implementation. With more effective deque-like implementation (when linked list items grouped in fixed-size chunks) it will be O(n).

----------

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

From report at bugs.python.org  Sat Feb  2 10:22:38 2013
From: report at bugs.python.org (gheorghe mosteoru)
Date: Sat, 02 Feb 2013 09:22:38 +0000
Subject: [issue17103] ampersand "&" in path prevents from compiling pthon
Message-ID: <1359796958.56.0.232245529308.issue17103@psf.upfronthosting.co.za>


New submission from gheorghe mosteoru:

I've be trying to compile python in a folder which had '&' (ampersand) in the path and i couldn't. 

First configure got some weird output:

configure: creating ./config.status
config.status: creating Makefile.pre
sed: -e expression #1, char 435: unknown option to `s'
config.status: creating Modules/Setup.config
sed: -e expression #1, char 447: unknown option to `s'
config.status: creating Misc/python.pc
sed: -e expression #1, char 438: unknown option to `s'
config.status: creating Misc/python-config.sh
sed: -e expression #1, char 452: unknown option to `s'
config.status: creating Modules/ld_so_aix
sed: -e expression #1, char 441: unknown option to `s'
config.status: creating pyconfig.h
creating Modules/Setup
creating Modules/Setup.local
creating Makefile

Then when I've run make I've got:

make: *** No rule to make target `/Modules/posixmodule.c', needed by `Modules/posixmodule.o'.  Stop.

----------
components: Build
messages: 181151
nosy: gheorghe.mosteoru
priority: normal
severity: normal
status: open
title: ampersand "&" in path prevents from compiling pthon
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  2 10:22:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 09:22:42 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359796279.24.0.604271302584.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359796789.3476.9.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > But rotate_at() / rotate_after() can probably be O(1), unless I'm
> missing something.
> 
> Hmm, perhaps. But only for current implementation. With more effective
> deque-like implementation (when linked list items grouped in
> fixed-size chunks) it will be O(n).

Does your deque-like implementation preserve O(1) deletion?

----------

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

From report at bugs.python.org  Sat Feb  2 10:28:36 2013
From: report at bugs.python.org (zephyr)
Date: Sat, 02 Feb 2013 09:28:36 +0000
Subject: [issue17104] Tk() not defined in Tkinter module
Message-ID: <1359797316.8.0.0796335939383.issue17104@psf.upfronthosting.co.za>


New submission from zephyr:

There are two cases of this issues:

1)Terminal-importing the Tkinter module and creating a Tk() object runs fine for the first instance but exiting the interpreter and trying to create a object for the next instance gives error:'Tk() is not defined'

2)IDE-importing the Tkinter module and creating a Tk() object produces error-'Tk() is not defined'.

----------
components: None
messages: 181153
nosy: zephyr
priority: normal
severity: normal
status: open
title: Tk() not defined in Tkinter module
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Sat Feb  2 10:41:36 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 09:41:36 +0000
Subject: [issue17048] calendar should understand full- vs. half-width
	characters
In-Reply-To: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za>
Message-ID: <1359798096.85.0.928898403793.issue17048@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For this particular East Asian local, the problem is the double spacing between the double-width characters (the Chinese numbers 1 to 7). This is potentially easily fixed for this locale. But do all locales have abbreviated weekday names that fit in 2 columns?

In looking at whether this issue should be classified as a bug or feature issue, I only found this:
'''
 class calendar.LocaleTextCalendar(firstweekday=0, locale=None)

    This subclass of TextCalendar can be passed a locale name in the constructor and will return month and weekday names in the specified locale.'''

The current code does this, though not gracefully. I suspect that adding "-t html" to the command line, to use class calendar.LocaleHTMLCalendar, would work better.

[Doc note 1: I suspect the next sentence "If this locale includes an encoding all strings containing month and weekday names will be returned as unicode.", which is unchanged from 2.x, is obsolete and perhaps should just be removed.

Doc note 2: I could not find any doc for the command line interface in 
8.2. calendar ? General calendar-related functions. Unless I am missing something, a new section should be added.]

#12568 will add a new feature that will only go in the 'next' release. So if this issue depends on that issue, it is effectively a new feature also.

----------
nosy: +rhettinger, terry.reedy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4 -Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Feb  2 10:53:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 09:53:25 +0000
Subject: [issue17060] IDLE -- jump to home should not go past the PS1 and PS2
	prompts
In-Reply-To: <1359364664.26.0.133025400757.issue17060@psf.upfronthosting.co.za>
Message-ID: <1359798805.59.0.24092013878.issue17060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On my Win 7 system, with 3.3.0, the first Home sends the cursor to the beginning of the user entry, after '>>> '. The second sends it to the beginning of the display line. And so forth, as intended. See #3851. (It worked the same with Win xp and 3.1) If are getting different behavior, what os and py versions?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Feb  2 10:55:36 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 09:55:36 +0000
Subject: [issue17061] tokenize unconditionally emits NL after comment lines &
	blank lines
In-Reply-To: <1359371668.59.0.445577508897.issue17061@psf.upfronthosting.co.za>
Message-ID: <1359798936.89.0.945914640484.issue17061@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Sat Feb  2 11:01:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 10:01:37 +0000
Subject: [issue17068] peephole optimization for constant strings
In-Reply-To: <1359411544.64.0.96683095685.issue17068@psf.upfronthosting.co.za>
Message-ID: <1359799297.63.0.231158254594.issue17068@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It would also be nice to optimize '{}{}{}'.format('https://', host, uri).
Either seems a bit much to ask from a fairly naive compiler :-).

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.4

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

From report at bugs.python.org  Sat Feb  2 11:19:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 10:19:59 +0000
Subject: [issue11159] Sax parser crashes if given unicode file name
In-Reply-To: <1297261203.08.0.513476017898.issue11159@psf.upfronthosting.co.za>
Message-ID: <3Yyrlf3js3zQSc@mail.python.org>


Roundup Robot added the comment:

New changeset 706218e0facb by Serhiy Storchaka in branch '2.7':
Fix tests for issue #11159.
http://hg.python.org/cpython/rev/706218e0facb

New changeset a7c074d9cbfb by Serhiy Storchaka in branch '3.2':
Fix tests for issue #11159.
http://hg.python.org/cpython/rev/a7c074d9cbfb

New changeset 2bf01f03ff40 by Serhiy Storchaka in branch '3.3':
Fix tests for issue #11159.
http://hg.python.org/cpython/rev/2bf01f03ff40

New changeset 4ab386b00aaf by Serhiy Storchaka in branch 'default':
Fix tests for issue #11159.
http://hg.python.org/cpython/rev/4ab386b00aaf

----------

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

From report at bugs.python.org  Sat Feb  2 11:31:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 10:31:30 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3Yys0x3G9BzPP5@mail.python.org>


Roundup Robot added the comment:

New changeset c3ab8a698d2f by Serhiy Storchaka in branch '2.7':
Fix translating of illegal characters on Windows (issue #6972).
http://hg.python.org/cpython/rev/c3ab8a698d2f

----------

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

From report at bugs.python.org  Sat Feb  2 12:07:17 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Feb 2013 11:07:17 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359803237.56.0.860331268169.issue6972@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The patch introduced a Cyrillic "C" into the docs, see below.  This makes the LaTeX build fail.

+      ``foo/bar`` on Unix, and ``??:\foo\bar`` becomes ``foo\bar`` on Windows.
                                  ^^

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

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

From report at bugs.python.org  Sat Feb  2 12:12:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 11:12:50 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359796789.3476.9.camel@localhost.localdomain>
Message-ID: <201302021312.33734.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Does your deque-like implementation preserve O(1) deletion?

Ah, OrderedDict should provide O(1) deletion for arbitrary key. Then deque-
like implementation should use variable-size chunks and rotate_at() / 
rotate_after() are possible with O(1).

----------

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

From report at bugs.python.org  Sat Feb  2 12:18:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 11:18:08 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359803888.79.0.363316954918.issue6972@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are different test fails on Windows:

http://buildbot.python.org/all/builders/x86%20XP-5%203.3/builds/405/steps/test/logs/stdio
======================================================================
ERROR: test_extract_hackers_arcnames (test.test_zipfile.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\Buildslave\3.3.moore-windows\build\lib\test\test_zipfile.py", line 585, in test_extract_hackers_arcnames
    writtenfile = zipfp.extract(arcname, targetpath)
  File "D:\Buildslave\3.3.moore-windows\build\lib\zipfile.py", line 1212, in extract
    return self._extract_member(member, path, pwd)
  File "D:\Buildslave\3.3.moore-windows\build\lib\zipfile.py", line 1253, in _extract_member
    os.makedirs(upperdirs)
  File "D:\Buildslave\3.3.moore-windows\build\lib\os.py", line 269, in makedirs
    mkdir(name, mode)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'target\\subdir\\subsub\\foo'

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.3/builds/428/steps/test/logs/stdio
======================================================================
FAIL: test_extract_hackers_arcnames (test.test_zipfile.TestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.3.kloth-win64\build\lib\test\test_zipfile.py", line 586, in test_extract_hackers_arcnames
    self.assertEqual(writtenfile, correctfile)
AssertionError: 'target\\subdir\\subsub' != 'target\\subdir\\subsub\\foo\\bar'
- target\subdir\subsub
+ target\subdir\subsub\foo\bar
?                     ++++++++

----------

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

From report at bugs.python.org  Sat Feb  2 12:30:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 11:30:28 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3YytK00TNqzPyc@mail.python.org>


Roundup Robot added the comment:

New changeset b6b707063991 by Serhiy Storchaka in branch '2.7':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/b6b707063991

New changeset ede0f27988f2 by Serhiy Storchaka in branch '3.2':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/ede0f27988f2

New changeset 785b8b49c3bf by Serhiy Storchaka in branch '3.3':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/785b8b49c3bf

New changeset 25294188c4ea by Serhiy Storchaka in branch 'default':
Fix a Cyrillic "C" inroduced into the docs by patch for issue #6972.
http://hg.python.org/cpython/rev/25294188c4ea

----------

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

From report at bugs.python.org  Sat Feb  2 12:31:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 11:31:17 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359804677.85.0.440917622894.issue6972@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The patch introduced a Cyrillic "C" into the docs, see below.

Thank you. Fixed.

----------

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

From report at bugs.python.org  Sat Feb  2 12:54:26 2013
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgQXR0aWxhIFTDs3Ro?=)
Date: Sat, 02 Feb 2013 11:54:26 +0000
Subject: [issue13966] Add disable_interspersed_args() to
	argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1359806066.37.0.823347202978.issue13966@psf.upfronthosting.co.za>


L?szl? Attila T?th added the comment:

Unfortunatelly the implementation bugous as of now. I wrote additional tests.

self.parser = ErrorRaisingArgumentParser()
self.parser.add_argument('-a', action='store_true')
self.parser.add_argument('-b')
self.parser.add_argument('rem', nargs=argparse.REMAINDER)
self.assertEquals(self.parser.parse_args('-b 4 -a  -b 5'.split()), NS(a=True, b='5', rem=[]))

This part is OK. But with the new option:
self.parser.disable_interspersed_args()
self.assertEquals(self.parser.parse_args('-b 4 -a -b 5'.split()), NS(a=False, b='4',  rem=['-a', '-b', '5']))

This assertation also passes because it contains the actual result, which is unexpected. This is because the code doesn't handle properly the arguments that are non-options, such as '-b' in this case.

I can't see a good solution for this.

----------

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

From report at bugs.python.org  Sat Feb  2 13:24:29 2013
From: report at bugs.python.org (Petre)
Date: Sat, 02 Feb 2013 12:24:29 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1359807869.77.0.0873837670224.issue1100942@psf.upfronthosting.co.za>


Changes by Petre <pmierlutiu at cmedtechnology.com>:


----------
nosy: +petre

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

From report at bugs.python.org  Sat Feb  2 13:41:21 2013
From: report at bugs.python.org (gheorghe mosteoru)
Date: Sat, 02 Feb 2013 12:41:21 +0000
Subject: [issue17103] ampersand "&" in path prevents from compiling pthon
In-Reply-To: <1359796958.56.0.232245529308.issue17103@psf.upfronthosting.co.za>
Message-ID: <1359808881.98.0.00477266563629.issue17103@psf.upfronthosting.co.za>


gheorghe mosteoru added the comment:

I think this might be a bug in autoconf:

http://lists.gnu.org/archive/html/bug-autoconf/2012-08/msg00000.html


The latest version of autoconf gives me a message when I try to run configure (for autoconf code itself) in that directory

checking whether build environment is sane... configure: error: unsafe absolute working directory name

----------

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

From report at bugs.python.org  Sat Feb  2 14:20:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 13:20:41 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1359803888.79.0.363316954918.issue6972@psf.upfronthosting.co.za>
Message-ID: <201302021520.18160.storchaka@gmail.com>


Serhiy Storchaka added the comment:

Here are patches which possible fixes some of this failures.

----------
Added file: http://bugs.python.org/file28932/zipfile_fix_arcname_4-2.7.patch
Added file: http://bugs.python.org/file28933/zipfile_fix_arcname_4-3.x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________
-------------- next part --------------
diff -r b6b707063991 Lib/test/test_zipfile.py
--- a/Lib/test/test_zipfile.py	Sat Feb 02 13:27:02 2013 +0200
+++ b/Lib/test/test_zipfile.py	Sat Feb 02 15:07:52 2013 +0200
@@ -434,8 +434,6 @@
             ('/foo/bar', 'foo/bar'),
             ('/foo/../bar', 'foo/bar'),
             ('/foo/../../bar', 'foo/bar'),
-            ('//foo/bar', 'foo/bar'),
-            ('../../foo../../ba..r', 'foo../ba..r'),
         ]
         if os.path.sep == '\\':
             hacknames.extend([
@@ -447,16 +445,22 @@
                 (r'C:/foo/bar', 'foo/bar'),
                 (r'C://foo/bar', 'foo/bar'),
                 (r'C:\foo\bar', 'foo/bar'),
-                (r'//conky/mountpoint/foo/bar', 'foo/bar'),
-                (r'\\conky\mountpoint\foo\bar', 'foo/bar'),
+                (r'//conky/mountpoint/foo/bar', 'conky/mountpoint/foo/bar'),
+                (r'\\conky\mountpoint\foo\bar', 'conky/mountpoint/foo/bar'),
                 (r'///conky/mountpoint/foo/bar', 'conky/mountpoint/foo/bar'),
                 (r'\\\conky\mountpoint\foo\bar', 'conky/mountpoint/foo/bar'),
                 (r'//conky//mountpoint/foo/bar', 'conky/mountpoint/foo/bar'),
                 (r'\\conky\\mountpoint\foo\bar', 'conky/mountpoint/foo/bar'),
-                (r'//?/C:/foo/bar', 'foo/bar'),
-                (r'\\?\C:\foo\bar', 'foo/bar'),
+                (r'//?/C:/foo/bar', '_/C_/foo/bar'),
+                (r'\\?\C:\foo\bar', '_/C_/foo/bar'),
                 (r'C:/../C:/foo/bar', 'C_/foo/bar'),
                 (r'a:b\c<d>e|f"g?h*i', 'b/c_d_e_f_g_h_i'),
+                ('../../foo../../ba..r', 'foo/ba..r'),
+            ])
+        else:  # Unix
+            hacknames.extend([
+                ('//foo/bar', 'foo/bar'),
+                ('../../foo../../ba..r', 'foo../ba..r'),
             ])
 
         for arcname, fixedname in hacknames:
@@ -469,7 +473,8 @@
 
             with zipfile.ZipFile(TESTFN2, 'r') as zipfp:
                 writtenfile = zipfp.extract(arcname, targetpath)
-                self.assertEqual(writtenfile, correctfile)
+                self.assertEqual(writtenfile, correctfile,
+                                 msg="extract %r" % arcname)
             self.check_file(correctfile, content)
             shutil.rmtree('target')
 
@@ -482,7 +487,8 @@
 
             with zipfile.ZipFile(TESTFN2, 'r') as zipfp:
                 writtenfile = zipfp.extract(arcname)
-                self.assertEqual(writtenfile, correctfile)
+                self.assertEqual(writtenfile, correctfile,
+                                 msg="extract %r" % arcname)
             self.check_file(correctfile, content)
             shutil.rmtree(fixedname.split('/')[0])
 
diff -r b6b707063991 Lib/zipfile.py
--- a/Lib/zipfile.py	Sat Feb 02 13:27:02 2013 +0200
+++ b/Lib/zipfile.py	Sat Feb 02 15:07:52 2013 +0200
@@ -1050,11 +1050,14 @@
         arcname = os.path.splitdrive(arcname)[1]
         arcname = os.path.sep.join(x for x in arcname.split(os.path.sep)
                     if x not in ('', os.path.curdir, os.path.pardir))
-        # filter illegal characters on Windows
         if os.path.sep == '\\':
+            # filter illegal characters on Windows
             illegal = ':<>|"?*'
             table = string.maketrans(illegal, '_' * len(illegal))
             arcname = arcname.translate(table)
+            # remove trailing dots
+            arcname = (x.rstrip('.') for x in arcname.split(os.path.sep))
+            arcname = os.path.sep.join(x for x in arcname if x)
 
         targetpath = os.path.join(targetpath, arcname)
         targetpath = os.path.normpath(targetpath)
-------------- next part --------------
diff -r 25294188c4ea Lib/test/test_zipfile.py
--- a/Lib/test/test_zipfile.py	Sat Feb 02 13:28:42 2013 +0200
+++ b/Lib/test/test_zipfile.py	Sat Feb 02 15:08:04 2013 +0200
@@ -548,8 +548,6 @@
             ('/foo/bar', 'foo/bar'),
             ('/foo/../bar', 'foo/bar'),
             ('/foo/../../bar', 'foo/bar'),
-            ('//foo/bar', 'foo/bar'),
-            ('../../foo../../ba..r', 'foo../ba..r'),
         ]
         if os.path.sep == '\\':  # Windows.
             hacknames.extend([
@@ -571,6 +569,12 @@
                 (r'\\?\C:\foo\bar', 'foo/bar'),
                 (r'C:/../C:/foo/bar', 'C_/foo/bar'),
                 (r'a:b\c<d>e|f"g?h*i', 'b/c_d_e_f_g_h_i'),
+                ('../../foo../../ba..r', 'foo/ba..r'),
+            ])
+        else:  # Unix
+            hacknames.extend([
+                ('//foo/bar', 'foo/bar'),
+                ('../../foo../../ba..r', 'foo../ba..r'),
             ])
 
         for arcname, fixedname in hacknames:
@@ -583,7 +587,8 @@
 
             with zipfile.ZipFile(TESTFN2, 'r') as zipfp:
                 writtenfile = zipfp.extract(arcname, targetpath)
-                self.assertEqual(writtenfile, correctfile)
+                self.assertEqual(writtenfile, correctfile,
+                                 msg="extract %r" % arcname)
             self.check_file(correctfile, content)
             shutil.rmtree('target')
 
@@ -596,7 +601,8 @@
 
             with zipfile.ZipFile(TESTFN2, 'r') as zipfp:
                 writtenfile = zipfp.extract(arcname)
-                self.assertEqual(writtenfile, correctfile)
+                self.assertEqual(writtenfile, correctfile,
+                                 msg="extract %r" % arcname)
             self.check_file(correctfile, content)
             shutil.rmtree(fixedname.split('/')[0])
 
diff -r 25294188c4ea Lib/zipfile.py
--- a/Lib/zipfile.py	Sat Feb 02 13:28:42 2013 +0200
+++ b/Lib/zipfile.py	Sat Feb 02 15:08:04 2013 +0200
@@ -1238,11 +1238,14 @@
         arcname = os.path.splitdrive(arcname)[1]
         arcname = os.path.sep.join(x for x in arcname.split(os.path.sep)
                     if x not in ('', os.path.curdir, os.path.pardir))
-        # filter illegal characters on Windows
         if os.path.sep == '\\':
+            # filter illegal characters on Windows
             illegal = ':<>|"?*'
             table = str.maketrans(illegal, '_' * len(illegal))
             arcname = arcname.translate(table)
+            # remove trailing dots
+            arcname = (x.rstrip('.') for x in arcname.split(os.path.sep))
+            arcname = os.path.sep.join(x for x in arcname if x)
 
         targetpath = os.path.join(targetpath, arcname)
         targetpath = os.path.normpath(targetpath)

From report at bugs.python.org  Sat Feb  2 14:37:18 2013
From: report at bugs.python.org (Radu Ciorba)
Date: Sat, 02 Feb 2013 13:37:18 +0000
Subject: [issue16142] ArgumentParser inconsistent with parse_known_args
In-Reply-To: <1349448801.58.0.783623579173.issue16142@psf.upfronthosting.co.za>
Message-ID: <1359812238.23.0.466821822642.issue16142@psf.upfronthosting.co.za>


Radu Ciorba added the comment:

"- if the unknown option is given first then both options are treated as unknown and returned in the list of remaining arguments."
I don't think this case is correct behaviour. There is no way to determine if u accepts arguments or not. If nargs for -u is "?" or more, the current behavior is correct since everything after -u would be an argument for this option.

----------
nosy: +Radu.Ciorba

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

From report at bugs.python.org  Sat Feb  2 14:42:02 2013
From: report at bugs.python.org (Andrei Vereha)
Date: Sat, 02 Feb 2013 13:42:02 +0000
Subject: [issue16142] ArgumentParser inconsistent with parse_known_args
In-Reply-To: <1349448801.58.0.783623579173.issue16142@psf.upfronthosting.co.za>
Message-ID: <1359812522.38.0.652078899451.issue16142@psf.upfronthosting.co.za>


Changes by Andrei Vereha <avereha at gmail.com>:


----------
nosy: +Andrei.Vereha

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

From report at bugs.python.org  Sat Feb  2 14:42:32 2013
From: report at bugs.python.org (Radu Ciorba)
Date: Sat, 02 Feb 2013 13:42:32 +0000
Subject: [issue16468] argparse only supports iterable choices
In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za>
Message-ID: <1359812552.09.0.686782991818.issue16468@psf.upfronthosting.co.za>


Changes by Radu Ciorba <raduciorba at gmail.com>:


----------
nosy: +Radu.Ciorba

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

From report at bugs.python.org  Sat Feb  2 15:12:13 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 14:12:13 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
	path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1359814333.71.0.503381400941.issue17102@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please see issue issue 1044.  I have no opinion here, I just remembered that this had been discussed before.

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

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

From report at bugs.python.org  Sat Feb  2 15:21:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 14:21:20 +0000
Subject: [issue17104] Tk() not defined in Tkinter module
In-Reply-To: <1359797316.8.0.0796335939383.issue17104@psf.upfronthosting.co.za>
Message-ID: <1359814880.31.0.053556633882.issue17104@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please provide a complete example of the failures.  Your report doesn't currently provide enough information to reproduce the reported issue.

If the reported error message is accurate, it looks at first glance like the error message at least could use some improvement, since (at least as a non-tkinter user) I have no idea what it would mean for Tk() to be defined, since it isn't a Python identifier.  On the other hand, if that error message comes from Tk itself and not Python, then it is probably correct.

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

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

From report at bugs.python.org  Sat Feb  2 16:45:23 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 15:45:23 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1359744780.73.0.720333207075.issue13756@psf.upfronthosting.co.za>
Message-ID: <510D3490.2040303@roumenpetrov.info>


Roumen Petrov added the comment:

Jason Tishler wrote:
> Jason Tishler added the comment:
>
>> Is this still an issue on 3.3/3.4?
> I presume so.
This build is broken since SOABI implementation.
>
>> Does the patch still work?
> I haven't tried it on 3.3 yet, so I don't know if it will apply cleanly.
Attached "0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch" for head.
This patch is part of split issue3871 into small independent changes.

Roumen

----------
Added file: http://bugs.python.org/file28934/0001-CYGWIN-issue13756-Python-make-fail-on-cygwin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13756>
_______________________________________
-------------- next part --------------
>From 23031e941eaab013ef65ed7b2cdb08742a72e68d Mon Sep 17 00:00:00 2001
From: Roumen Petrov <local at example.net>
Date: Sat, 2 Feb 2013 00:04:12 +0200
Subject: [PATCH 1/5] CYGWIN-issue13756: Python make fail on cygwin

---
 Lib/distutils/command/build_ext.py | 7 -------
 Makefile.pre.in                    | 4 ++--
 Modules/makesetup                  | 2 +-
 3 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/Lib/distutils/command/build_ext.py b/Lib/distutils/command/build_ext.py
index f7c71b3..eac04a5 100644
--- a/Lib/distutils/command/build_ext.py
+++ b/Lib/distutils/command/build_ext.py
@@ -705,13 +705,6 @@ class build_ext(Command):
                 return ext.libraries + [pythonlib]
             else:
                 return ext.libraries
-        elif sys.platform[:6] == "cygwin":
-            template = "python%d.%d"
-            pythonlib = (template %
-                   (sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff))
-            # don't extend ext.libraries, it may be shared with other
-            # extensions, it is a reference to the original list
-            return ext.libraries + [pythonlib]
         elif sys.platform[:6] == "atheos":
             from distutils import sysconfig
 
diff --git a/Makefile.pre.in b/Makefile.pre.in
index 9570730..5190f4f 100644
--- a/Makefile.pre.in
+++ b/Makefile.pre.in
@@ -556,9 +556,9 @@ $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK): \
 	$(LN) -fsn Versions/Current/$(PYTHONFRAMEWORK) $(PYTHONFRAMEWORKDIR)/$(PYTHONFRAMEWORK)
 	$(LN) -fsn Versions/Current/Resources $(PYTHONFRAMEWORKDIR)/Resources
 
-# This rule builds the Cygwin Python DLL and import library if configured
+# This rule builds the Python DLL and import library if configured
 # for a shared core library; otherwise, this rule is a noop.
-$(DLLLIBRARY) libpython$(VERSION).dll.a: $(LIBRARY_OBJS)
+$(DLLLIBRARY) libpython$(LDVERSION).dll.a: $(LIBRARY_OBJS)
 	if test -n "$(DLLLIBRARY)"; then \
 		$(LDSHARED) -Wl,--out-implib=$@ -o $(DLLLIBRARY) $^ \
 			$(LIBS) $(MODLIBS) $(SYSLIBS) $(LDLAST); \
diff --git a/Modules/makesetup b/Modules/makesetup
index 40dfa9d..1a1fcf6 100755
--- a/Modules/makesetup
+++ b/Modules/makesetup
@@ -91,7 +91,7 @@ CYGWIN*) if test $libdir = .
 	 else
 	 	ExtraLibDir='$(LIBPL)'
 	 fi
-	 ExtraLibs="-L$ExtraLibDir -lpython\$(VERSION)";;
+	 ExtraLibs="-L$ExtraLibDir -lpython\$(LDVERSION)";;
 esac
 
 # Main loop
-- 
1.7.12.1


From report at bugs.python.org  Sat Feb  2 16:47:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 15:47:15 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3Yz01G2sbDzPx1@mail.python.org>


Roundup Robot added the comment:

New changeset ebef003a2acd by Serhiy Storchaka in branch '2.7':
Fix the test and remove trailing dots on Windows for issue #6972.
http://hg.python.org/cpython/rev/ebef003a2acd

----------

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

From report at bugs.python.org  Sat Feb  2 17:10:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 16:10:18 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <3Yz0Ws6JYCzSLs@mail.python.org>


Roundup Robot added the comment:

New changeset c73a1f96dd9b by Gregory P. Smith in branch '2.7':
Update the embedded copy of the expat XML parser to 2.1.0.  It brings
http://hg.python.org/cpython/rev/c73a1f96dd9b

----------

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

From report at bugs.python.org  Sat Feb  2 17:10:52 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Feb 2013 16:10:52 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1359821452.88.0.103480490347.issue14340@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Feb  2 17:17:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 16:17:08 +0000
Subject: [issue15881] multiprocessing 'NoneType' object is not callable
In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za>
Message-ID: <3Yz0gl5Mj4zSPg@mail.python.org>


Roundup Robot added the comment:

New changeset 0a58fa8e9bac by Benjamin Peterson in branch '2.7':
Issue #15881: Fixed atexit hook in multiprocessing.
http://hg.python.org/cpython/rev/0a58fa8e9bac

----------

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

From report at bugs.python.org  Sat Feb  2 17:17:20 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Feb 2013 16:17:20 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1359821840.49.0.140251840176.issue14340@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Then I guess there is no reason not to put it in 3.2.4.

----------

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

From report at bugs.python.org  Sat Feb  2 17:18:07 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 16:18:07 +0000
Subject: [issue15483] CROSS: initialise include and library paths in setup.py
In-Reply-To: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za>
Message-ID: <1359821887.35.0.264801678678.issue15483@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

I agree that current directory in library search path is different issue so I'm closing as fixed.

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

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

From report at bugs.python.org  Sat Feb  2 17:18:46 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Feb 2013 16:18:46 +0000
Subject: [issue15881] multiprocessing 'NoneType' object is not callable
In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za>
Message-ID: <1359821926.66.0.214385296542.issue15881@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Feb  2 17:18:57 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Feb 2013 16:18:57 +0000
Subject: [issue15881] multiprocessing 'NoneType' object is not callable
In-Reply-To: <1347044200.13.0.235512745295.issue15881@psf.upfronthosting.co.za>
Message-ID: <1359821937.96.0.646843737742.issue15881@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Feb  2 17:28:59 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Feb 2013 16:28:59 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1359822539.79.0.607487488045.issue13994@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

It's not clear to me at all what needs to happen here, so I'm just going to have to drop it for 2.7.4.

----------
priority: release blocker -> normal

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

From report at bugs.python.org  Sat Feb  2 17:33:59 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 16:33:59 +0000
Subject: [issue15819] Unable to build Python out-of-tree when source tree
	is	readonly.
In-Reply-To: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za>
Message-ID: <1359822839.11.0.170291925846.issue15819@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

To update .hgtouch is not enough.
Grammar, AST and importlib should left in source tree as before.

----------
nosy: +rpetrov

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

From report at bugs.python.org  Sat Feb  2 17:34:34 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 16:34:34 +0000
Subject: [issue15483] CROSS: initialise include and library paths in setup.py
In-Reply-To: <1343554833.66.0.976178324221.issue15483@psf.upfronthosting.co.za>
Message-ID: <1359822874.27.0.482746839991.issue15483@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


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

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

From report at bugs.python.org  Sat Feb  2 17:35:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 16:35:41 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3Yz1585HNKzSMV@mail.python.org>


Roundup Robot added the comment:

New changeset 5a68052b52ea by Serhiy Storchaka in branch '2.7':
Preserve backslashes in malicious zip files for testing issue #6972.
http://hg.python.org/cpython/rev/5a68052b52ea

----------

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

From report at bugs.python.org  Sat Feb  2 17:48:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 16:48:22 +0000
Subject: [issue17034] Use Py_CLEAR() in stringobject.c and bytesobject.c
In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za>
Message-ID: <3Yz1Mn38QxzSMx@mail.python.org>


Roundup Robot added the comment:

New changeset 4d120cea3507 by Serhiy Storchaka in branch '2.7':
Issue #17034: Use Py_CLEAR() in stringobject.c.
http://hg.python.org/cpython/rev/4d120cea3507

New changeset 8a747dec89c5 by Serhiy Storchaka in branch '3.2':
Issue #17034: Use Py_CLEAR() in bytesobject.c.
http://hg.python.org/cpython/rev/8a747dec89c5

New changeset 7e34c176aa6f by Serhiy Storchaka in branch '3.3':
Issue #17034: Use Py_CLEAR() in bytesobject.c.
http://hg.python.org/cpython/rev/7e34c176aa6f

New changeset 33bef5e211af by Serhiy Storchaka in branch 'default':
Issue #17034: Use Py_CLEAR() in bytesobject.c.
http://hg.python.org/cpython/rev/33bef5e211af

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Feb  2 17:51:13 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 16:51:13 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1359823873.12.0.77523139666.issue3754@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

I agree that cross-compilation is now usable.
Issues related to build and test outside source tree more or less are permanent but out of cross-compilation scope.
Also parts of patches posted in this issue now are in separate defects or enhancements.

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

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

From report at bugs.python.org  Sat Feb  2 17:53:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 16:53:16 +0000
Subject: [issue17034] Use Py_CLEAR() in stringobject.c and bytesobject.c
In-Reply-To: <1359144891.77.0.961082315571.issue17034@psf.upfronthosting.co.za>
Message-ID: <1359823996.81.0.310392358156.issue17034@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually it is a part of issue16445 or issue16447. Now they will be a little smaller.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  2 18:08:01 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 17:08:01 +0000
Subject: [issue3871] cross and native build of python for mingw* hosts
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1359824881.13.0.791144125641.issue3871@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Please do not post to this thread.
Follow python bugs list for result of patch-split. I will try to post parts of this patch to already opened issues or to open new one if necessary.

As basis will be used py3k-20121004-MINGW.patch with following main changes:
- prefer posix installation scheme
- use of system libffi

Lets keep issue open as reference until is reached usable level.

----------
components: +Build -Cross-Build

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

From report at bugs.python.org  Sat Feb  2 18:23:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 17:23:58 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359825838.42.0.402568594164.issue17100@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Sat Feb  2 18:26:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 17:26:54 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3Yz2DG0BlzzPyc@mail.python.org>


Roundup Robot added the comment:

New changeset ab4b8da79a5f by Serhiy Storchaka in branch '2.7':
Fix test for issue #6972.
http://hg.python.org/cpython/rev/ab4b8da79a5f

----------

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

From report at bugs.python.org  Sat Feb  2 18:38:44 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 17:38:44 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359826724.85.0.257742832191.issue17100@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please don't rush to make patches.  It isn't even clear that this is a good idea.

AFAICT, none of the many extant implementation of ordered dictionaries in any language currently implement a rotate operation.

FWIW, the iter() and move_to_end() methods are likely your best bet for implementing a rotate function using the current API and without doing any ordered dictionary key lookups:

>>> from collections import OrderedDict
>>> from itertools import islice
>>> 
>>> def rotate(d, n):
    # quick demo
    if n > 0:
        for k in list(islice(d, n)):
            d.move_to_end(k)
    elif n < 0:
        for k in list(islice(reversed(d), -n)):
            d.move_to_end(k, 0)
           
>>> d = collections.OrderedDict.fromkeys('abcdefghijk')
>>> list(d)
['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k']
>>> rotate(d, 3)
>>> list(d)
['d', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'a', 'b', 'c']
>>> rotate(d, -3)
>>> list(d)
['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k']

----------

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

From report at bugs.python.org  Sat Feb  2 18:44:25 2013
From: report at bugs.python.org (Ray Donnelly)
Date: Sat, 02 Feb 2013 17:44:25 +0000
Subject: [issue3871] cross and native build of python for mingw* hosts
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1359827065.3.0.163171089147.issue3871@psf.upfronthosting.co.za>


Ray Donnelly added the comment:

Great Roumen, please split into new issues then make a new overall tracking issue, then this one can be left for historians and archaeologists.

For Posix installation scheme I've got:

https://github.com/niXman/mingw-builds/blob/master/patches/Python-3.3.0/0050-mingw-sysconfig-like-posix.patch

It needs some changes to allow for normal NT scheme when not using MinGW though.

For system libffi there's:

https://github.com/niXman/mingw-builds/blob/master/patches/Python-3.3.0/0035-mingw-system-libffi.patch

When you make your new patches I will base a new set of patches on them.

----------

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

From report at bugs.python.org  Sat Feb  2 18:44:53 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 17:44:53 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1359827093.21.0.498054249031.issue17100@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: http://bugs.python.org/msg181184

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

From report at bugs.python.org  Sat Feb  2 18:46:28 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 17:46:28 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1359827188.29.0.124390117358.issue1597850@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Proposed patch is mostly for cross compilation in general. Now this is implemented differently and I think that all proposed updates are already addressed.

Also I can not  see relation with gcc( mingw ) builds.

What about to close issue as fixed ?

----------

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

From report at bugs.python.org  Sat Feb  2 18:52:01 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 02 Feb 2013 17:52:01 +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: <1359827521.52.0.853937018678.issue6672@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Version against current (2013-02-02) source.

----------
versions: +Python 3.4
Added file: http://bugs.python.org/file28935/0002-MINGW-issue6672-add-mingw-recognition-to-pyport.h-to.patch

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

From report at bugs.python.org  Sat Feb  2 18:54:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 17:54:15 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3Yz2qp6wsNzPmY@mail.python.org>


Roundup Robot added the comment:

New changeset 434b50c7bbed by Serhiy Storchaka in branch '3.2':
Fix the test for issue #6972.
http://hg.python.org/cpython/rev/434b50c7bbed

New changeset 8b33f3a4a200 by Serhiy Storchaka in branch '3.3':
Fix the test for issue #6972.
http://hg.python.org/cpython/rev/8b33f3a4a200

New changeset 7a47fd7f2fdc by Serhiy Storchaka in branch 'default':
Fix the test for issue #6972.
http://hg.python.org/cpython/rev/7a47fd7f2fdc

----------

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

From report at bugs.python.org  Sat Feb  2 18:56:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 17:56:20 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <3Yz2tC5nTszPNH@mail.python.org>


Roundup Robot added the comment:

New changeset f7b01daffe01 by Raymond Hettinger in branch 'default':
Issue 16398: Use memcpy() in deque.rotate().
http://hg.python.org/cpython/rev/f7b01daffe01

----------

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

From report at bugs.python.org  Sat Feb  2 19:03:34 2013
From: report at bugs.python.org (Damian)
Date: Sat, 02 Feb 2013 18:03:34 +0000
Subject: [issue17105] Python 3.2 segfault
Message-ID: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>


New submission from Damian:

Hi. While porting a library of mine (https://stem.torproject.org/) to python 3 I've been reliably encountering a python segmentation fault while running its integration tests. After many hours of head scratching I've narrowed the repro to the following script...

========================================

import queue
import socket

class Demo(object):
  def __init__(self, control_socket_file):
    demo_queue = queue.Queue()

    try:
      raise ValueError()
    except ValueError as exc:
      demo_queue.put(exc)

for i in range(20):
  control_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  control_socket.connect(("www.google.com", 80))
  control_socket_file = control_socket.makefile(mode = "rw", newline = "") 

  Demo(control_socket_file)

========================================

atagar at morrigan:~$ python3 --version
Python 3.2
atagar at morrigan:~$ python3 demo.py 
Segmentation fault

========================================

Yes, I realise that the script is stupidly convoluted but it was the minimal amount of code I could get to in order to reproduce the problem. Some things to note...

* You must have an object that gets a reference to an open socket based file.

* You need to have a try/catch block and enqueue that exception. If you get rid of the try/catch or enqueue something else then no segfault for you.

* The segfault isn't entirely reliable (seems so happen half the time or so), hence the loop.


While this repro script is pointless, it's the last issue preventing me from moving to python 3. At this point I'm out of idea so help would be greatly appreciated.

Thanks! -Damian

Python: Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)
Platform: Ubuntu 11.04

PS. If the advice is 'upgrade python, 3.2 had some segfault bugs' then a pointer to those bugs would be appreciated. I've sunk quite a few hours into this issue so it would be nice to finally figure out what's up.

----------
messages: 181190
nosy: atagar
priority: normal
severity: normal
status: open
title: Python 3.2 segfault
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  2 19:23:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 18:23:45 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <3Yz3Ts0R33zSTM@mail.python.org>


Roundup Robot added the comment:

New changeset cb5cde9e5ac5 by Raymond Hettinger in branch '2.7':
Issue 16398: Use memcpy() in deque.rotate().
http://hg.python.org/cpython/rev/cb5cde9e5ac5

----------

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

From report at bugs.python.org  Sat Feb  2 19:28:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 18:28:24 +0000
Subject: [issue16686] audioop overflow issues
In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>
Message-ID: <1359829704.34.0.969982830695.issue16686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since there is no one who want to review the patch for this dirty buggy module, I will test and review it myself yet once and then commit.

----------

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

From report at bugs.python.org  Sat Feb  2 19:32:32 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Feb 2013 18:32:32 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1359829952.74.0.612968707696.issue14340@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Then I guess there is no reason not to put it in 3.2.4.

----------

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

From report at bugs.python.org  Sat Feb  2 19:40:27 2013
From: report at bugs.python.org (Simon Law)
Date: Sat, 02 Feb 2013 18:40:27 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359830427.92.0.41409565917.issue16398@psf.upfronthosting.co.za>


Simon Law added the comment:

Raymond, looking at your patch, can we assert that deque->leftblock is never equal to deque->rightblock? If not, you need to use memmove() instead of memcpy(), which is unsafe for overlapping arrays.

It is not clear to me that this invariant is true. At the very least, an assertion should be there to protect future refactorings.

----------

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

From report at bugs.python.org  Sat Feb  2 19:43:21 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 02 Feb 2013 18:43:21 +0000
Subject: [issue17105] Python 3.2 segfault
In-Reply-To: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>
Message-ID: <1359830601.91.0.306146184791.issue17105@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks for the report. I cannot reproduce it with the latest 3.2 version.
Perhaps the version shipped with Ubuntu 11.04 has this problem.

----------
nosy: +doko, skrah

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

From report at bugs.python.org  Sat Feb  2 19:44:42 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 18:44:42 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359830682.55.0.720915480886.issue16398@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Even when leftblock == rightblock, a memcpy() will work fine.  When the block extends off the end, it *always* creates a newblock and never wraps around to the current block.  Data doesn't get overwritten in any scenario.

----------

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

From report at bugs.python.org  Sat Feb  2 19:46:31 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 18:46:31 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359830790.99.0.267216252565.issue16398@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also note, len>=1 and |n| < len//2, so even within a single block, memcpy() doesn't overwrite data.

----------

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

From report at bugs.python.org  Sat Feb  2 19:51:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 18:51:11 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359831071.54.0.687749078026.issue16398@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is possible to use only one new block (or even none). It should a little speed up rotate(). I will open a new issue when prepare a patch.

----------

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

From report at bugs.python.org  Sat Feb  2 19:55:57 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 02 Feb 2013 18:55:57 +0000
Subject: [issue17105] Python 3.2 segfault
In-Reply-To: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>
Message-ID: <1359831357.97.0.37512265511.issue17105@psf.upfronthosting.co.za>


Stefan Krah added the comment:

IOW, my advice is to get Python 3.3 from hg.python.org and see if
you can reproduce the issue.

----------

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

From report at bugs.python.org  Sat Feb  2 19:58:07 2013
From: report at bugs.python.org (Nadeem Vawda)
Date: Sat, 02 Feb 2013 18:58:07 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1359831487.2.0.642804857109.issue13886@psf.upfronthosting.co.za>


Nadeem Vawda added the comment:

You're right; it breaks backspacing over multibyte characters. I should
have tested it more carefully before committing. I'll revert the changes.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

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

From report at bugs.python.org  Sat Feb  2 20:05:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 19:05:19 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <3Yz4Pp4YPtzRXw@mail.python.org>


Roundup Robot added the comment:

New changeset e6952acd5a55 by Nadeem Vawda in branch '3.2':
Back out fix for issue #13886; it introduced a new bug in interactive readline use.
http://hg.python.org/cpython/rev/e6952acd5a55

----------

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

From report at bugs.python.org  Sat Feb  2 20:08:24 2013
From: report at bugs.python.org (Damian)
Date: Sat, 02 Feb 2013 19:08:24 +0000
Subject: [issue17105] Python 3.2 segfault
In-Reply-To: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>
Message-ID: <1359832104.38.0.223491052422.issue17105@psf.upfronthosting.co.za>


Damian added the comment:

Thanks. I snagged the 3.3 tarball from 'http://www.python.org/download/' after your first comment. Compilation just finished and it works there...

atagar at morrigan:~$ ~/Desktop/Python-3.3.0/python --version
Python 3.3.0
atagar at morrigan:~$ ~/Desktop/Python-3.3.0/python demo.py 

*sigh*

Feel free to resolve this ticket.

----------

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

From report at bugs.python.org  Sat Feb  2 20:18:04 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 02 Feb 2013 19:18:04 +0000
Subject: [issue17105] Python 3.2 segfault
In-Reply-To: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>
Message-ID: <1359832684.05.0.189673782123.issue17105@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks for testing. The problem with the Ubuntu Python

  "Python 3.2 (r32:88445, Oct 20 2012, 14:09:50)"

is that it seems to be a patched 3.2.0, while we're already at 3.2.3.


So it might be worth reporting this issue to Ubuntu.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  2 20:24:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 19:24:53 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <3Yz4rN3GpVzSRp@mail.python.org>


Roundup Robot added the comment:

New changeset efb8d80af320 by Raymond Hettinger in branch 'default':
Issue 16398:  Add assertions to show why memcmp is safe.
http://hg.python.org/cpython/rev/efb8d80af320

----------

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

From report at bugs.python.org  Sat Feb  2 20:25:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 19:25:27 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <3Yz4s25GgjzSRp@mail.python.org>


Roundup Robot added the comment:

New changeset 5c7e884b205a by Nadeem Vawda in branch '3.3':
Back out fix for issue #13886; it introduced a new bug in interactive readline use.
http://hg.python.org/cpython/rev/5c7e884b205a

----------

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

From report at bugs.python.org  Sat Feb  2 20:27:46 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 19:27:46 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359833266.42.0.549345008468.issue16398@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, it is intentional that a new block is created.  Also, note the deque implementation uses freelisting (block reuse) so getting a "new block" is very cheap.   Please leave this design unchanged -- it makes it very easy to reason about the deques work and how they perform.  It also contributes to the invariants being understandable.

----------

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

From report at bugs.python.org  Sat Feb  2 20:29:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 19:29:47 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <3Yz4y26krWzNgq@mail.python.org>


Roundup Robot added the comment:

New changeset 8b8c6abda7e8 by Nadeem Vawda in branch 'default':
Back out fix for issue #13886; it introduced a new bug in interactive readline use.
http://hg.python.org/cpython/rev/8b8c6abda7e8

----------

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

From report at bugs.python.org  Sat Feb  2 20:53:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 19:53:16 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <3Yz5T763dhzSQ4@mail.python.org>


Roundup Robot added the comment:

New changeset 5bf91dfb1e34 by Nadeem Vawda in branch '2.7':
Back out fix for issue #13886; it introduced a new bug in interactive readline use.
http://hg.python.org/cpython/rev/5bf91dfb1e34

----------

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

From report at bugs.python.org  Sat Feb  2 20:57:13 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 19:57:13 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359835033.87.0.201698665482.issue16398@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Sat Feb  2 21:00:40 2013
From: report at bugs.python.org (Han-Wen Nienhuys)
Date: Sat, 02 Feb 2013 20:00:40 +0000
Subject: [issue1597850] Cross compiling patches for MINGW
Message-ID: <1359835240.64.0.00920284438229.issue1597850@psf.upfronthosting.co.za>


Han-Wen Nienhuys added the comment:

yeah, whatever.

(only 7 years to close an issue. Yay for open-source.)

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

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

From report at bugs.python.org  Sat Feb  2 21:13:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 20:13:44 +0000
Subject: [issue17106] Crash in IO reading text file as binary via email library
Message-ID: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>


New submission from R. David Murray:

I came across this by making a mistake, but it shouldn't crash:

rdmurray at hey:~/python/p32>touch temp
rdmurray at hey:~/python/p32>./python  
Python 3.2.3+ (3.2:e6952acd5a55+, Feb  2 2013, 15:04:21) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email import message_from_binary_file as mb
>>> m = mb(open('temp'))
python: ./Modules/_io/textio.c:1454: textiowrapper_read_chunk: Assertion `((((((PyObject*)(input_chunk))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.
zsh: abort      ./python


This is a regression relative to 3.2.3:

Python 3.2.3 (default, Sep 16 2012, 16:35:39) 
[GCC 4.5.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from email import message_from_binary_file as mb
>>> m = mb(open('temp'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/email/__init__.py", line 63, in
message_from_binary_file
    return BytesParser(*args, **kws).parse(fp)
  File "/usr/lib/python3.2/email/parser.py", line 124, in parse
    return self.parser.parse(fp, headersonly)
  File "/usr/lib/python3.2/email/parser.py", line 68, in parse
    data = fp.read(8192)
  File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
TypeError: 'str' does not support the buffer interface

----------
components: IO
keywords: 3.2regression
messages: 181210
nosy: georg.brandl, pitrou, r.david.murray
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Crash in IO reading text file as binary via email library
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Sat Feb  2 21:17:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 20:17:23 +0000
Subject: [issue17106] Crash in IO reading text file as binary via email library
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359836243.33.0.222693561167.issue17106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I?see "TypeError: 'str' does not support the buffer interface" on current 3.2 and default.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Feb  2 21:18:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 20:18:37 +0000
Subject: [issue17106] Crash in IO reading text file as binary via email library
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359836317.25.0.249220337296.issue17106@psf.upfronthosting.co.za>


R. David Murray added the comment:

It might not crash on a debug build.  I haven't tried that.

----------

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

From report at bugs.python.org  Sat Feb  2 21:18:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 20:18:50 +0000
Subject: [issue17106] Crash in IO reading text file as binary via email library
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359836330.04.0.856013449405.issue17106@psf.upfronthosting.co.za>


R. David Murray added the comment:

I mean, non-debug build.

----------

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

From report at bugs.python.org  Sat Feb  2 21:19:16 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2013 20:19:16 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <1359836356.9.0.0432466451266.issue16398@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: http://bugs.python.org/msg181206

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

From report at bugs.python.org  Sat Feb  2 21:27:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 20:27:02 +0000
Subject: [issue16398] deque.rotate() could be much faster
In-Reply-To: <1351971066.78.0.209275581981.issue16398@psf.upfronthosting.co.za>
Message-ID: <3Yz6D54CJPzSM8@mail.python.org>


Roundup Robot added the comment:

New changeset 12ef5a4bba63 by Raymond Hettinger in branch 'default':
Issue 16398: One more assertion for good measure.
http://hg.python.org/cpython/rev/12ef5a4bba63

----------

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

From report at bugs.python.org  Sat Feb  2 21:28:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 20:28:17 +0000
Subject: [issue17106] Crash in IO reading text file as binary via email library
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359836897.6.0.0334886568706.issue17106@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, this happens in debug mode in 3.2.3, so it is not a regression.  Still something to be looked in to, since that assert presumably has a purpose.

----------
keywords:  -3.2regression
priority: release blocker -> normal
type: crash -> behavior
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Feb  2 21:29:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 Feb 2013 20:29:33 +0000
Subject: [issue17106] Crash in IO reading text file as binary via email library
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359836973.08.0.801373591624.issue17106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a simpler crasher:

import io
io.TextIOWrapper(io.StringIO()).read(1)

----------

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

From report at bugs.python.org  Sat Feb  2 21:55:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 20:55:47 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359838547.86.0.889963916375.issue17106@psf.upfronthosting.co.za>


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


----------
title: Crash in IO reading text file as binary via email library -> assertion error in IO reading text file as binary

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

From report at bugs.python.org  Sat Feb  2 22:15:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 21:15:05 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359839705.04.0.945551859333.issue17106@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, if a proper type check is made later, then the assert can go.
Also, the PyBytes_Size() result should be checked for error, which incidentally ensures the argument is a bytes object.

----------

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

From report at bugs.python.org  Sat Feb  2 22:21:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Feb 2013 21:21:54 +0000
Subject: [issue8765] Tests unwillingly writing unicocde to raw streams
In-Reply-To: <1274271475.93.0.690807793227.issue8765@psf.upfronthosting.co.za>
Message-ID: <1359840114.19.0.139102766359.issue8765@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Sat Feb  2 22:40:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 21:40:08 +0000
Subject: [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1359841208.27.0.901880239337.issue15369@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't really think they deserve documenting.

pystones can arguably be a cheap and easy way of comparing performance of different systems *using the exact same Python interpreter*. It's the only point of running pystones.

As for pybench, it probably had a point when there wasn't anything better, but I don't think it has anymore. We have a much better benchmarks suite right now, and we also have a couple specialized benchmarks in the tools directory.

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

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

From report at bugs.python.org  Sat Feb  2 22:52:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 21:52:37 +0000
Subject: [issue15633] httplib.response is not closed after all data has been
	read
In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za>
Message-ID: <3Yz86s0L19zSTF@mail.python.org>


Roundup Robot added the comment:

New changeset 8dcf94c2fef5 by Antoine Pitrou in branch '2.7':
Issue #15633: httplib.HTTPResponse is now mark closed when the server sends less than the advertised Content-Length.
http://hg.python.org/cpython/rev/8dcf94c2fef5

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Feb  2 23:10:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 22:10:31 +0000
Subject: [issue15633] httplib.response is not closed after all data has been
	read
In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za>
Message-ID: <3Yz8WW0D22zMtT@mail.python.org>


Roundup Robot added the comment:

New changeset 03c536afeb7e by Antoine Pitrou in branch '3.2':
Issue #15633: httplib.HTTPResponse is now mark closed when the server sends less than the advertised Content-Length.
http://hg.python.org/cpython/rev/03c536afeb7e

New changeset 7d504068bc58 by Antoine Pitrou in branch '3.3':
Issue #15633: httplib.HTTPResponse is now mark closed when the server sends less than the advertised Content-Length.
http://hg.python.org/cpython/rev/7d504068bc58

New changeset 9f9287357af9 by Antoine Pitrou in branch 'default':
Issue #15633: httplib.HTTPResponse is now mark closed when the server sends less than the advertised Content-Length.
http://hg.python.org/cpython/rev/9f9287357af9

----------

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

From report at bugs.python.org  Sat Feb  2 23:14:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 22:14:07 +0000
Subject: [issue15633] httplib.response is not closed after all data has been
	read
In-Reply-To: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za>
Message-ID: <1359843247.24.0.445226819808.issue15633@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've committed the patch into 2.7 and then ported it to 3.x. Please reopen if the problem still occurs with the patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  2 23:15:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 22:15:52 +0000
Subject: [issue17107] test_sni in test_urllib2net could be enabled
Message-ID: <1359843352.18.0.227762212958.issue17107@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Right now test_sni in test_urllib2net is skipped with the message "test disabled - test server needed". But the ssl module now has server-side SNI support, and therefore we could implement this test with a local server (and perhaps move it to test_urllib2_localnet).

----------
components: Tests
messages: 181222
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_sni in test_urllib2net could be enabled
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Feb  2 23:20:05 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Feb 2013 22:20:05 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
	path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1359843605.08.0.553983968344.issue17102@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

given issue 1044, this is not high priority.  i still think it'd be useful.

----------
priority: high -> normal

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

From report at bugs.python.org  Sat Feb  2 23:34:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Feb 2013 22:34:51 +0000
Subject: [issue16698] test_posix.test_getgroups fails on some systems
In-Reply-To: <1355666709.31.0.161385459804.issue16698@psf.upfronthosting.co.za>
Message-ID: <1359844491.32.0.291248562913.issue16698@psf.upfronthosting.co.za>


Ned Deily added the comment:

The problem is as documented for issue10433: http://docs.python.org/2/library/os.html#os.getgroups

Here's a patch that skips the failing test when Python is built on OS X with a deployment target less than 10.6.  Currently on releases prior to 3.3.0, the build deployment target defaults to 10.5 or earlier unless it is explicitly overridden at configure time with MACOSX_DEPLOYMENT_TARGET (Issue11485).  The patch seems to work OK on 2.7.  I'm about to test with 3.2 and later.

----------
keywords: +patch
nosy: +benjamin.peterson, georg.brandl
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28936/issue16698_27.patch

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

From report at bugs.python.org  Sat Feb  2 23:41:08 2013
From: report at bugs.python.org (Shai Berger)
Date: Sat, 02 Feb 2013 22:41:08 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
Message-ID: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>


New submission from Shai Berger:

Consider the following directory structure:

a-\
  __init__.py
  b.py
  b-|
    __init__.py

Now, in Python (I checked 2.7.3 and 3.2.3, haven't seen the issue mentioned anywhere so I suspect it is also in later Pythons), if you import a.b, you always get the package (that is, the b folder), and the module (b.py) is silently ignored. I tested by putting the line """print("I'm a package")""" in a/b/__init__.py and """print("I'm a module")""" in a/b.py.

This becomes a real problem with tools which find modules dynamically, like test harnesses.

I'd expect that in such cases, Python should "avoid the temptation to guess", and raise an ImportError.

Thanks, Shai.

----------
components: Interpreter Core
messages: 181225
nosy: shai
priority: normal
severity: normal
status: open
title: import silently prefers package over module when both available
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sat Feb  2 23:58:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 22:58:46 +0000
Subject: [issue16686] audioop overflow issues
In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>
Message-ID: <1359845926.88.0.489462488331.issue16686@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do not have the knowledge needed to review the code, but I took a brief look. The three doc patches need a verb to be proper English. "Samples truncated in case of overflow." should be "Samples are truncated in case of overflow." in both places. I think "Samples wrapped around in case of overflow." could be rewritten as "Samples wrap around in case of overflow.", though adding 'are' works too.

In the C code comment:

     /* Passing a short** for an 's' argument is correct only
        if the string contents is aligned for interpretation
        as short[]. Due to the definition of PyBytesObject,
-       this is currently (Python 2.6) the case. */
+       this is currently (Python 2.6) the case.
+       XXX: It's not true for memoryview. */

Is whatever the case in 2.6 only (if so, drop obsolete) or since 2.6. If the latter, I would rewrite as "this is the case since Python 2.6.".
The addition is not clear to me. Are you implying that something should be made true for memory view (in a future patch)?

----------

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

From report at bugs.python.org  Sun Feb  3 00:01:24 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Feb 2013 23:01:24 +0000
Subject: [issue16698] test_posix.test_getgroups fails on some systems
In-Reply-To: <1355666709.31.0.161385459804.issue16698@psf.upfronthosting.co.za>
Message-ID: <1359846084.61.0.550128254634.issue16698@psf.upfronthosting.co.za>


Ned Deily added the comment:

It seems to work on 3.x as well.  Since it is minimally invasive and should help to clean up the OS X buildbots, I'm going to push the fix now and keep an eye on the buildbots.

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Sun Feb  3 00:14:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 23:14:19 +0000
Subject: [issue16698] test_posix.test_getgroups fails on some systems
In-Reply-To: <1355666709.31.0.161385459804.issue16698@psf.upfronthosting.co.za>
Message-ID: <3Yz9x62FlXzSVZ@mail.python.org>


Roundup Robot added the comment:

New changeset c37ac05119ff by Ned Deily in branch '2.7':
Issue #16698: Skip posix test_getgroups when built with OS X
http://hg.python.org/cpython/rev/c37ac05119ff

New changeset 6c9f4c22fd81 by Ned Deily in branch '3.2':
Issue #16698: Skip posix test_getgroups when built with OS X
http://hg.python.org/cpython/rev/6c9f4c22fd81

New changeset 3653d8174b0b by Ned Deily in branch '3.3':
Issue #16698: merge from 3.2
http://hg.python.org/cpython/rev/3653d8174b0b

New changeset 06576c641113 by Ned Deily in branch 'default':
Issue #16698: merge from 3.3
http://hg.python.org/cpython/rev/06576c641113

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Feb  3 00:28:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 23:28:26 +0000
Subject: [issue17015] mock could be smarter and inspect the spec's signature
In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za>
Message-ID: <3YzBFQ07P8zSW3@mail.python.org>


Roundup Robot added the comment:

New changeset b888c9043566 by Antoine Pitrou in branch 'default':
Issue #17015: When it has a spec, a Mock object now inspects its signature when matching calls, so that arguments can be matched positionally or by name.
http://hg.python.org/cpython/rev/b888c9043566

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Feb  3 00:29:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 23:29:01 +0000
Subject: [issue17015] mock could be smarter and inspect the spec's signature
In-Reply-To: <1358858651.94.0.425572209999.issue17015@psf.upfronthosting.co.za>
Message-ID: <1359847741.05.0.117882653358.issue17015@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Committed!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  3 00:31:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 23:31:56 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
Message-ID: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you look at http://docs.python.org/dev/library/development.html, you'll see the following outline (stripped for brevity):
     
26.4. unittest.mock ? mock object library

    26.4.1. Quick Guide
    26.4.2. The Mock Class

26.5. The patchers

26.6. MagicMock and magic method support

26.7. Helpers

26.8. unittest.mock ? getting started

26.9. Further Examples

26.10. 2to3 - Automated Python 2 to 3 code translation


Instead, it should be:

26.4. unittest.mock ? mock object library

    26.4.1. Quick Guide
    26.4.2. The Mock Class
    26.4.3. The patchers
    26.4.4. MagicMock and magic method support
    26.4.5. Helpers

26.5. unittest.mock ? getting started

    26.5.1. Further Examples

26.6. 2to3 - Automated Python 2 to 3 code translation


(I'm also not sure the reference document should come before the getting started document)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 181231
nosy: docs at python, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest.mock has wrong heading levels
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 00:39:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Feb 2013 23:39:33 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359848373.22.0.373752295102.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is behavior has been true since packages were introduced, and is not going to change.  However, I agree that it could be better documented.

In Python3 something that needs to do dynamic module discovery can use importlib to be sure of using the same logic that Python itself uses.  (Well, that's completely true only for 3.3+, but it is 99+% true for 3.1 and 3.2 as well).

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

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

From report at bugs.python.org  Sun Feb  3 00:51:05 2013
From: report at bugs.python.org (Shai Berger)
Date: Sat, 02 Feb 2013 23:51:05 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359849065.89.0.705054200068.issue17108@psf.upfronthosting.co.za>


Shai Berger added the comment:

Thanks for the quick response.

If this isn't changing, I'd definitely want better documentation. In particular, the rationale behind this should be explained.

I submitted the bug because a co-worker unintentionally caused a whole suite of tests to be ignored.

Thanks again,
Shai.

----------

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

From report at bugs.python.org  Sun Feb  3 01:02:49 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 03 Feb 2013 00:02:49 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359849769.87.0.0647652341112.issue17108@psf.upfronthosting.co.za>


Eric Snow added the comment:

Other than the language reference (with its updated info on imports--thanks Barry!), what other documentation would benefit from a note on this?  Somwhere in http://docs.python.org/dev/tutorial/modules.html?

----------
nosy: +eric.snow

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

From report at bugs.python.org  Sun Feb  3 02:23:36 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Feb 2013 01:23:36 +0000
Subject: [issue16698] test_posix.test_getgroups fails on some systems
In-Reply-To: <1355666709.31.0.161385459804.issue16698@psf.upfronthosting.co.za>
Message-ID: <1359854616.11.0.792440185544.issue16698@psf.upfronthosting.co.za>


Ned Deily added the comment:

The buildbots look happier: closing.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  3 02:31:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Feb 2013 01:31:14 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359855074.81.0.788933000065.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

It was mostly the language reference I was thinking of, since that's where I think one would naturally go to find out about unexpected behavior of the import statement, but a note in the tutorial is probably not a bad idea.  I'm not sure if this rises to the level of a FAQ or not, but perhaps it does.

Technically I suppose the importlib documentation should also mention it where appropriate if it does not already, but I wouldn't expect that to be a very discoverable location for it.

By the way, I seem to remember there being some detail about namespace packages that potentially affected this, but I don't remember if that was a proposal or something that wound up in the final implementation.  Do you?

----------

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

From report at bugs.python.org  Sun Feb  3 02:32:54 2013
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 03 Feb 2013 01:32:54 +0000
Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF
Message-ID: <1359855174.67.0.710510463071.issue1159051@psf.upfronthosting.co.za>


Nadeem Vawda added the comment:

I think the new behavior should be controlled by a constructor flag, maybe
named "defer_errors". I don't like the idea of adding the flag to read(),
since that makes us diverge from the standard file interface. Making a
distinction between size<0 and size=None seems confusing and error-prone,
not to mention that we (again) would have read() work differently from most
other file classes.

I'd prefer it if the new behavior is not enabled by default for size>=0,
even if this wouldn't break well-behaved code. Having a flag that only
controls the size<0 case is inelegant, and I don't think we should change
the default behavior unless there is a clear benefit to doing so.

----------

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

From report at bugs.python.org  Sun Feb  3 04:10:56 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 03 Feb 2013 03:10:56 +0000
Subject: [issue17105] Python 3.2 segfault
In-Reply-To: <1359828214.1.0.432640165119.issue17105@psf.upfronthosting.co.za>
Message-ID: <1359861056.84.0.938358109056.issue17105@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/issue17105>
_______________________________________

From report at bugs.python.org  Sun Feb  3 04:39:05 2013
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 03 Feb 2013 03:39:05 +0000
Subject: [issue15633] httplib.response is not closed after all data has been
	read
In-Reply-To: <1359530624.91.0.425033560143.issue15633@psf.upfronthosting.co.za>
Message-ID: <510DDBD0.3050200@rath.org>


Nikolaus Rath added the comment:

On 01/29/2013 11:23 PM, Antoine Pitrou wrote:
> "length: 9369540" indicates you haven't read the whole advertised Content-Length. Is it possible the server shuts down the TCP connection even before the whole Content-Length has been sent?

The remote server isn't under my control, so I can't say for sure. But I
guess the connection could be terminated prematurely for quite a number
of reasons, so if that causes trouble for httplib then this might well
be the problem.

Best,

   -Nikolaus

-- 
 ?Time flies like an arrow, fruit flies like a Banana.?

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

----------

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

From report at bugs.python.org  Sun Feb  3 05:01:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Feb 2013 04:01:11 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
	issues
Message-ID: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The sys.argv docs [1] currently contain no mention of the fact that they are Unicode strings decoded from bytes provided by the OS. They also don't explain how to correct a decoding error by reversing Python's implicit conversion and redoing it based on the application's knowledge of the correct encoding, as described at [2]

[1] http://docs.python.org/3/library/sys#sys.argv
[2] http://stackoverflow.com/questions/6981594/sys-argv-as-bytes-in-python-3k/

----------
assignee: docs at python
components: Documentation, Unicode
messages: 181239
nosy: docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.argv docs should explaining how to handle encoding issues
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 05:07:16 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Feb 2013 04:07:16 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1359864436.31.0.127809299573.issue13994@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Benjamin: what?s missing is an import.

Is it too late?  I changed home today and that took a lot of my time and energy this week, so I may have missed 2.7.4.

----------

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

From report at bugs.python.org  Sun Feb  3 05:12:32 2013
From: report at bugs.python.org (Meador Inge)
Date: Sun, 03 Feb 2013 04:12:32 +0000
Subject: [issue17061] tokenize unconditionally emits NL after comment lines &
	blank lines
In-Reply-To: <1359371668.59.0.445577508897.issue17061@psf.upfronthosting.co.za>
Message-ID: <1359864752.74.0.795046293103.issue17061@psf.upfronthosting.co.za>


Meador Inge added the comment:

The current behavior seems consistent with the lexical definition for
blank lines [1]:

"""
A logical line that contains only spaces, tabs, formfeeds and possibly a
comment, is ignored (i.e., no NEWLINE token is generated).
"""

NL and COMMENT are used for items that the CPython tokenizer
ignores (and are not really tokens).  Also, the test suite explicitly
tests for this case.

Perhaps the tokenize documentation should be updated
to say something like:

"""
NL tokens are generated when a logical line of code is continued over
multiple physical lines and for blank lines.
"""

[1] http://docs.python.org/3.4/reference/lexical_analysis.html#blank-lines

----------
type:  -> behavior

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

From report at bugs.python.org  Sun Feb  3 05:27:08 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Feb 2013 04:27:08 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
	issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1359865628.81.0.0197782166555.issue17110@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Feb  3 05:29:03 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Feb 2013 04:29:03 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359865743.03.0.368267663828.issue17108@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Feb  3 05:30:32 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Feb 2013 04:30:32 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359865832.66.0.179404639955.issue6972@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Feb  3 05:31:27 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Feb 2013 04:31:27 +0000
Subject: [issue17102] tarfile extract can write files outside the destination
	path
In-Reply-To: <1359784947.71.0.187572651427.issue17102@psf.upfronthosting.co.za>
Message-ID: <1359865887.96.0.0599658907983.issue17102@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Feb  3 05:34:04 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Feb 2013 04:34:04 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359866044.87.0.970160556057.issue17106@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Feb  3 05:36:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Feb 2013 04:36:25 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359866185.21.0.263308722292.issue17109@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/issue17109>
_______________________________________

From report at bugs.python.org  Sun Feb  3 05:38:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Feb 2013 04:38:26 +0000
Subject: [issue17048] calendar should understand full- vs. half-width
	characters
In-Reply-To: <1359275890.12.0.683153995486.issue17048@psf.upfronthosting.co.za>
Message-ID: <1359866306.99.0.689249854233.issue17048@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/issue17048>
_______________________________________

From report at bugs.python.org  Sun Feb  3 05:39:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Feb 2013 04:39:52 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1359866392.42.0.74310524341.issue4011@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/issue4011>
_______________________________________

From report at bugs.python.org  Sun Feb  3 06:07:23 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 03 Feb 2013 05:07:23 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359868043.6.0.184652033644.issue17108@psf.upfronthosting.co.za>


Eric Snow added the comment:

> By the way,...

Yeah, PEP 420 (implemented in 3.3) introduced namespace packages.  The new behavior you're thinking of is where a package doesn't need a __init__.py.  So path-based lookup for modules, the order goes like this (for "import spam.eggs"):

1. look for a directory named "spam" with a __init__.py,
2. look for a file named spam.py,
3. look for a directory named "spam" (becomes an namespace package),
4. raise ImportError (used to be step 3).

Once spam gets loaded, spam.eggs gets imported...

----------

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

From report at bugs.python.org  Sun Feb  3 06:07:36 2013
From: report at bugs.python.org (Meador Inge)
Date: Sun, 03 Feb 2013 05:07:36 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1359868056.01.0.0310961425129.issue12691@psf.upfronthosting.co.za>


Meador Inge added the comment:

I will take a look.  As it stands the current patch fixes way too many
issues.  Patches should fix *one* issue at a time.  I will look at fixing
the original assert problem and at opening new issues for the others
(assuming there aren't already issues for them).

----------

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

From report at bugs.python.org  Sun Feb  3 07:12:46 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Feb 2013 06:12:46 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1359871966.0.0.768430502134.issue6972@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I believe this is all done after Serhiy's fixes.

----------
assignee: gregory.p.smith -> serhiy.storchaka
status: open -> closed

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

From report at bugs.python.org  Sun Feb  3 07:47:41 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 Feb 2013 06:47:41 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1359874061.13.0.17539555636.issue13994@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

There's a window above about 12 hours now.

----------

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

From report at bugs.python.org  Sun Feb  3 09:46:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Feb 2013 08:46:35 +0000
Subject: [issue17111] test_surrogates of test_fileio fails sometimes on OS X
	10.4
Message-ID: <1359881195.85.0.467111019736.issue17111@psf.upfronthosting.co.za>


New submission from Ned Deily:

Seen on "X86 Tiger 2.7" buildbot (http://buildbot.python.org/all/builders/x86%20Tiger%202.7)

test_surrogates (test.test_fileio.OtherFileTests) ... test test_fileio failed -- Traceback (most recent call last):
  File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_fileio.py", line 455, in test_surrogates
    self.fail('Bad output: %r' % out)
AssertionError: Bad output: 'Traceback (most recent call last):\n  File "<string>", line 1, in <module>\nIOError: [Errno 22] Invalid argument: \'\\xed\\xb2\\x80.txt\'\n[20282 refs]\n'

Looking into it a bit, the test attempts to open a file with a filename containing surrogates.  On OS X 10.4 (Tiger), an attempt to open such a file on a standard HFS+ file system appears to always fail with the above error 22 (EINVAL), rather than error 2 (ENOENT) "No such file or directory" as the test expects and as more recent versions of OS X do.  So the test should probably be changed to expect either error code.  I'm attaching a patch that should do that.

However, there is another issue.  The test does not always fail on 10.4 as one would expect.  The test on the buildbot sometimes succeeds.  On my own 10.4 system, while I predictably receive an EINVAL when attempting to open the file, running test_fileio in isolation seems to always pass and it's not obvious why it does.  The first part of the test, the local open fails as expected but, without the patch, the test of an open in a subprocess passes when it should be failing.  But I was able to reproduce the Error 22 failure, as seen on the buildbot failures, with the same interpreter build by using a --randseed value from one of the buildbot failures.  So there appears to be a test interaction problem here as well (environment variables?).

/python.exe -Wd -3 -E -tt  -R ./Lib/test/regrtest.py -uall -rwW --randseed=2535964

----------
components: Tests
files: issue_XXXXX_test_fileio.patch
keywords: buildbot, needs review, patch
messages: 181246
nosy: ned.deily
priority: normal
severity: normal
stage: patch review
status: open
title: test_surrogates of test_fileio fails sometimes on OS X 10.4
versions: Python 2.7
Added file: http://bugs.python.org/file28937/issue_XXXXX_test_fileio.patch

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

From report at bugs.python.org  Sun Feb  3 09:50:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 08:50:54 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359839705.04.0.945551859333.issue17106@psf.upfronthosting.co.za>
Message-ID: <201302031050.31166.storchaka@gmail.com>


Serhiy Storchaka added the comment:

Crash is possible not only when reading from text files, but also when decoder 
returns a non-string or when decoder's state is not a bytes object. This is 
possible with malicious decoder and perhaps with some old not bytes-to-string 
decoder in stdlib codecs registry.

Here are patches for different versions.

----------
keywords: +patch
Added file: http://bugs.python.org/file28938/textio_type_check-2.7.patch
Added file: http://bugs.python.org/file28939/textio_type_check-3.3.patch
Added file: http://bugs.python.org/file28940/textio_type_check-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17106>
_______________________________________
-------------- next part --------------
diff -r c37ac05119ff Modules/_io/textio.c
--- a/Modules/_io/textio.c	Sat Feb 02 15:06:45 2013 -0800
+++ b/Modules/_io/textio.c	Sun Feb 03 10:41:09 2013 +0200
@@ -269,8 +269,9 @@
         return NULL;
 
     if (!PyUnicode_Check(output)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "decoder should return a string result");
+        PyErr_Format(PyExc_TypeError,
+                     "decoder should return a string result, not '%.200s'",
+                     Py_TYPE(output)->tp_name);
         goto error;
     }
 
@@ -1417,7 +1418,12 @@
     Py_DECREF(chunk_size);
     if (input_chunk == NULL)
         goto fail;
-    assert(PyBytes_Check(input_chunk));
+    if (!PyBytes_Check(input_chunk)) {
+        PyErr_Format(PyExc_IOError,
+                     "underlying read1() should have returned a bytes object, "
+                     "not '%.200s'", Py_TYPE(input_chunk)->tp_name);
+        goto fail;
+    }
 
     eof = (PyBytes_Size(input_chunk) == 0);
 
@@ -1444,7 +1450,14 @@
         PyObject *next_input = PyNumber_Add(dec_buffer, input_chunk);
         if (next_input == NULL)
             goto fail;
-        assert (PyBytes_Check(next_input));
+        if (!PyBytes_Check(next_input)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder getstate() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(next_input)->tp_name);
+            Py_DECREF(next_input);
+            goto fail;
+        }
         Py_DECREF(dec_buffer);
         Py_CLEAR(self->snapshot);
         self->snapshot = Py_BuildValue("NN", dec_flags, next_input);
@@ -2110,7 +2123,14 @@
         if (input_chunk == NULL)
             goto fail;
 
-        assert (PyBytes_Check(input_chunk));
+        if (!PyBytes_Check(input_chunk)) {
+            PyErr_Format(PyExc_IOError,
+                         "underlying read() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(input_chunk)->tp_name);
+            Py_DECREF(input_chunk);
+            goto fail;
+        }
 
         self->snapshot = Py_BuildValue("iN", cookie.dec_flags, input_chunk);
         if (self->snapshot == NULL) {
@@ -2247,7 +2267,13 @@
             self->decoder, "decode", "s#", input, 1);
         if (decoded == NULL)
             goto fail;
-        assert (PyUnicode_Check(decoded));
+        if (!PyUnicode_Check(decoded)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder should return a string result, not '%.200s'",
+                         Py_TYPE(decoded)->tp_name);
+            Py_DECREF(decoded);
+            goto fail;
+        }
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
 
@@ -2281,7 +2307,13 @@
             self->decoder, "decode", "si", "", /* final = */ 1);
         if (decoded == NULL)
             goto fail;
-        assert (PyUnicode_Check(decoded));
+        if (!PyUnicode_Check(decoded)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder should return a string result, not '%.200s'",
+                         Py_TYPE(decoded)->tp_name);
+            Py_DECREF(decoded);
+            goto fail;
+        }
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
         cookie.need_eof = 1;
@@ -2440,7 +2472,7 @@
     Py_DECREF(res);
     if (r < 0)
         return NULL;
-    
+
     if (r > 0) {
         Py_RETURN_NONE; /* stream already closed */
     }
-------------- next part --------------
diff -r 3653d8174b0b Modules/_io/textio.c
--- a/Modules/_io/textio.c	Sat Feb 02 15:12:59 2013 -0800
+++ b/Modules/_io/textio.c	Sun Feb 03 10:42:13 2013 +0200
@@ -290,8 +290,9 @@
         return NULL;
 
     if (!PyUnicode_Check(output)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "decoder should return a string result");
+        PyErr_Format(PyExc_TypeError,
+                     "decoder should return a string result, not '%.200s'",
+                     Py_TYPE(output)->tp_name);
         goto error;
     }
 
@@ -1458,7 +1459,13 @@
     Py_DECREF(chunk_size);
     if (input_chunk == NULL)
         goto fail;
-    assert(PyBytes_Check(input_chunk));
+    if (!PyBytes_Check(input_chunk)) {
+        PyErr_Format(PyExc_IOError,
+                     "underlying %s() should have returned a bytes object, "
+                     "not '%.200s'", (self->has_read1 ? "read1": "read"),
+                     Py_TYPE(input_chunk)->tp_name);
+        goto fail;
+    }
 
     nbytes = PyBytes_Size(input_chunk);
     eof = (nbytes == 0);
@@ -1493,7 +1500,14 @@
         PyObject *next_input = PyNumber_Add(dec_buffer, input_chunk);
         if (next_input == NULL)
             goto fail;
-        assert (PyBytes_Check(next_input));
+        if (!PyBytes_Check(next_input)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder getstate() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(next_input)->tp_name);
+            Py_DECREF(next_input);
+            goto fail;
+        }
         Py_DECREF(dec_buffer);
         Py_CLEAR(self->snapshot);
         self->snapshot = Py_BuildValue("NN", dec_flags, next_input);
@@ -2151,7 +2165,14 @@
         if (input_chunk == NULL)
             goto fail;
 
-        assert (PyBytes_Check(input_chunk));
+        if (!PyBytes_Check(input_chunk)) {
+            PyErr_Format(PyExc_IOError,
+                         "underlying read() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(input_chunk)->tp_name);
+            Py_DECREF(input_chunk);
+            goto fail;
+        }
 
         self->snapshot = Py_BuildValue("iN", cookie.dec_flags, input_chunk);
         if (self->snapshot == NULL) {
@@ -2283,13 +2304,18 @@
         Py_DECREF(_state); \
     } while (0)
 
-    /* TODO: replace assert with exception */
 #define DECODER_DECODE(start, len, res) do { \
         PyObject *_decoded = _PyObject_CallMethodId( \
             self->decoder, &PyId_decode, "y#", start, len); \
         if (_decoded == NULL) \
             goto fail; \
-        assert (PyUnicode_Check(_decoded)); \
+        if (!PyUnicode_Check(_decoded)) { \
+            PyErr_Format(PyExc_TypeError, \
+                         "decoder should return a string result, not '%.200s'", \
+                         Py_TYPE(_decoded)->tp_name); \
+            Py_DECREF(_decoded); \
+            goto fail; \
+        } \
         res = PyUnicode_GET_LENGTH(_decoded); \
         Py_DECREF(_decoded); \
     } while (0)
@@ -2372,7 +2398,13 @@
             self->decoder, &PyId_decode, "yi", "", /* final = */ 1);
         if (decoded == NULL)
             goto fail;
-        assert (PyUnicode_Check(decoded));
+        if (!PyUnicode_Check(decoded)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder should return a string result, not '%.200s'",
+                         Py_TYPE(decoded)->tp_name);
+            Py_DECREF(decoded);
+            goto fail;
+        }
         chars_decoded += PyUnicode_GET_LENGTH(decoded);
         Py_DECREF(decoded);
         cookie.need_eof = 1;
-------------- next part --------------
diff -r 6c9f4c22fd81 Modules/_io/textio.c
--- a/Modules/_io/textio.c	Sat Feb 02 15:08:52 2013 -0800
+++ b/Modules/_io/textio.c	Sun Feb 03 10:37:22 2013 +0200
@@ -269,8 +269,9 @@
         return NULL;
 
     if (!PyUnicode_Check(output)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "decoder should return a string result");
+        PyErr_Format(PyExc_TypeError,
+                     "decoder should return a string result, not '%.200s'",
+                     Py_TYPE(output)->tp_name);
         goto error;
     }
 
@@ -1454,7 +1455,13 @@
     Py_DECREF(chunk_size);
     if (input_chunk == NULL)
         goto fail;
-    assert(PyBytes_Check(input_chunk));
+    if (!PyBytes_Check(input_chunk)) {
+        PyErr_Format(PyExc_IOError,
+                     "underlying %s() should have returned a bytes object, "
+                     "not '%.200s'", (self->has_read1 ? "read1": "read"),
+                     Py_TYPE(input_chunk)->tp_name);
+        goto fail;
+    }
 
     eof = (PyBytes_Size(input_chunk) == 0);
 
@@ -1481,7 +1488,14 @@
         PyObject *next_input = PyNumber_Add(dec_buffer, input_chunk);
         if (next_input == NULL)
             goto fail;
-        assert (PyBytes_Check(next_input));
+        if (!PyBytes_Check(next_input)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder getstate() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(next_input)->tp_name);
+            Py_DECREF(next_input);
+            goto fail;
+        }
         Py_DECREF(dec_buffer);
         Py_CLEAR(self->snapshot);
         self->snapshot = Py_BuildValue("NN", dec_flags, next_input);
@@ -2123,7 +2137,14 @@
         if (input_chunk == NULL)
             goto fail;
 
-        assert (PyBytes_Check(input_chunk));
+        if (!PyBytes_Check(input_chunk)) {
+            PyErr_Format(PyExc_IOError,
+                         "underlying read() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(input_chunk)->tp_name);
+            Py_DECREF(input_chunk);
+            goto fail;
+        }
 
         self->snapshot = Py_BuildValue("iN", cookie.dec_flags, input_chunk);
         if (self->snapshot == NULL) {
@@ -2259,7 +2280,13 @@
             self->decoder, "decode", "y#", input, 1);
         if (decoded == NULL)
             goto fail;
-        assert (PyUnicode_Check(decoded));
+        if (!PyUnicode_Check(decoded)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder should return a string result, not '%.200s'",
+                         Py_TYPE(decoded)->tp_name);
+            Py_DECREF(decoded);
+            goto fail;
+        }
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
 
@@ -2293,7 +2320,13 @@
             self->decoder, "decode", "yi", "", /* final = */ 1);
         if (decoded == NULL)
             goto fail;
-        assert (PyUnicode_Check(decoded));
+        if (!PyUnicode_Check(decoded)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder should return a string result, not '%.200s'",
+                         Py_TYPE(decoded)->tp_name);
+            Py_DECREF(decoded);
+            goto fail;
+        }
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
         cookie.need_eof = 1;

From report at bugs.python.org  Sun Feb  3 09:53:19 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2013 08:53:19 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359881599.8.0.552636584136.issue17106@psf.upfronthosting.co.za>


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


----------
nosy: +larry
priority: normal -> release blocker

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

From report at bugs.python.org  Sun Feb  3 09:54:19 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2013 08:54:19 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359881659.98.0.767944383341.issue17106@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Blocker for 3.2.4.

----------

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

From report at bugs.python.org  Sun Feb  3 09:55:41 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2013 08:55:41 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1359881741.52.0.36899122989.issue14340@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Greg, if you are fine please apply to 3.2 or indicate if it is enough to apply the same patch as on 3.3/default.

----------

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

From report at bugs.python.org  Sun Feb  3 10:01:06 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2013 09:01:06 +0000
Subject: [issue4011] Create DAG for PEP 101
In-Reply-To: <1222896665.95.0.381960877122.issue4011@psf.upfronthosting.co.za>
Message-ID: <1359882066.84.0.276495814511.issue4011@psf.upfronthosting.co.za>


Georg Brandl added the comment:

While it's nice to look at a graphical representation, clearly there is no deep interest (and PEP 101 has so many little steps that you couldn't possibly fit them all into a graph, so you have to consult the text anyway).  I see no reason to keep this open.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Feb  3 10:07:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 09:07:28 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359882448.37.0.250448739619.issue17106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This bug exists also in 2.7.

I?doubt about an exception type. On one hand, TypeError looks naturally here and exception of this type implicitly raised by Python implementation. On other hand, there is a precedent in __iter__() which raises IOError when readline() returns non-string.

----------
nosy: +benjamin.peterson
versions: +Python 2.7

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

From report at bugs.python.org  Sun Feb  3 10:17:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 09:17:15 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359883035.73.0.463680967758.issue17106@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

TypeError should be the right exception here.

----------

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

From report at bugs.python.org  Sun Feb  3 10:27:28 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Feb 2013 09:27:28 +0000
Subject: [issue17112] Some doctest-based tests fail when run with python -OO
Message-ID: <1359883648.75.0.520386861217.issue17112@psf.upfronthosting.co.za>


New submission from Ned Deily:

Seen on the AMD64 Mountain Lion Optimized [SB] 2.7 buildbot
(http://buildbot.python.org/all/builders/AMD64%20Mountain%20Lion%20Optimized%20%5BSB%5D%202.7):

test test_doctest crashed -- <type 'exceptions.AssertionError'>: filter ('backquote not supported', SyntaxWarning) did not catch any warning
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 896, in runtest_inner
  File "/Users/cpython/buildslave/optimized/2.7.snakebite-mountainlion-amd64-optimized/build/Lib/test/test_doctest.py", line 2684, in test_main
    test_support.run_doctest(test_doctest, verbosity=True)
  File "/Users/cpython/buildslave/optimized/2.7.snakebite-mountainlion-amd64-optimized/build/Lib/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/Users/cpython/buildslave/optimized/2.7.snakebite-mountainlion-amd64-optimized/build/Lib/test/test_support.py", line 641, in _filterwarnings
    missing[0])
AssertionError: filter ('backquote not supported', SyntaxWarning) did not catch any warning

The same failure is seen in test_syntax and test_zipimport_support.

That buildbot builds the interpreter --with-pydebug but runs the test suite with -OO:

./python.exe -Wd -3 -E -tt -OO -R ./Lib/test/regrtest.py -uall -rwW

I am able to reproduce the buildbot failures when run as above.  Without "-OO", the tests no longer fail.

----------
components: Tests
keywords: buildbot
messages: 181253
nosy: ned.deily
priority: normal
severity: normal
status: open
title: Some doctest-based tests fail when run with python -OO
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  3 10:34:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 09:34:35 +0000
Subject: [issue17112] Some doctest-based tests fail when run with python -OO
In-Reply-To: <1359883648.75.0.520386861217.issue17112@psf.upfronthosting.co.za>
Message-ID: <1359884075.03.0.188675228301.issue17112@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Without -3 option tests passed.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Feb  3 10:45:55 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 03 Feb 2013 09:45:55 +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: <1359884755.14.0.372609902492.issue7083@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Any progress on that? After a month I am inclined that this behavior should be fixed, not only documented. The correct documentation is:

NOTE: The variable returned by locals() is sporadically updated by core interpreter.

----------
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Feb  3 10:58:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Feb 2013 09:58:01 +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: <1359885481.45.0.0360349735566.issue7083@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.4, Python 2.5, Python 2.6, Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Sun Feb  3 11:07:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 10:07:30 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359886050.4.0.405256260229.issue17106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one crasher, not fixed by my patch yet.

io.TextIOWrapper(io.BytesIO(b'a'), newline='\n', encoding='quopri_codec').read(1)

Sometimes it crashes (on non-debug build), sometimes raises an exception: "ValueError: character U+82228c0 is not in range [U+0000; U+10ffff]".

----------

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

From report at bugs.python.org  Sun Feb  3 11:47:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 10:47:34 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <3YzTK11d4ZzR9V@mail.python.org>


Roundup Robot added the comment:

New changeset 72aee7ee2299 by Georg Brandl in branch '3.3':
Closes #17109: fix heading levels in mock doc.
http://hg.python.org/cpython/rev/72aee7ee2299

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  3 11:53:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 10:53:17 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359888797.56.0.359212290245.issue17109@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

unittest.mock-examples.rst also needs fixing.

----------

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

From report at bugs.python.org  Sun Feb  3 12:05:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 11:05:10 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359889509.99.0.317983293999.issue17106@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch for 3.3+. An exception type changed to TypeError, fixed some new crashes, added tests. If it is good, I'll backport it to 3.2 and 2.7.

----------
Added file: http://bugs.python.org/file28941/textio_type_check-3.3_2.patch

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

From report at bugs.python.org  Sun Feb  3 12:15:51 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 03 Feb 2013 11:15:51 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1359736540.6.0.19376281947.issue12502@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2gJeJogEs-D08-rtja__pDG2aDxjrr6MiX7C9yzUrowA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I'm unable to reproduce it.
Are you using the attached script?
Did you apply the patch by hand, or are you using a recent Python version?

----------

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

From report at bugs.python.org  Sun Feb  3 12:16:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 11:16:15 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359889509.99.0.317983293999.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359889999.3415.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Here is an updated patch for 3.3+. An exception type changed to
> TypeError, fixed some new crashes, added tests. If it is good, I'll
> backport it to 3.2 and 2.7.

Looks ok to me.

----------

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

From report at bugs.python.org  Sun Feb  3 12:29:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 11:29:39 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1359890979.87.0.541944713385.issue16997@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This new patch adds some documentation.

----------
Added file: http://bugs.python.org/file28942/subtests4.patch

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

From report at bugs.python.org  Sun Feb  3 12:54:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 11:54:20 +0000
Subject: [issue16686] audioop overflow issues
In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>
Message-ID: <1359892460.11.0.993754034583.issue16686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Terry.

> Is whatever the case in 2.6 only (if so, drop obsolete) or since 2.6. If the latter, I would rewrite as "this is the case since Python 2.6.".
> The addition is not clear to me. Are you implying that something should be made true for memory view (in a future patch)?

In 2.6 the sentence possible was true and the code was correct. But it is wrong for currently supported versions when we pass memoryview as an argument. This is a bug (possible even a crash) and should be fixed. But on x86 or when we don't use unaligned memoryview (most peoples don't do this) it is never occurred. Due to this I left this bug unfixed yet. There are other minor bugs which I left for different issues. This patch fixes most critical bugs and creates a solid basis for testing.

I see unstable AIX buildbots failed on test_aifc. Perhaps this patch will fix it or expose an issue in audioop module (current audioop testing too poor).

----------

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

From report at bugs.python.org  Sun Feb  3 13:18:14 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 03 Feb 2013 12:18:14 +0000
Subject: [issue16643] Wrong documented default value for timefunc parameter in
	sched.scheduler()
In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>
Message-ID: <1359893894.51.0.180980696338.issue16643@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Here's a patch.

----------
keywords: +patch
nosy: +ramchandra.apte
Added file: http://bugs.python.org/file28943/issue16643.patch

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

From report at bugs.python.org  Sun Feb  3 13:38:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 12:38:28 +0000
Subject: [issue16643] Wrong documented default value for timefunc parameter in
	sched.scheduler()
In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>
Message-ID: <1359895108.95.0.123578661941.issue16643@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Sun Feb  3 13:59:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 12:59:28 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <3YzXFD00TzzMhh@mail.python.org>


Roundup Robot added the comment:

New changeset 9040b3714207 by Georg Brandl in branch '3.3':
#17109: fix headings in mock example doc.
http://hg.python.org/cpython/rev/9040b3714207

----------

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

From report at bugs.python.org  Sun Feb  3 14:00:49 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 03 Feb 2013 13:00:49 +0000
Subject: [issue17025] reduce multiprocessing.Queue contention
In-Reply-To: <1359312092.44.0.172489308809.issue17025@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1ppRR4CztNANjEuexjmw4SyB2ba+n9gPRKBjF9Lp2ztw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> For the record, I tried the Connection approach and here is what I ended up with.

I don't really like the API.
Having to pass an external lock is IMO a bad idea, it should be a
private instance field.
Also, for consistency we'd probably need send_bytes/recv_bytes.

----------

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

From report at bugs.python.org  Sun Feb  3 14:45:40 2013
From: report at bugs.python.org (Roy Smith)
Date: Sun, 03 Feb 2013 13:45:40 +0000
Subject: [issue17113] argparse.RawDescriptionHelpFormatter should not delete
	blank lines
Message-ID: <1359899140.94.0.20575006786.issue17113@psf.upfronthosting.co.za>


New submission from Roy Smith:

The following code, when run with "--help", omits the trailing newlines from the epilog.  It should just emit the string verbatim.  If the developer didn't want the extra newlines, he/she wouldn't have put them there.


import argparse
parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter,
                                 epilog="foo\n\n")
parser.parse_args()

----------
components: Library (Lib)
messages: 181267
nosy: roysmith
priority: normal
severity: normal
status: open
title: argparse.RawDescriptionHelpFormatter should not delete blank lines
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Feb  3 15:04:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Feb 2013 14:04:40 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359900280.04.0.321470100823.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, yes.

To clarify for Shai, by the way, the reason this stuff can't change (and the reason there is a new step 3 instead of changing the whole algorithm to be something more sensible) is because of the requirement of maintaining backward compatibility.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python

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

From report at bugs.python.org  Sun Feb  3 15:16:08 2013
From: report at bugs.python.org (Shai Berger)
Date: Sun, 03 Feb 2013 14:16:08 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359900968.31.0.991070098502.issue17108@psf.upfronthosting.co.za>


Shai Berger added the comment:

Hi,

> the reason this stuff can't change [... is] backward compatibility.

Thanks, but this is still unclear to me. The required fix for code that would break because of the change I propose, is removal of dead code which looks misleadingly alive. 

Is the backward-compatibility requirement really that strict?

----------

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

From report at bugs.python.org  Sun Feb  3 15:34:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 14:34:16 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359889999.3415.0.camel@localhost.localdomain>
Message-ID: <201302031633.47980.storchaka@gmail.com>


Serhiy Storchaka added the comment:

Here are patches for 3.2 and 2.7.

Note that due to unicode-str autoconversions 2.7 not always raises TypeError 
(sometimes it can do nor raise an exception, sometimes it raises 
UnicodeEncodeError). 2.7 tests are not so strong as 3.x tests.

----------
Added file: http://bugs.python.org/file28944/textio_type_check-3.2_2.patch
Added file: http://bugs.python.org/file28945/textio_type_check-2.7_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17106>
_______________________________________
-------------- next part --------------
diff -r 6c9f4c22fd81 Lib/test/test_io.py
--- a/Lib/test/test_io.py	Sat Feb 02 15:08:52 2013 -0800
+++ b/Lib/test/test_io.py	Sun Feb 03 15:02:34 2013 +0200
@@ -2481,6 +2481,30 @@
         txt.write('5')
         self.assertEqual(b''.join(raw._write_stack), b'123\n45')
 
+    def test_read_nonbytes(self):
+        # Issue #17106
+        # Crash when underlying read() returns non-bytes
+        t = self.TextIOWrapper(self.StringIO('a'))
+        self.assertRaises(TypeError, t.read, 1)
+        t = self.TextIOWrapper(self.StringIO('a'))
+        self.assertRaises(TypeError, t.readline)
+        t = self.TextIOWrapper(self.StringIO('a'))
+        self.assertRaises(TypeError, t.read)
+
+    def test_illegal_decoder(self):
+        # Issue #17106
+        # Crash when decoder returns non-string
+        t = self.TextIOWrapper(self.BytesIO(b'aaaaaa'), newline='\n',
+                               encoding='quopri_codec')
+        self.assertRaises(TypeError, t.read, 1)
+        t = self.TextIOWrapper(self.BytesIO(b'aaaaaa'), newline='\n',
+                               encoding='quopri_codec')
+        self.assertRaises(TypeError, t.readline)
+        t = self.TextIOWrapper(self.BytesIO(b'aaaaaa'), newline='\n',
+                               encoding='quopri_codec')
+        self.assertRaises(TypeError, t.read)
+
+
 class CTextIOWrapperTest(TextIOWrapperTest):
 
     def test_initialization(self):
diff -r 6c9f4c22fd81 Modules/_io/textio.c
--- a/Modules/_io/textio.c	Sat Feb 02 15:08:52 2013 -0800
+++ b/Modules/_io/textio.c	Sun Feb 03 15:02:34 2013 +0200
@@ -236,6 +236,21 @@
     Py_TYPE(self)->tp_free((PyObject *)self);
 }
 
+static int
+check_decoded(PyObject *decoded)
+{
+    if (decoded == NULL)
+        return -1;
+    if (!PyUnicode_Check(decoded)) {
+        PyErr_Format(PyExc_TypeError,
+                     "decoder should return a string result, not '%.200s'",
+                     Py_TYPE(decoded)->tp_name);
+        Py_DECREF(decoded);
+        return -1;
+    }
+    return 0;
+}
+
 #define SEEN_CR   1
 #define SEEN_LF   2
 #define SEEN_CRLF 4
@@ -265,15 +280,9 @@
         Py_INCREF(output);
     }
 
-    if (output == NULL)
+    if (check_decoded(output) < 0)
         return NULL;
 
-    if (!PyUnicode_Check(output)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "decoder should return a string result");
-        goto error;
-    }
-
     output_len = PyUnicode_GET_SIZE(output);
     if (self->pendingcr && (final || output_len > 0)) {
         Py_UNICODE *out;
@@ -1454,7 +1463,13 @@
     Py_DECREF(chunk_size);
     if (input_chunk == NULL)
         goto fail;
-    assert(PyBytes_Check(input_chunk));
+    if (!PyBytes_Check(input_chunk)) {
+        PyErr_Format(PyExc_TypeError,
+                     "underlying %s() should have returned a bytes object, "
+                     "not '%.200s'", (self->has_read1 ? "read1": "read"),
+                     Py_TYPE(input_chunk)->tp_name);
+        goto fail;
+    }
 
     eof = (PyBytes_Size(input_chunk) == 0);
 
@@ -1467,8 +1482,7 @@
             _PyIO_str_decode, input_chunk, eof ? Py_True : Py_False, NULL);
     }
 
-    /* TODO sanity check: isinstance(decoded_chars, unicode) */
-    if (decoded_chars == NULL)
+    if (check_decoded(decoded_chars) < 0)
         goto fail;
     textiowrapper_set_decoded_chars(self, decoded_chars);
     if (PyUnicode_GET_SIZE(decoded_chars) > 0)
@@ -1481,7 +1495,14 @@
         PyObject *next_input = PyNumber_Add(dec_buffer, input_chunk);
         if (next_input == NULL)
             goto fail;
-        assert (PyBytes_Check(next_input));
+        if (!PyBytes_Check(next_input)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder getstate() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(next_input)->tp_name);
+            Py_DECREF(next_input);
+            goto fail;
+        }
         Py_DECREF(dec_buffer);
         Py_CLEAR(self->snapshot);
         self->snapshot = Py_BuildValue("NN", dec_flags, next_input);
@@ -1525,7 +1546,7 @@
         decoded = PyObject_CallMethodObjArgs(self->decoder, _PyIO_str_decode,
                                              bytes, Py_True, NULL);
         Py_DECREF(bytes);
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
 
         result = textiowrapper_get_decoded_chars(self, -1);
@@ -2123,7 +2144,14 @@
         if (input_chunk == NULL)
             goto fail;
 
-        assert (PyBytes_Check(input_chunk));
+        if (!PyBytes_Check(input_chunk)) {
+            PyErr_Format(PyExc_TypeError,
+                         "underlying read() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(input_chunk)->tp_name);
+            Py_DECREF(input_chunk);
+            goto fail;
+        }
 
         self->snapshot = Py_BuildValue("iN", cookie.dec_flags, input_chunk);
         if (self->snapshot == NULL) {
@@ -2134,7 +2162,7 @@
         decoded = PyObject_CallMethod(self->decoder, "decode",
                                       "Oi", input_chunk, (int)cookie.need_eof);
 
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
 
         textiowrapper_set_decoded_chars(self, decoded);
@@ -2257,9 +2285,8 @@
 
         PyObject *decoded = PyObject_CallMethod(
             self->decoder, "decode", "y#", input, 1);
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
-        assert (PyUnicode_Check(decoded));
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
 
@@ -2291,9 +2318,8 @@
         /* We didn't get enough decoded data; signal EOF to get more. */
         PyObject *decoded = PyObject_CallMethod(
             self->decoder, "decode", "yi", "", /* final = */ 1);
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
-        assert (PyUnicode_Check(decoded));
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
         cookie.need_eof = 1;
-------------- next part --------------
diff -r c37ac05119ff Lib/test/test_io.py
--- a/Lib/test/test_io.py	Sat Feb 02 15:06:45 2013 -0800
+++ b/Lib/test/test_io.py	Sun Feb 03 15:49:38 2013 +0200
@@ -36,6 +36,7 @@
 from collections import deque
 from UserList import UserList
 from test import test_support as support
+import contextlib
 
 import codecs
 import io  # C implementation of io
@@ -2419,6 +2420,39 @@
         with self.assertRaises((AttributeError, TypeError)):
             txt.buffer = buf
 
+    def test_read_nonbytes(self):
+        # Issue #17106
+        # Crash when underlying read() returns non-bytes
+        class NonbytesStream(self.StringIO):
+            read1 = self.StringIO.read
+        class NonbytesStream(self.StringIO):
+            read1 = self.StringIO.read
+        t = self.TextIOWrapper(NonbytesStream('a'))
+        with self.maybeRaises(TypeError):
+            t.read(1)
+        t = self.TextIOWrapper(NonbytesStream('a'))
+        with self.maybeRaises(TypeError):
+            t.readline()
+        t = self.TextIOWrapper(NonbytesStream('a'))
+        self.assertEqual(t.read(), u'a')
+
+    def test_illegal_decoder(self):
+        # Issue #17106
+        # Crash when decoder returns non-string
+        t = self.TextIOWrapper(self.BytesIO(b'aaaaaa'), newline='\n',
+                               encoding='quopri_codec')
+        with self.maybeRaises(TypeError):
+            t.read(1)
+        t = self.TextIOWrapper(self.BytesIO(b'aaaaaa'), newline='\n',
+                               encoding='quopri_codec')
+        with self.maybeRaises(TypeError):
+            t.readline()
+        t = self.TextIOWrapper(self.BytesIO(b'aaaaaa'), newline='\n',
+                               encoding='quopri_codec')
+        with self.maybeRaises(TypeError):
+            t.read()
+
+
 class CTextIOWrapperTest(TextIOWrapperTest):
 
     def test_initialization(self):
@@ -2460,9 +2494,13 @@
             t2.buddy = t1
         support.gc_collect()
 
+    maybeRaises = unittest.TestCase.assertRaises
+
 
 class PyTextIOWrapperTest(TextIOWrapperTest):
-    pass
+    @contextlib.contextmanager
+    def maybeRaises(self, *args, **kwds):
+        yield
 
 
 class IncrementalNewlineDecoderTest(unittest.TestCase):
diff -r c37ac05119ff Modules/_io/textio.c
--- a/Modules/_io/textio.c	Sat Feb 02 15:06:45 2013 -0800
+++ b/Modules/_io/textio.c	Sun Feb 03 15:49:38 2013 +0200
@@ -236,6 +236,21 @@
     Py_TYPE(self)->tp_free((PyObject *)self);
 }
 
+static int
+check_decoded(PyObject *decoded)
+{
+    if (decoded == NULL)
+        return -1;
+    if (!PyUnicode_Check(decoded)) {
+        PyErr_Format(PyExc_TypeError,
+                     "decoder should return a string result, not '%.200s'",
+                     Py_TYPE(decoded)->tp_name);
+        Py_DECREF(decoded);
+        return -1;
+    }
+    return 0;
+}
+
 #define SEEN_CR   1
 #define SEEN_LF   2
 #define SEEN_CRLF 4
@@ -265,15 +280,9 @@
         Py_INCREF(output);
     }
 
-    if (output == NULL)
+    if (check_decoded(output) < 0)
         return NULL;
 
-    if (!PyUnicode_Check(output)) {
-        PyErr_SetString(PyExc_TypeError,
-                        "decoder should return a string result");
-        goto error;
-    }
-
     output_len = PyUnicode_GET_SIZE(output);
     if (self->pendingcr && (final || output_len > 0)) {
         Py_UNICODE *out;
@@ -1417,7 +1426,12 @@
     Py_DECREF(chunk_size);
     if (input_chunk == NULL)
         goto fail;
-    assert(PyBytes_Check(input_chunk));
+    if (!PyBytes_Check(input_chunk)) {
+        PyErr_Format(PyExc_TypeError,
+                     "underlying read1() should have returned a bytes object, "
+                     "not '%.200s'", Py_TYPE(input_chunk)->tp_name);
+        goto fail;
+    }
 
     eof = (PyBytes_Size(input_chunk) == 0);
 
@@ -1430,8 +1444,7 @@
             _PyIO_str_decode, input_chunk, eof ? Py_True : Py_False, NULL);
     }
 
-    /* TODO sanity check: isinstance(decoded_chars, unicode) */
-    if (decoded_chars == NULL)
+    if (check_decoded(decoded_chars) < 0)
         goto fail;
     textiowrapper_set_decoded_chars(self, decoded_chars);
     if (PyUnicode_GET_SIZE(decoded_chars) > 0)
@@ -1444,7 +1457,14 @@
         PyObject *next_input = PyNumber_Add(dec_buffer, input_chunk);
         if (next_input == NULL)
             goto fail;
-        assert (PyBytes_Check(next_input));
+        if (!PyBytes_Check(next_input)) {
+            PyErr_Format(PyExc_TypeError,
+                         "decoder getstate() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(next_input)->tp_name);
+            Py_DECREF(next_input);
+            goto fail;
+        }
         Py_DECREF(dec_buffer);
         Py_CLEAR(self->snapshot);
         self->snapshot = Py_BuildValue("NN", dec_flags, next_input);
@@ -1490,7 +1510,7 @@
         decoded = PyObject_CallMethodObjArgs(self->decoder, _PyIO_str_decode,
                                              bytes, Py_True, NULL);
         Py_DECREF(bytes);
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
 
         result = textiowrapper_get_decoded_chars(self, -1);
@@ -2110,7 +2130,14 @@
         if (input_chunk == NULL)
             goto fail;
 
-        assert (PyBytes_Check(input_chunk));
+        if (!PyBytes_Check(input_chunk)) {
+            PyErr_Format(PyExc_TypeError,
+                         "underlying read() should have returned a bytes "
+                         "object, not '%.200s'",
+                         Py_TYPE(input_chunk)->tp_name);
+            Py_DECREF(input_chunk);
+            goto fail;
+        }
 
         self->snapshot = Py_BuildValue("iN", cookie.dec_flags, input_chunk);
         if (self->snapshot == NULL) {
@@ -2121,7 +2148,7 @@
         decoded = PyObject_CallMethod(self->decoder, "decode",
                                       "Oi", input_chunk, (int)cookie.need_eof);
 
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
 
         textiowrapper_set_decoded_chars(self, decoded);
@@ -2245,9 +2272,8 @@
 
         PyObject *decoded = PyObject_CallMethod(
             self->decoder, "decode", "s#", input, 1);
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
-        assert (PyUnicode_Check(decoded));
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
 
@@ -2279,9 +2305,8 @@
         /* We didn't get enough decoded data; signal EOF to get more. */
         PyObject *decoded = PyObject_CallMethod(
             self->decoder, "decode", "si", "", /* final = */ 1);
-        if (decoded == NULL)
+        if (check_decoded(decoded) < 0)
             goto fail;
-        assert (PyUnicode_Check(decoded));
         chars_decoded += PyUnicode_GET_SIZE(decoded);
         Py_DECREF(decoded);
         cookie.need_eof = 1;
@@ -2440,7 +2465,7 @@
     Py_DECREF(res);
     if (r < 0)
         return NULL;
-    
+
     if (r > 0) {
         Py_RETURN_NONE; /* stream already closed */
     }

From report at bugs.python.org  Sun Feb  3 15:37:13 2013
From: report at bugs.python.org (Swarnkar Rajesh)
Date: Sun, 03 Feb 2013 14:37:13 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
Message-ID: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>


New submission from Swarnkar Rajesh:

[Hello all. Just registered to ask this.]

I insatlled python 3.2 from Ubuntu Software Center. 
It created python Icon in launcher as expected. 

It was working fine until i customized the IDLE theme. I edited the 
config-highlight.cfg found in /home/user/.idlerc (hidden) directory. 
I copy pasted desert color theme into this file and pressed save.(I perfectly edited file with leaving one newline at end. So it is not issue with editing i believe.) 

Then i closed the editor. When i tried running by clicking 'IDLE (Using Python 3.2)' in Ubuntu launcher, it glows for a while then nothing shows up. 
I could see a process name python running in system monitor, but no IDLE window.

I tried these issues : 
4049
15998
8099
7265

But all these issues are related to windows OS. 
I tried follwing the similar instruction but i see three directories in /usr/lib/ as python2.7, python3 and python3.2. I am stuck at this point. So i did not choose to proceed. :S

Can you please see into it? Thank you.

----------
components: IDLE
messages: 181271
nosy: rjs.swarnkar
priority: normal
severity: normal
status: open
title: Python IDLE GUI does not open in Ubuntu 12.04
versions: Python 3.2

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

From report at bugs.python.org  Sun Feb  3 15:39:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 14:39:36 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359902376.52.0.0873552450905.issue17106@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Sun Feb  3 15:48:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Feb 2013 14:48:56 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359902936.5.0.667688975894.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes.  Imagine you have a deployed application, and there happens to be an xx.py file that is masked by a package in it.  You upgrade from pythonX.Y.Z to X.Y.Z+1, and your application is suddenly throwing an error.  Yes it is easy to fix, but we prefer not to break things that way.

Now, could we throw an error in Python 3.4?  It could be discussed, at least.

----------

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

From report at bugs.python.org  Sun Feb  3 15:54:43 2013
From: report at bugs.python.org (Shai Berger)
Date: Sun, 03 Feb 2013 14:54:43 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359903283.53.0.572878479693.issue17108@psf.upfronthosting.co.za>


Shai Berger added the comment:

Oh, sure, this was unclear of me. I thought you were talking about Python 3.4. I wasn't really expecting this to be fixed in the stable branches.

Thanks,
Shai.

----------

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

From report at bugs.python.org  Sun Feb  3 16:14:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 15:14:06 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <3YzbDZ0nZJzRHx@mail.python.org>


Roundup Robot added the comment:

New changeset 5655cdd3c010 by Serhiy Storchaka in branch '3.2':
Issue #17106: Fix a segmentation fault in io.TextIOWrapper when an underlying
http://hg.python.org/cpython/rev/5655cdd3c010

New changeset 0c4cc967a733 by Serhiy Storchaka in branch '3.3':
Issue #17106: Fix a segmentation fault in io.TextIOWrapper when an underlying
http://hg.python.org/cpython/rev/0c4cc967a733

New changeset 398bcdf55f92 by Serhiy Storchaka in branch 'default':
Issue #17106: Fix a segmentation fault in io.TextIOWrapper when an underlying
http://hg.python.org/cpython/rev/398bcdf55f92

New changeset 19a33ef3821d by Serhiy Storchaka in branch '2.7':
Issue #17106: Fix a segmentation fault in io.TextIOWrapper when an underlying
http://hg.python.org/cpython/rev/19a33ef3821d

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Feb  3 16:16:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 15:16:27 +0000
Subject: [issue17106] assertion error in IO reading text file as binary
In-Reply-To: <1359836024.9.0.950016138746.issue17106@psf.upfronthosting.co.za>
Message-ID: <1359904587.0.0.647844933515.issue17106@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  3 17:30:47 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Feb 2013 16:30:47 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1359909047.63.0.349321052207.issue13994@psf.upfronthosting.co.za>


?ric Araujo added the comment:

On it.

----------
priority: normal -> release blocker

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

From report at bugs.python.org  Sun Feb  3 17:41:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 16:41:27 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <3Yzd9L5fbKzSFq@mail.python.org>


Roundup Robot added the comment:

New changeset d4dd297fedb1 by ?ric Araujo in branch '2.7':
Add alias to restore 2.7.2 compatibility for setup scripts (#13994).
http://hg.python.org/cpython/rev/d4dd297fedb1

----------

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

From report at bugs.python.org  Sun Feb  3 17:43:11 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 03 Feb 2013 16:43:11 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1359909791.63.0.175297938913.issue13994@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Benjamin, I don?t know if you are using a release clone or if you will just tag the main repo, so leaving this open for now.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

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

From report at bugs.python.org  Sun Feb  3 17:44:23 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 Feb 2013 16:44:23 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1359909863.52.0.794429367713.issue13994@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Not yet tagged.

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

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

From report at bugs.python.org  Sun Feb  3 17:47:26 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:47:26 +0000
Subject: [issue17115] __loader__ = None should be fine
Message-ID: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There is no reason __loader__ can't be set to None like __package__. That means having xml.parsers.expat.(model|errors) set the attribute to None by default (and thus removing the exemption for those modules from test_importlib.test_api.StartupTests), updating the decorators in importlib.util to set __loader__ when it is None, and make importlib.find_loader() treat None the same as if the attribute isn't set (e.g. unifying the raising of ValueError in both cases).

This will bring __loader__ back in alignment with __package__.

In all honesty I would like to tweak imp.new_module()/PyModule_Create() to set both __package__ and __loader__ to None by default, but I don't know how much code out there relies on the absence of these attributes and not on them being set to None (although fixing all of that code is simply transitioning from hasattr(module, '__loader__') to getattr(module, '__loader__', None)). Luckily PEP 302 was updated a couple versions back to state the loaders **must** set these attributes, so hopefully as time goes on this will be less of a worry.

----------
assignee: brett.cannon
messages: 181279
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: __loader__ = None should be fine
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  3 17:47:37 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:47:37 +0000
Subject: [issue17116] xml.parsers.expat.(errors|model) don't set the
	__loader__ attribute
Message-ID: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za>


New submission from Brett Cannon:

A new test in test_importlib is discovering that pyexpat is creating both its errors and model modules by hand in pyexpat's initialization function. Should at least set __loader__ to None there.

----------
assignee: brett.cannon
messages: 181280
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: xml.parsers.expat.(errors|model) don't set the __loader__ attribute
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  3 17:47:46 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:47:46 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1359910066.2.0.381347349123.issue17115@psf.upfronthosting.co.za>


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


----------
dependencies: +xml.parsers.expat.(errors|model) don't set the __loader__ attribute

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

From report at bugs.python.org  Sun Feb  3 17:48:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:48:10 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1359910090.57.0.439755067958.issue17115@psf.upfronthosting.co.za>


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


----------
dependencies: +Raise ValueError when __loader__ not defined for importlib.find_loader()

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

From report at bugs.python.org  Sun Feb  3 17:49:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:49:34 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
Message-ID: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The various importlib.util decorators involved with __loader__ should reset the attribute when it is set to None, just like for __package__.

----------
assignee: brett.cannon
components: Library (Lib)
messages: 181281
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Update importlib.util.module_for_loader/set_loader to set when __loader__ = None
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Feb  3 17:49:43 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:49:43 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1359910183.06.0.48647549023.issue17115@psf.upfronthosting.co.za>


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


----------
dependencies: +Update importlib.util.module_for_loader/set_loader to set when __loader__ = None

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

From report at bugs.python.org  Sun Feb  3 17:49:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 16:49:52 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1359910192.85.0.397127380764.issue17114@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Can you please provide your config-highlight.cfg?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Feb  3 17:50:00 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:50:00 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1359910200.86.0.893423974693.issue17099@psf.upfronthosting.co.za>


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


----------
assignee:  -> brett.cannon

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

From report at bugs.python.org  Sun Feb  3 17:50:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:50:09 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1359910209.74.0.31946991856.issue17117@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Sun Feb  3 17:50:18 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 16:50:18 +0000
Subject: [issue17116] xml.parsers.expat.(errors|model) don't set the
	__loader__ attribute
In-Reply-To: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za>
Message-ID: <1359910218.95.0.405168635224.issue17116@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Sun Feb  3 18:03:50 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 17:03:50 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1359911030.18.0.821462461616.issue17115@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Screw it, forget the "like" and make that a "will happen". A What's New entry telling people to update their code to use a getattr() with a None default value for transitioning should be enough (and a single line change for the few people who would care about this).

This will also require an updating of the importlib docs, language reference, and PEP 302 to say the language reference and importlib docs now supersede the PEP. For both attributes it should be stated that a value of None means "I don't know what the values should be", but that loaders should continue to be required to set them.

----------

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

From report at bugs.python.org  Sun Feb  3 19:59:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 18:59:05 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <3YzhD858bhzSTD@mail.python.org>


Roundup Robot added the comment:

New changeset d2f6f63e73af by Gregory P. Smith in branch '3.2':
Update the embedded copy of the expat XML parser to 2.1.0.  It brings
http://hg.python.org/cpython/rev/d2f6f63e73af

----------

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

From report at bugs.python.org  Sun Feb  3 20:01:02 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Feb 2013 19:01:02 +0000
Subject: [issue14340] Update embedded copy of expat - fix security & crash
	issues
In-Reply-To: <1331933306.8.0.658837557797.issue14340@psf.upfronthosting.co.za>
Message-ID: <1359918062.03.0.199105754424.issue14340@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

done.

btw, it looks like benjamin.peterson did it for 2.7 yesterday morning but when 'hg graft' is used to apply a change from another branch the roundup notification mentions the original commit's author, not the person who did the push of the graft.

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

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

From report at bugs.python.org  Sun Feb  3 20:10:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:10:30 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
Message-ID: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds tests for testing how Python values converted when passed to Tkinter and back. This patch was a part of issue16840, but other issues need this tests.

----------
assignee: serhiy.storchaka
components: Tests, Tkinter
files: tkinter_test_passing_values.patch
keywords: patch
messages: 181286
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for testing Python-Tcl interaction
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28946/tkinter_test_passing_values.patch

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

From report at bugs.python.org  Sun Feb  3 20:21:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:21:42 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1359919302.32.0.949033662493.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 2.7
Added file: http://bugs.python.org/file28947/tkinter_test_passing_values-2.7.patch

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

From report at bugs.python.org  Sun Feb  3 20:33:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Feb 2013 19:33:52 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1359920032.46.0.432282636209.issue7358@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Suggested workaround: use io.BytesIO instead of cStringIO.

comments on the patch... in short: your patch is changing an ABI and isn't suitable for a maintenance release.

I'm not sure how much we can usefully do to cStringIO in a maintenance release.  I'd be inclined to close as wontfix as io.BytesIO is available.

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

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

From report at bugs.python.org  Sun Feb  3 20:35:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:35:39 +0000
Subject: [issue17119] Integer overflow when passing large string to Tkinter
Message-ID: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Second argument of Tcl_NewUnicodeObj() which specifies a number of characters has type "int". When a large string with more than INT_MAX characters passed to Tkinter this value will overflow. If this parameter is negative, all characters up to the first null character are used (up to the end of string because current string implementation has null character after the end). When string length will be more than UINT_MAX, always only part of string will be converted.

I?propose explicitly check a string length and raise an exception when the length overflows C?int range.

----------
components: Tkinter
messages: 181288
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Integer overflow when passing large string to Tkinter
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 20:35:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:35:55 +0000
Subject: [issue17119] Integer overflow when passing large string to Tkinter
In-Reply-To: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>
Message-ID: <1359920155.61.0.330412936417.issue17119@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Add tests for testing Python-Tcl interaction

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

From report at bugs.python.org  Sun Feb  3 20:42:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 19:42:06 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1359920526.95.0.835937397455.issue7358@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Not making cStringIO 64-bit compatible is one thing. But we can still fix the crashes by detecting an overflow before it happens ;)

----------

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

From report at bugs.python.org  Sun Feb  3 20:49:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 19:49:20 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1359920960.16.0.42459287138.issue7358@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Suggested workaround: use io.BytesIO instead of cStringIO.

Well, maybe we can replace cStringIO by io.BytesIO in cPickle (and other places).

> comments on the patch... in short: your patch is changing an ABI and isn't suitable for a maintenance release.

Isn't this a private API?

>?I'm not sure how much we can usefully do to cStringIO in a maintenance release.  I'd be inclined to close as wontfix as io.BytesIO is available.

We can't just close this issue. cStringIO crashes Python. We can use another approach. Change cStringIO so that user can't write or read more than INT_MAX?bytes at a time (an exception will be raised instead of crash), but can write more than INT_MAX?bytes in sum and get all string with getvalue(). This will preserve an ABI.

----------

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

From report at bugs.python.org  Sun Feb  3 20:50:28 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 19:50:28 +0000
Subject: [issue17113] argparse.RawDescriptionHelpFormatter should not delete
	blank lines
In-Reply-To: <1359899140.94.0.20575006786.issue17113@psf.upfronthosting.co.za>
Message-ID: <1359921028.27.0.705013568397.issue17113@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +bethard, chris.jerdonek

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

From report at bugs.python.org  Sun Feb  3 20:56:40 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 19:56:40 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359921400.23.0.60000925023.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

How does the "+" level relate to the convention described here?

http://docs.python.org/devguide/documenting.html#sections

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Sun Feb  3 20:57:25 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 19:57:25 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359921445.78.0.938853527643.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Never mind :)

----------

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

From report at bugs.python.org  Sun Feb  3 21:02:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 20:02:29 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1359921749.22.0.604083727758.issue17115@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Mmmh, what is the point of forcing people to adapt their module-like objects so that they have a __loader__ entry?
Couldn't importlib just interpret the absence of __loader__ as a None?

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

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

From report at bugs.python.org  Sun Feb  3 21:06:26 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 20:06:26 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359921986.51.0.915325663969.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I see why I was confused.  The ~'s are different from -'s.  The tilde level isn't listed in our devguide conventions.

----------

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

From report at bugs.python.org  Sun Feb  3 21:17:18 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Feb 2013 20:17:18 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1359922638.69.0.884050950337.issue7358@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Include/cStringIO.h is public and the name of the structure "PycStringIO" lacks an _ which implies that it is public.

There appear to be a few references to it in external projects doing some searching.  A (very old) version of twisted/protocols/_c_urlarg.c uses it for example.

Doing the latter and limiting writes to INT_MAX but allowing greater to accumulate makes sense.

----------

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

From report at bugs.python.org  Sun Feb  3 21:19:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 20:19:16 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359921986.51.0.915325663969.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359922578.3415.24.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I see why I was confused.  The ~'s are different from -'s.  The tilde
> level isn't listed in our devguide conventions.

I think the conventions are just conventions, and docutils / sphinx
don't enforce any order. I may be wrong though.

----------

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

From report at bugs.python.org  Sun Feb  3 21:31:35 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Feb 2013 20:31:35 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1359923495.51.0.745441154506.issue6083@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Serhiy's patch looks good to me.

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

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

From report at bugs.python.org  Sun Feb  3 21:56:32 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 03 Feb 2013 20:56:32 +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: <1359924992.96.0.769514366269.issue7083@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Anatoly, please stop playing with the headers. It is meaningless and irritating, especially when you set them wrong. The 3.5 choice is for issues that will *not* apply before then. An example is actually making a change warned about in a deprecation warning. 3.2 will soon see its last regular bugfix release. The main purpose of the headers is to help developers develop and apply a patch. The secondary purpose is serve as history and to inform users.

As I explained in my email to you
1. The OP meant for this to be a code bug report.
2. This was properly closed as an invalid bug report. So there will be no code patch. So the headers have no use except as history.
3. I do believe the doc should be changed, *and* I believe it should be a new issue. If I do open one, I will try to remember to add it here as superseder.

----------

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

From report at bugs.python.org  Sun Feb  3 22:09:09 2013
From: report at bugs.python.org (Andrey Kislyuk)
Date: Sun, 03 Feb 2013 21:09:09 +0000
Subject: [issue14103] argparse: add ability to create a bash completion script
In-Reply-To: <1330031882.01.0.825351616002.issue14103@psf.upfronthosting.co.za>
Message-ID: <1359925749.01.0.34298761299.issue14103@psf.upfronthosting.co.za>


Andrey Kislyuk added the comment:

FYI: http://pypi.python.org/pypi/argcomplete

----------
nosy: +Andrey.Kislyuk

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

From report at bugs.python.org  Sun Feb  3 22:19:28 2013
From: report at bugs.python.org (Daniel Black)
Date: Sun, 03 Feb 2013 21:19:28 +0000
Subject: [issue17107] test_sni in test_urllib2net could be enabled
In-Reply-To: <1359843352.18.0.227762212958.issue17107@psf.upfronthosting.co.za>
Message-ID: <1359926368.62.0.678937030548.issue17107@psf.upfronthosting.co.za>


Daniel Black added the comment:

ask and you shall receive :-)

----------
keywords: +patch
nosy: +grooverdan
versions: +Python 3.5
Added file: http://bugs.python.org/file28948/https_sni_test.patch

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

From report at bugs.python.org  Sun Feb  3 22:24:14 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 03 Feb 2013 21:24:14 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1359926654.28.0.538884692519.issue17115@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It will interpret its absence as None, but I would rather get the very common case of actual module instances just setting None automatically. Not having it set when None is already an accepted default value for __package__ seems inconsistent; either the lack of attribute should signify that the value is unknown for both values, or having None should, but not both. I'm advocating for the latter as it has an easier compatibility path. Plus I'm not worrying about random objects people stash into sys.modules, just real modules created from imp.new_module()/PyModule_Create(); if you muck with sys.modules you are on your own.

----------

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

From report at bugs.python.org  Sun Feb  3 22:56:52 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2013 21:56:52 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359928612.02.0.777654333412.issue17109@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Antoine is right.  It's probably ok to remove that suggestion completely.

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

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

From report at bugs.python.org  Sun Feb  3 23:05:56 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 22:05:56 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359929156.61.0.564447165267.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I think the guidance is still helpful.  I have referred to it often.  It can just be changed to being a suggestion as opposed to "the convention that we use."

----------

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

From report at bugs.python.org  Mon Feb  4 00:36:59 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 03 Feb 2013 23:36:59 +0000
Subject: [issue14103] argparse: add ability to create a bash completion script
In-Reply-To: <1359925749.01.0.34298761299.issue14103@psf.upfronthosting.co.za>
Message-ID: <CAA77j2BPkqE05RwyOnUCCE=JSH4VE3XFocwH7JL6W1bx2VT2+w@mail.gmail.com>


Tshepang Lekhonkhobe added the comment:

thanks so much; will play with it soon enough

----------

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

From report at bugs.python.org  Mon Feb  4 01:27:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 00:27:26 +0000
Subject: [issue5289] ctypes.util.find_library does not work under Solaris
In-Reply-To: <1234858635.81.0.426092533899.issue5289@psf.upfronthosting.co.za>
Message-ID: <3YzqW21SK6zSVJ@mail.python.org>


Roundup Robot added the comment:

New changeset d76fb24d79c3 by Benjamin Peterson in branch '2.7':
fix find_library on Solaris (closes #5289)
http://hg.python.org/cpython/rev/d76fb24d79c3

New changeset 73574de2068b by Benjamin Peterson in branch '3.3':
fix find_library on Solaris (closes #5289)
http://hg.python.org/cpython/rev/73574de2068b

New changeset 640a80adb9df by Benjamin Peterson in branch 'default':
merge 3.3 (#5289)
http://hg.python.org/cpython/rev/640a80adb9df

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 03:15:51 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 02:15:51 +0000
Subject: [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359944151.12.0.379392505661.issue17091@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

Was this already taken care of? http://docs.python.org/2/library/thread.html?highlight=thread.lock#thread.lock.acquire and http://docs.python.org/3.3/library/_thread.html?highlight=thread.lock#_thread.lock.acquire don't make any mention of returning None.

----------
nosy: +icordasc

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

From report at bugs.python.org  Mon Feb  4 03:27:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 02:27:34 +0000
Subject: [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359944854.36.0.826852720546.issue17091@psf.upfronthosting.co.za>


R. David Murray added the comment:

Armin is talking about the docstring, not the docs.  That is, what you get if you do help(x.acquire), where x is a Lock object, at the Python prompt.

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

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

From report at bugs.python.org  Mon Feb  4 03:28:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 02:28:03 +0000
Subject: [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359944883.42.0.665970210921.issue17091@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.3, Python 3.4 -Python 3.5

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

From report at bugs.python.org  Mon Feb  4 03:54:26 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 02:54:26 +0000
Subject: [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359946466.13.0.905217582376.issue17091@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

Thanks. I couldn't find it in the source but I just found Modules/_threadmodule.c

I tested the method from the interpreter to confirm the changes I was making to the docstring. Attached is a diff that covers the change.

----------
Added file: http://bugs.python.org/file28949/doc_fix.txt

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

From report at bugs.python.org  Mon Feb  4 06:39:07 2013
From: report at bugs.python.org (RAW)
Date: Mon, 04 Feb 2013 05:39:07 +0000
Subject: [issue17120] Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in
	pyconfig.h
Message-ID: <1359956347.87.0.611737971795.issue17120@psf.upfronthosting.co.za>


New submission from RAW:

The header file pyconfig.h mishandles the _POSIX_C_SOURCE and _XOPEN_SOURCE preprocessor macros.

For older versions of Python, the pyconfig.h header specifies:

#define _POSIX_C_SOURCE 200112L

and:

#define _XOPEN_SOURCE 600

For newer versions of Python, the pyconfig.h header specifies:

#define _POSIX_C_SOURCE 200809L

and:

#define _XOPEN_SOURCE 700

The Open Group has documentation about these symbols:

http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html

In particular, the documentation states:

A POSIX-conforming application should ensure that the feature test macro _POSIX_C_SOURCE is defined before inclusion of any header.

So, having a header file attempting to set _POSIX_C_SOURCE violates this intention.

Yes, I am well aware that the Python documentation says to include Python.h before any standard headers are included.  However, this is still problematic.

In particular, it causes trouble for source code that wishes to include the Python headers and wishes to use declarations that are made visible by setting later values for _POSIX_C_SOURCE and _XOPEN_SOURCE.

I would suggest the pyconfig.h be updated to have something like this:

#if !defined(_POSIX_C_SOURCE) || _POSIX_C_SOURCE < 200112L
#ifdef _POSIX_C_SOURCE
#warning Python expects -D_POSIX_C_SOURCE=200112L or later
#undef _POSIX_C_SOURCE
#endif
#define _POSIX_C_SOURCE 200112L
#endif

and this:

#if !defined(_XOPEN_SOURCE) || _XOPEN_SOURCE < 600
#ifdef _XOPEN_SOURCE
#warning Python expects -D_XOPEN_SOURCE=600 or later
#undef _XOPEN_SOURCE
#endif
#define _XOPEN_SOURCE 600
#endif

----------
components: Library (Lib)
messages: 181309
nosy: RAW
priority: normal
severity: normal
status: open
title: Mishandled _POSIX_C_SOURCE and _XOPEN_SOURCE in pyconfig.h
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Feb  4 07:37:01 2013
From: report at bugs.python.org (Patrick)
Date: Mon, 04 Feb 2013 06:37:01 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1359959821.29.0.844061980712.issue10365@psf.upfronthosting.co.za>


Patrick added the comment:

Forgive me if I'm not following the correct process. But I believe I have seen this issue again in 3.3. Not sure I captured exactly what is needed from the command line. The file being openeed is from the Python Hands On Class Examples http://anh.cs.luc.edu/python/hands-on/

c:\python33\python.exe -m idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "c:\python33\lib\idlelib\MultiCall.py", line 174, in handler
    doafterhandler.pop()()
  File "c:\python33\lib\idlelib\MultiCall.py", line 221, in <lambda>
    doit = lambda: self.bindedfuncs[triplet[2]][triplet[0]].remove(func)
ValueError: list.remove(x): x not in list
Traceback (most recent call last):
  File "c:\python33\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "c:\python33\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "c:\python33\lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "c:\python33\lib\idlelib\PyShell.py", line 1477, in main
    root.mainloop()
  File "c:\python33\lib\tkinter\__init__.py", line 1038, in mainloop
    self.tk.mainloop(n)

----------
nosy: +Patrick.Walters

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

From report at bugs.python.org  Mon Feb  4 09:51:06 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Feb 2013 08:51:06 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1359967866.63.0.651238044959.issue17069@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Here is he patch against the default that would address this reported issue. Same would go for other 3.x branches. The 2.7 only can just see the addition of getcode() documented.

----------
assignee:  -> orsenthil
keywords: +patch
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2, Python 3.3, Python 3.4 -Python 2.6
Added file: http://bugs.python.org/file28950/Issue17069-default.patch

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

From report at bugs.python.org  Mon Feb  4 10:21:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 09:21:55 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1359969715.1.0.258430180123.issue7358@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for review and enlightenment Gregory. Here is an updated patch which doesn't change an ABI.

----------
Added file: http://bugs.python.org/file28951/cStringIO64_2.patch

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

From report at bugs.python.org  Mon Feb  4 11:03:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 10:03:42 +0000
Subject: [issue17121] SSH upload for distutils
Message-ID: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>


New submission from Christian Heimes:

In the light of Ruby's recent issues and man in the middle attacks on PyPI (http://www.reddit.com/r/Python/comments/17rfh7/warning_dont_use_pip_in_an_untrusted_network_a/) we should include secure uploads in distutils.

Martin has created a SSH uploader for distutils http://pypi.python.org/pypi/pypissh. I suggest that we include the feature in the next security update for Python 2.6 to 3.3. I'm well aware that this beats the "no new feature" clause but in my opinion "security beats purity".

What do you think?

----------
assignee: eric.araujo
components: Distutils
messages: 181313
nosy: christian.heimes, eric.araujo, gregory.p.smith, gvanrossum, loewis, pitrou, tarek
priority: critical
severity: normal
stage: needs patch
status: open
title: SSH upload for distutils
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 11:24:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 10:24:45 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <604464792.7198009.1359973478222.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Martin has created a SSH uploader for distutils
> http://pypi.python.org/pypi/pypissh. I suggest that we include the
> feature in the next security update for Python 2.6 to 3.3. I'm well
> aware that this beats the "no new feature" clause but in my opinion
> "security beats purity".

"this package performs heavy monkey-patching of distutils to make it
use the system's ssh command. Users using this package should run
ssh-agent (which runs automatically in the background on many systems)
and load their PyPI key into the ssh agent."

I don't think this bodes well for immediate inclusion, especially in
a bugfix release. Perhaps some time should be taken to clean it up
and then include it in 3.4.

I'm still not sure why this would be better than HTTPS upload, though.

----------

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

From report at bugs.python.org  Mon Feb  4 11:32:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 10:32:05 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359973925.33.0.31676391217.issue17121@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python 2.6 to 3.1 don't do HTTPS server cert validation. This leaves the upload process open to MITM attacks ...

----------

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

From report at bugs.python.org  Mon Feb  4 12:05:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 11:05:35 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <3Z05gL6jNjzQ0L@mail.python.org>


Roundup Robot added the comment:

New changeset a4c85f9b8f58 by Serhiy Storchaka in branch '2.7':
Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple
http://hg.python.org/cpython/rev/a4c85f9b8f58

New changeset 4bac47eb444c by Serhiy Storchaka in branch '3.2':
Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple
http://hg.python.org/cpython/rev/4bac47eb444c

New changeset e0ee10f27e5f by Serhiy Storchaka in branch '3.3':
Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple
http://hg.python.org/cpython/rev/e0ee10f27e5f

New changeset 3e3a7d825736 by Serhiy Storchaka in branch 'default':
Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple
http://hg.python.org/cpython/rev/3e3a7d825736

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  4 13:03:51 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 04 Feb 2013 12:03:51 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359979431.5.0.902821866699.issue17121@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

I would strongly prefer to back port certificate validation instead. Is there anything *practical* that makes it hard/impossible?

If we want to keep features stable, we can add it privately so it?s only usable by distutils. The susceptibility to (easy!) MITM attacks can be counted as a security bug and this seems the most practical resolve.

----------
nosy: +hynek

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

From report at bugs.python.org  Mon Feb  4 13:17:12 2013
From: report at bugs.python.org (Swarnkar Rajesh)
Date: Mon, 04 Feb 2013 12:17:12 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1359980232.85.0.483331848998.issue17114@psf.upfronthosting.co.za>


Swarnkar Rajesh added the comment:

Sure, Here it is:

[Rajesh_Python_Settings]
definition-foreground = #86deff
error-foreground = #ff1c1c
normal-foreground = #ffffff
keyword-foreground = #fff900
hilite-foreground = #000000
comment-background = #511633
hit-foreground = #ffffff
builtin-background = #511633
stdout-foreground = #efefef
cursor-foreground = #fffff5
string-background = #511633
break-background = #ffff55
comment-foreground = #997678
hilite-background = gray
definition-background = #511633
stderr-background = #511633
hit-background = #000000
console-foreground = #2cbbff
normal-background = #511633
builtin-foreground = #f4cec6
stdout-background = #511630
console-background = #511644
stderr-foreground = #ff5900
keyword-background = #511633
string-foreground = #00e05b
break-foreground = black
error-background = #311634
cursor-foreground = black

[Obsidian]
definition-foreground = #678CB1
error-foreground = #FF0000
string-background = #293134
keyword-foreground = #93C763
normal-foreground = #E0E2E4
comment-background = #293134
hit-foreground = #E0E2E4
builtin-background = #293134
stdout-foreground = #678CB1
cursor-foreground = #E0E2E4
break-background = #293134
comment-foreground = #66747B
hilite-background = #2F393C
hilite-foreground = #E0E2E4
definition-background = #293134
stderr-background = #293134
hit-background = #000000
console-foreground = #E0E2E4
normal-background = #293134
builtin-foreground = #E0E2E4
stdout-background = #293134
console-background = #293134
stderr-foreground = #FB0000
keyword-background = #293134
string-foreground = #EC7600
break-foreground = #E0E2E4
error-background = #293134

The erlier one is my own custom setting, i edited it on idle and saved as custom theme. Also to mention later one theme added via text editor from this site: ramdump(dot)com/2011/08/04/obsidian-theme-for-idle/. 
Thanks.

----------

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

From report at bugs.python.org  Mon Feb  4 13:29:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 12:29:24 +0000
Subject: [issue17122] Fix and cleanup test_functools
Message-ID: <1359980964.91.0.854026651157.issue17122@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since changeset fcfaca024160 (issue12428) subclassing of partial actually is not tested (subclassed partial overwritten in setUp() method). The proposed patch fixes this and some other minor issues and cleanup the code.

----------
assignee: serhiy.storchaka
components: Tests
files: test_functools.diff
keywords: patch
messages: 181319
nosy: pitrou, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Fix and cleanup test_functools
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file28952/test_functools.diff

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

From report at bugs.python.org  Mon Feb  4 13:39:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 12:39:00 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1359981540.13.0.786931575007.issue17114@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Run IDLE?from command line and you will see:

configparser.DuplicateOptionError: While reading from .../.idlerc/config-highlight.cfg [line 29]: option 'cursor-foreground' in section 'Rajesh_Python_Settings' already exists

Your configuration is wrong. Just remove duplicated option 'cursor-foreground' (and other duplications if they exist).

However 2.7 and 3.1 are tolerant for this. This is an IDLE bug, a regression in 3.2.

----------
keywords: +3.2regression
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 13:46:12 2013
From: report at bugs.python.org (Swarnkar Rajesh)
Date: Mon, 04 Feb 2013 12:46:12 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1359981972.51.0.859125492075.issue17114@psf.upfronthosting.co.za>


Swarnkar Rajesh added the comment:

Thank you Serhiy Storchaka.
It worked well. I did not noticed that. 
Thanks again.

----------

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

From report at bugs.python.org  Mon Feb  4 13:49:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 12:49:36 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1359982176.21.0.894126743811.issue17114@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

ConfigParser is more strong by default since 3.2. Here is a simple patch which made IDLE more tolerant for such kind of user errors.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28953/idle_nonstrict_config.patch

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

From report at bugs.python.org  Mon Feb  4 13:58:47 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 04 Feb 2013 12:58:47 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359982727.12.0.707987626853.issue17121@psf.upfronthosting.co.za>


Donald Stufft added the comment:

+1 for back porting SSL validation even if it's a private to distutils backport.

pypissh requires a SSH Binary which isn't all that great on Windows where SSH is not typically installed by default.

----------
nosy: +dstufft

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

From report at bugs.python.org  Mon Feb  4 14:00:29 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 13:00:29 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359982829.19.0.456252529767.issue17121@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Infrastructure needs to get a proper SSL cert first and we have to ship the CA's public key so we can verify the cert everywhere.

----------

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

From report at bugs.python.org  Mon Feb  4 14:03:24 2013
From: report at bugs.python.org (Swarnkar Rajesh)
Date: Mon, 04 Feb 2013 13:03:24 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1359983004.47.0.880174946656.issue17114@psf.upfronthosting.co.za>


Swarnkar Rajesh added the comment:

How can i install this patch?

----------

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

From report at bugs.python.org  Mon Feb  4 14:13:36 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 04 Feb 2013 13:13:36 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359983616.3.0.823082053522.issue17121@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Well Infrastructure *should* get a proper cert anyways else MITM is trivial via the web interface anyways.

----------

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

From report at bugs.python.org  Mon Feb  4 14:33:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 13:33:24 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1359984804.12.0.0965064657374.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I do not have possibility and desires blind-repair a test on alien platform, so just temporarily disable a new test in Lib/ctypes/test/test_returnfuncptrs.py on Windows. If someone has a desire to fix it fell free to do this.

I?do not close this issue because committed patch only fix existing crashes in Python. There should be plenty of such bugs in third-party code. We have to deprecate this unsafe feature or reject any sequences except tuple as Alexander proposed.

----------
stage: patch review -> needs patch
versions:  -Python 3.1

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

From report at bugs.python.org  Mon Feb  4 14:34:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 13:34:37 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1359984877.43.0.199071076753.issue6083@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: serhiy.storchaka -> 

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

From report at bugs.python.org  Mon Feb  4 14:36:09 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 04 Feb 2013 13:36:09 +0000
Subject: [issue17103] ampersand "&" in path prevents compilation of Python
In-Reply-To: <1359796958.56.0.232245529308.issue17103@psf.upfronthosting.co.za>
Message-ID: <1359984969.69.0.235089485481.issue17103@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: ampersand "&" in path prevents from compiling pthon -> ampersand "&" in path prevents compilation of Python

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

From report at bugs.python.org  Mon Feb  4 15:44:14 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 14:44:14 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1359989054.59.0.402056377043.issue16555@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Benjamin, does this have to wait for 2.7.5?

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

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

From report at bugs.python.org  Mon Feb  4 15:46:13 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Feb 2013 14:46:13 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1359989173.83.0.0670469827654.issue16555@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Is there some sort of reference for these aliases? Where do they come from?

----------

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

From report at bugs.python.org  Mon Feb  4 15:52:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 14:52:14 +0000
Subject: [issue16903] subprocess.Popen.communicate with
	universal_newlines=True doesn't accept strings on 3.2
In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za>
Message-ID: <3Z0Bhs6nHgzSb7@mail.python.org>


Roundup Robot added the comment:

New changeset 4206f91c974c by Serhiy Storchaka in branch '3.2':
Issue #16903: Popen.communicate() on Unix now accepts strings when
http://hg.python.org/cpython/rev/4206f91c974c

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  4 15:59:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 14:59:50 +0000
Subject: [issue16903] subprocess.Popen.communicate with
	universal_newlines=True doesn't accept strings on 3.2
In-Reply-To: <1357723737.45.0.474075490157.issue16903@psf.upfronthosting.co.za>
Message-ID: <1359989990.37.0.412629353931.issue16903@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 16:26:18 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 15:26:18 +0000
Subject: [issue17096] the system keyring should be used instead of ~/.pypirc
In-Reply-To: <1359683125.78.0.593949491252.issue17096@psf.upfronthosting.co.za>
Message-ID: <1359991578.5.0.182305018626.issue17096@psf.upfronthosting.co.za>


?ric Araujo added the comment:

The general idea is absolutely right: using proper keyrings (or ssh) is an excellent thing for security and ease of use.  A big obstacle however is the rules for stdlib inclusion: a module such as keyring which is tied to specific applications/libs/file formats and may need a short release cycle to adapt for changes in the programs.  So while I think keyring is a great library, I fear it does not fit the criteria for stdlib inclusion.

The workaround is to enter your password each time you upload and never store it.  This isn?t great.

What if there was an option specifying a program to call to get the password?  That way one could use clvault (command-line interface to python-keyring), maybe ssh-askpass, keepass, etc., but we wouldn?t have code subject to obsolescence in the stdlib.  It would not be as nice as seamless password retrieval, and it would not be 100% secure (password is still in memory), but it would solve the storage problem.  What do you think?

[FYI the distutils2 project is stopped.  I don?t have the time right now to go into details again, and there isn?t a single link I can give that explains things well.]

----------
components: +Distutils -Distutils2
versions: +Python 3.4

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

From report at bugs.python.org  Mon Feb  4 16:30:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 15:30:19 +0000
Subject: [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <3Z0CXp1X1kzSS5@mail.python.org>


Roundup Robot added the comment:

New changeset 0cc51c04aa20 by R David Murray in branch '3.2':
#17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/0cc51c04aa20

New changeset b414b2dfd3d3 by R David Murray in branch '3.3':
merge #17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/b414b2dfd3d3

New changeset a80abb179ba1 by R David Murray in branch 'default':
merge #17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/a80abb179ba1

New changeset 20f0c5398e97 by R David Murray in branch '2.7':
#17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/20f0c5398e97

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  4 16:30:46 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 15:30:46 +0000
Subject: [issue13756] Python3.2.2 make fail on cygwin
In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za>
Message-ID: <1359991846.11.0.00527338299762.issue13756@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I have no objection to the patch.  I can?t test it on cygwin (unless snakebite provides it, I?ll ask) but I can check that a linux build still works.

----------
keywords: +needs review
stage:  -> patch review
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 16:31:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 15:31:42 +0000
Subject: [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359991902.87.0.351924208116.issue17091@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Ian.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Mon Feb  4 16:33:40 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 15:33:40 +0000
Subject: [issue15485] CROSS: append gcc library search paths
In-Reply-To: <1343555717.99.0.825702829621.issue15485@psf.upfronthosting.co.za>
Message-ID: <1359992020.78.0.530237565938.issue15485@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +doko, eric.araujo
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Mon Feb  4 16:35:50 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 15:35:50 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1359992150.17.0.0985148965716.issue15298@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Can this be closed?

----------

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

From report at bugs.python.org  Mon Feb  4 16:49:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 15:49:56 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359992996.48.0.815106215442.issue17121@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

PyPI *has* a proper cert, it's just not in the default trusted certs of most distributions and browsers (i.e., it uses CACert). It would be easy to bundle CACert's root cert with distutils, if we wanted to.

----------

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

From report at bugs.python.org  Mon Feb  4 16:50:49 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 15:50:49 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1359993048.99.0.292864219042.issue17069@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Are these the addinfourl getters that Ezio wants to deprecate?

----------

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

From report at bugs.python.org  Mon Feb  4 16:55:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 15:55:19 +0000
Subject: [issue17077] Fix test_tools hangs
In-Reply-To: <1359484777.42.0.023750065374.issue17077@psf.upfronthosting.co.za>
Message-ID: <1359993319.46.0.851902580567.issue17077@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed changeset 4be538a058a8. Thank you for the patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 17:03:40 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 16:03:40 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1359993820.86.0.242661914911.issue12779@psf.upfronthosting.co.za>


Changes by Ian Cordasco <graffatcolmingov at gmail.com>:


----------
nosy: +icordasc, larry

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

From report at bugs.python.org  Mon Feb  4 17:08:24 2013
From: report at bugs.python.org (Benjamin Ash)
Date: Mon, 04 Feb 2013 16:08:24 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1359994104.7.0.328608172969.issue12502@psf.upfronthosting.co.za>


Benjamin Ash added the comment:

Hi Charles-Fran?ois,

I am using a recent version of Python-2.7 that does in fact contains this patch http://hg.python.org/cpython/rev/16bc59d37866:
  python-2.7.3-4.fc16.x86_64 (Fedora 16)

The CPU usage spikes after I make the initial client connection to the socket.

I am able to reproduce the issue using the attached script 'asyncore_test.py', and any of the following:
 - simple asyncore.dispatcher_with_send client.
 - simple asyncore.dispatcher client.
 - a direct socket.socket() connection.

Not sure what might be going wrong here. Any help would be most appreciated.

Thanks,

-ben

----------

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

From report at bugs.python.org  Mon Feb  4 17:10:10 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 16:10:10 +0000
Subject: [issue6761] Class calling
In-Reply-To: <1250961239.16.0.126736964049.issue6761@psf.upfronthosting.co.za>
Message-ID: <1359994210.09.0.118649001996.issue6761@psf.upfronthosting.co.za>


Changes by Ian Cordasco <graffatcolmingov at gmail.com>:


----------
nosy: +icordasc

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

From report at bugs.python.org  Mon Feb  4 17:14:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 16:14:32 +0000
Subject: [issue17123] Add OCSP support to ssl module
Message-ID: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python's ssl module doesn't support OCSP [1]. The example code at [2] doesn't look too complicated. We should consider OCSP at least for 3.4 and may want to backport it to older versions to prevent MITM attacks on PyPI downloads.


[1]http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol)
[2] http://etutorials.org/Programming/secure+programming/Chapter+10.+Public+Key+Infrastructure/10.12+Checking+Revocation+Status+via+OCSP+with+OpenSSL/

----------
components: Extension Modules
messages: 181341
nosy: christian.heimes, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Add OCSP support to ssl module
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 17:15:30 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 16:15:30 +0000
Subject: [issue14940] Usage documentation for pysetup
In-Reply-To: <1338246677.91.0.429583785939.issue14940@psf.upfronthosting.co.za>
Message-ID: <1359994530.11.0.06951185223.issue14940@psf.upfronthosting.co.za>


?ric Araujo added the comment:

pysetup is no more.

----------
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 17:19:35 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 04 Feb 2013 16:19:35 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359994775.0.0.844896776088.issue17121@psf.upfronthosting.co.za>


Donald Stufft added the comment:

CACert is not *proper* irregardless of what that projects goals are. It is not trusted by default therefore it does not provide the same level of security in the browser (Very few people will bother to look at the difference between a CACert and a self signed cert). Further more I don't believe you'll be able to use HSTS with it at all making SSL Stripping a very easy avenue to a MITM.

----------

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

From report at bugs.python.org  Mon Feb  4 17:20:26 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 16:20:26 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1359994826.45.0.0488606750931.issue12779@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Packaging is removed from the stdlib and distutils2 is evolving into decoupled libs/tools.  Closing this effort :(

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 17:25:17 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 16:25:17 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359995117.55.0.702619901184.issue17121@psf.upfronthosting.co.za>


Christian Heimes added the comment:

And there is OCSP. I'm getting sec_error_ocsp_invalid_signing_cert for https://pypi.python.org/pypi. I haven't been able to do a successful HTTPS request from Firefox to PyPI all day.

----------

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

From report at bugs.python.org  Mon Feb  4 17:31:26 2013
From: report at bugs.python.org (Benjamin Ash)
Date: Mon, 04 Feb 2013 16:31:26 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1359995486.55.0.675667544046.issue12502@psf.upfronthosting.co.za>


Benjamin Ash added the comment:

After doing a bit more testing, I was able to prevent the problem from occurring in asyncore_test.py with the following patch:

--- /proc/self/fd/11	2013-02-04 11:24:41.298347199 -0500
+++ asyncore_test.py	2013-02-04 11:24:40.393318513 -0500
@@ -19,10 +19,18 @@
         self.bind(sock)
         self.listen(5)
 
-    def handle_accepted(self, sock, addr):
-        print('Incoming connection from %s' % repr(addr))
-        handler = EchoHandler(sock)
+    def handle_accept(self):
+        pair = self.accept()
+        if pair is not None:
+            (sock, addr) = pair
+            print('Incoming connection from %s' % repr(addr))
+            handler = EchoHandler(sock)

Using handle_accept() in my code and remembering to call listen() in my asyncore.dispatcher server's constructor did the trick.

I am not sure if we still have a bug here though, since if the subclass doesn't define  a proper handle_accept() we get into the select() loop and 100% CPU utilization after the initial client connection.

----------

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

From report at bugs.python.org  Mon Feb  4 17:32:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 16:32:53 +0000
Subject: [issue17089] Expat parser parses strings only when XML encoding is
	UTF-8
In-Reply-To: <1359626479.25.0.87229024986.issue17089@psf.upfronthosting.co.za>
Message-ID: <3Z0Dx115ThzSdB@mail.python.org>


Roundup Robot added the comment:

New changeset 3cc2a2de36e3 by Serhiy Storchaka in branch '3.2':
Issue #17089: Expat parser now correctly works with string input not only when
http://hg.python.org/cpython/rev/3cc2a2de36e3

New changeset 6c27b0e09c43 by Serhiy Storchaka in branch '3.3':
Issue #17089: Expat parser now correctly works with string input not only when
http://hg.python.org/cpython/rev/6c27b0e09c43

New changeset c4e6e560e6f5 by Serhiy Storchaka in branch 'default':
Issue #17089: Expat parser now correctly works with string input not only when
http://hg.python.org/cpython/rev/c4e6e560e6f5

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  4 17:50:54 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 16:50:54 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
Message-ID: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>


New submission from Dave Jones:

import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6

I'm running this test from a LiveCD to make sure the environment is relatively clean.

------------------
localhost Desktop # python --version
Python 2.7.3
-------------------  <<<works fine here>>>
localhost Desktop # cat sp.py
#!/usr/bin/python

import subprocess

print "Done......."

-------------------
localhost Desktop # ls -1 | wc -l
7

-------------------
localhost Desktop # time python sp.py 
Done.......

real	0m0.027s
user	0m0.023s
sys	0m0.003s


--- BUT--- <<< This cannot be right>>>
localhost Desktop # mv sp.py  ..
mv: overwrite `../sp.py'? y
localhost Desktop # cd ..
localhost jonesda0 # cat sp.py
#!/usr/bin/python

import subprocess

print "Done......."
localhost jonesda0 # time python sp.py 
100000000
Done.......

real	0m25.336s
user	0m25.270s
sys	0m0.014s
localhost jonesda0 # ls -1 | wc -l
758

Only change is the number of files in the directory.
I have tested this on several different LiveCDs but the results are the same.  Is there some sort of flag I need to know about?

FWIW, I do not see the problem when using python3..

localhost jonesda0 # yum -y install python3
Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit
...
Installed:
  python3.i686 0:3.1.2-14.fc14                                                                                                         

Dependency Installed:
  python3-libs.i686 0:3.1.2-14.fc14                                                                                                    

Complete!
localhost jonesda0 # time python3 sp.py  ## (print function...duh)
  File "sp.py", line 5
    print "Done......."
                      ^
SyntaxError: invalid syntax

real	0m0.048s
user	0m0.044s
sys	0m0.004s
localhost jonesda0 # vi sp.py 
localhost jonesda0 # time python3 sp.py 
Done.......

real	0m0.091s
user	0m0.084s
sys	0m0.006s

localhost jonesda0 # python3 --version
Python 3.1.2

----------
messages: 181348
nosy: Dave.Jones
priority: normal
severity: normal
status: open
title: import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  4 17:51:28 2013
From: report at bugs.python.org (Tyler Crompton)
Date: Mon, 04 Feb 2013 16:51:28 +0000
Subject: [issue17125] tokenizer.tokenize passes a bytes object to
	str.startswith
Message-ID: <1359996688.85.0.198838954965.issue17125@psf.upfronthosting.co.za>


New submission from Tyler Crompton:

Line 402 in lib/python3.3/tokenize.py, contains the following line:

    if first.startswith(BOM_UTF8):

BOM_UTF8 is a bytes object. str.startswith does not accept bytes objects. I was able to use tokenize.tokenize only after making the following changes:

Change line 402 to the following:

    if first.startswith(BOM_UTF8.decode()):

Add these two lines at line 374:

        except AttributeError:
            line_string = line

Change line 485 to the following:

            try:
                line = line.decode(encoding)
            except AttributeError:
                pass

I do not know if these changes are correct as I have not fully tested this module after these changes, but it started working for me. This is the meat of my invokation of tokenize.tokenize:

import tokenize

with open('example.py') as file: # opening a file encoded as UTF-8
	for token in tokenize.tokenize(file.readline):
		print(token)

I am not suggesting that these changes are correct, but I do believe that the current implementation is incorrect. I am also unsure as to what other versions of Python are affected by this.

----------
components: Library (Lib)
messages: 181349
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: tokenizer.tokenize passes a bytes object to str.startswith
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb  4 17:53:51 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 16:53:51 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1359996831.68.0.772266948412.issue17124@psf.upfronthosting.co.za>


Dave Jones added the comment:

That line (100000000) seems to pop up every time the subprocess call "hangs"

----------

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

From report at bugs.python.org  Mon Feb  4 18:02:56 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 17:02:56 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1359997376.03.0.0740779611958.issue17124@psf.upfronthosting.co.za>


Dave Jones added the comment:

Distros tested with include Funduntu 2012-4, Fuduntu 2013-1, Fedora 17, Scientific Linux 6.3 & OpenSUSE 12.2 (all 32-bit) on the same hardware.

----------

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

From report at bugs.python.org  Mon Feb  4 18:06:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 17:06:59 +0000
Subject: [issue17125] tokenizer.tokenize passes a bytes object to
	str.startswith
In-Reply-To: <1359996688.85.0.198838954965.issue17125@psf.upfronthosting.co.za>
Message-ID: <1359997619.95.0.524049088253.issue17125@psf.upfronthosting.co.za>


R. David Murray added the comment:

The docs could certainly be more explicit...currently they state that tokenize is *detecting* the encoding of the file, which *implies* but does not make explicit that the input must be binary, not text.

The doc problem will get fixed as part of the fix to issue 12486, so I'm closing this as a duplicate.  If you want to help out with a patch review and doc patch suggestions on that issue, that would be great.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> tokenize module should have a unicode API

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

From report at bugs.python.org  Mon Feb  4 18:07:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 17:07:19 +0000
Subject: [issue17123] Add OCSP support to ssl module
In-Reply-To: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>
Message-ID: <1858917529.8294643.1359997633369.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

Can you explain how OCSP helps prevent MITM attacks?

----- Mail original -----
> De: "Christian Heimes" <report at bugs.python.org>
> ?: pitrou at free.fr
> Envoy?: Lundi 4 F?vrier 2013 17:14:32
> Objet: [issue17123] Add OCSP support to ssl module
> 
> 
> New submission from Christian Heimes:
> 
> Python's ssl module doesn't support OCSP [1]. The example code at [2]
> doesn't look too complicated. We should consider OCSP at least for
> 3.4 and may want to backport it to older versions to prevent MITM
> attacks on PyPI downloads.

----------

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

From report at bugs.python.org  Mon Feb  4 18:09:40 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 04 Feb 2013 17:09:40 +0000
Subject: [issue13156] _PyGILState_Reinit assumes auto thread state will always
	exist which is not true.
In-Reply-To: <1318401227.21.0.161699609918.issue13156@psf.upfronthosting.co.za>
Message-ID: <1359997780.25.0.968144614286.issue13156@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/issue13156>
_______________________________________

From report at bugs.python.org  Mon Feb  4 18:09:59 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:09:59 +0000
Subject: [issue17123] Add OCSP support to ssl module
In-Reply-To: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>
Message-ID: <1359997799.84.0.99449838835.issue17123@psf.upfronthosting.co.za>


Christian Heimes added the comment:

OCSP can prevent MITM attacks when the private server cert or CA cert got compromised or stolen somehow.

----------

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

From report at bugs.python.org  Mon Feb  4 18:10:22 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:10:22 +0000
Subject: [issue17123] Add OCSP support to ssl module
In-Reply-To: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>
Message-ID: <1359997822.39.0.882768973278.issue17123@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +barry, benjamin.peterson, georg.brandl, larry
priority: high -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:10:56 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:10:56 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1359997856.74.0.42303328076.issue12226@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: normal -> release blocker
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Mon Feb  4 18:11:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:11:01 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1359997861.32.0.2198759122.issue17121@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +barry, benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:11:21 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:11:21 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1359997881.39.0.652120467696.issue16040@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:12:24 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:12:24 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1359997944.75.0.996594522273.issue16037@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:12:29 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:12:29 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1359997949.32.0.77672546604.issue16038@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:12:34 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:12:34 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1359997954.23.0.50733503024.issue16039@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:12:41 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:12:41 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1359997961.3.0.728719693529.issue16041@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:12:45 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:12:45 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1359997965.09.0.378934570193.issue16042@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:12:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 17:12:49 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1359997969.1.0.345401075689.issue16043@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: critical -> release blocker

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

From report at bugs.python.org  Mon Feb  4 18:36:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Feb 2013 17:36:35 +0000
Subject: [issue15298] _sysconfigdata is generated in srcdir, not builddir
In-Reply-To: <1341782776.55.0.708234468774.issue15298@psf.upfronthosting.co.za>
Message-ID: <1359999395.3.0.00505369739195.issue15298@psf.upfronthosting.co.za>


Ned Deily added the comment:

On OS X, Trent's fixes solved the bootstrap issue and _sysconfigdata.py is now created in buildir.  Closing.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 18:49:58 2013
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Feb 2013 17:49:58 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1360000198.24.0.77962898267.issue17099@psf.upfronthosting.co.za>


Eric Snow added the comment:

My vote is for making this a ValueError in both cases (and amending the doc appropriately as well).  The error amounts to the same thing: the module did not have loader (implicitly or explicitly).  If someone wants to distinguish between the two they can explicitly check __loader__ on the module.

Incidently, _find_and_load_unlocked() has similar code to find_loader() (Lib/importlib/_bootstrap:1523) and raises ImportError instead of ValueError.  That's actually fine since it's a different situation.  However, _find_module() does not handle when __loader__ does not exist, so you would get neither ValueError nor ImportError.  I expect we'd want it or _find_and_load_unlocked() to convert the AttributeError into ImportError to be consistent both with the fix for this issue and with how we handle the __loader__ == None case there.

---

For reference, here is the original python-dev thread:

  http://mail.python.org/pipermail/python-dev/2013-January/123777.html

The reference to ValueError is in the importlib docs:

  http://docs.python.org/dev/library/importlib.html#importlib.find_loader

----------

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

From report at bugs.python.org  Mon Feb  4 18:51:28 2013
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Feb 2013 17:51:28 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1360000288.25.0.240396339956.issue17117@psf.upfronthosting.co.za>


Eric Snow added the comment:

+1

----------
nosy: +eric.snow

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

From report at bugs.python.org  Mon Feb  4 18:53:09 2013
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Feb 2013 17:53:09 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1360000389.13.0.595004452824.issue17115@psf.upfronthosting.co.za>


Eric Snow added the comment:

> In all honesty I would like to tweak imp.new_module()/PyModule_Create()...

+1

----------
nosy: +eric.snow

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

From report at bugs.python.org  Mon Feb  4 18:56:55 2013
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Feb 2013 17:56:55 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1360000615.9.0.63184131565.issue17115@psf.upfronthosting.co.za>


Eric Snow added the comment:

> [document that] the language reference and importlib docs now supersede the PEP

Agreed.  PEP 302 is even crustier now than it was a year ago and Barry's new import page in the language reference obviates the need for 302 as the de facto spec.

----------

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

From report at bugs.python.org  Mon Feb  4 19:09:50 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Mon, 04 Feb 2013 18:09:50 +0000
Subject: [issue17092] Disable TIPC in configure
In-Reply-To: <1359652372.04.0.314648330864.issue17092@psf.upfronthosting.co.za>
Message-ID: <1360001390.38.0.49600052833.issue17092@psf.upfronthosting.co.za>


ddvento at ucar.edu added the comment:

Ok, I'm closing this ticket, since it does not seem there is interested in fixing it. I still believe it would be a nice feature, but life is short, let's concentrate efforts on more useful things.

Moreover (see Issue17085 for details) TIPC was not the root cause of the that other issue.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 19:19:56 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Mon, 04 Feb 2013 18:19:56 +0000
Subject: [issue17085] test_socket crashes the whole test suite
In-Reply-To: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za>
Message-ID: <1360001996.43.0.806684385753.issue17085@psf.upfronthosting.co.za>


ddvento at ucar.edu added the comment:

So I rebuild python withou tipc (basically deleting it from configure, since it cannot be "cleanly" avoided, see Issue17092).

The 'sudo modprobe tipc' message of course disappears, but the uncaught alarm is still there, see below:

./python Lib/test/regrtest.py -v test_socket
== CPython 2.7.3 (default, Feb 2 2013, 11:27:13) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/build/test_python_9390
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_socket
testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok
testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok
testGetServBy (test.test_socket.GeneralModuleTests) ... ok
testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok
testHostnameRes (test.test_socket.GeneralModuleTests) ... ok
testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok
testIPv4toString (test.test_socket.GeneralModuleTests) ... ok
testIPv6toString (test.test_socket.GeneralModuleTests) ... ok
testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok
testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok
testNewAttributes (test.test_socket.GeneralModuleTests) ... ok
testNtoH (test.test_socket.GeneralModuleTests) ... ok
testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok
testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok
testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok
testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok
testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testSockName (test.test_socket.GeneralModuleTests) ... ok
testSocketError (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok
test_flowinfo (test.test_socket.GeneralModuleTests) ... ok
test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok
test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... FAIL
test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ... FAIL
test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows specific'
test_weakref (test.test_socket.GeneralModuleTests) ... ok
testDup (test.test_socket.BasicTCPTest) ... ok
testFromFd (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok
testRecv (test.test_socket.BasicTCPTest) ... ok
testRecvFrom (test.test_socket.BasicTCPTest) ... ok
testSendAll (test.test_socket.BasicTCPTest) ... ok
testShutdown (test.test_socket.BasicTCPTest) ... ok
testClose (test.test_socket.TCPCloserTest) ... Alarm clock

----------

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

From report at bugs.python.org  Mon Feb  4 19:23:44 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 04 Feb 2013 18:23:44 +0000
Subject: [issue17123] Add OCSP support to ssl module
In-Reply-To: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>
Message-ID: <1360002224.34.0.870252074559.issue17123@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/issue17123>
_______________________________________

From report at bugs.python.org  Mon Feb  4 19:25:54 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Mon, 04 Feb 2013 18:25:54 +0000
Subject: [issue17085] test_socket crashes the whole test suite
In-Reply-To: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za>
Message-ID: <1360002354.88.0.547645060834.issue17085@psf.upfronthosting.co.za>


ddvento at ucar.edu added the comment:

Just to see this test running to completion, I applied the following (ugly) patch:

--- Lib/test/test_socket.py.orig    2012-04-09 17:07:32.000000000 -0600
+++ Lib/test/test_socket.py     2013-02-03 06:56:11.778118985 -0700
@@ -14,7 +14,7 @@
 import array
 import contextlib
 from weakref import proxy
-import signal
+#import signal
 import math
 
 def try_address(host, port=0, family=socket.AF_INET):
@@ -33,6 +33,12 @@
 MSG = b'Michael Gilfix was here\n'
 SUPPORTS_IPV6 = socket.has_ipv6 and try_address('::1', family=socket.AF_INET6)
 
+signal = "not a signal"
+
 try:
     import thread


With it, the test case completed as follows, which at least confirmed that the only broken part is sendall_interrupted. I'll live with it for now, but I'll be happy to work with the maintainer of these tests to understand what are they trying to accomplish, how to make them fail more gracefully (I tried installing a signal handler without success), and how to tell what to do to users of systems affected by the issue.


./python Lib/test/regrtest.py -v test_socket
== CPython 2.7.3 (default, Feb 2 2013, 11:27:13) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/build/test_python_16005
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_socket
testCrucialConstants (test.test_socket.GeneralModuleTests) ... ok
testDefaultTimeout (test.test_socket.GeneralModuleTests) ... ok
testGetServBy (test.test_socket.GeneralModuleTests) ... ok
testGetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testGetaddrinfo (test.test_socket.GeneralModuleTests) ... ok
testHostnameRes (test.test_socket.GeneralModuleTests) ... ok
testIPv4_inet_aton_fourbytes (test.test_socket.GeneralModuleTests) ... ok
testIPv4toString (test.test_socket.GeneralModuleTests) ... ok
testIPv6toString (test.test_socket.GeneralModuleTests) ... ok
testInterpreterCrash (test.test_socket.GeneralModuleTests) ... ok
testListenBacklog0 (test.test_socket.GeneralModuleTests) ... ok
testNewAttributes (test.test_socket.GeneralModuleTests) ... ok
testNtoH (test.test_socket.GeneralModuleTests) ... ok
testNtoHErrors (test.test_socket.GeneralModuleTests) ... ok
testRefCountGetNameInfo (test.test_socket.GeneralModuleTests) ... ok
testSendAfterClose (test.test_socket.GeneralModuleTests) ... ok
testSendtoErrors (test.test_socket.GeneralModuleTests) ... ok
testSetSockOpt (test.test_socket.GeneralModuleTests) ... ok
testSockName (test.test_socket.GeneralModuleTests) ... ok
testSocketError (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv4 (test.test_socket.GeneralModuleTests) ... ok
testStringToIPv6 (test.test_socket.GeneralModuleTests) ... ok
test_flowinfo (test.test_socket.GeneralModuleTests) ... ok
test_getsockaddrarg (test.test_socket.GeneralModuleTests) ... ok
test_sendall_interrupted (test.test_socket.GeneralModuleTests) ... skipped 'signal.alarm and socket.socketpair required for this test'
test_sendall_interrupted_with_timeout (test.test_socket.GeneralModuleTests) ... skipped 'signal.alarm and socket.socketpair required for this test'
test_sock_ioctl (test.test_socket.GeneralModuleTests) ... skipped 'Windows specific'
test_weakref (test.test_socket.GeneralModuleTests) ... ok
testDup (test.test_socket.BasicTCPTest) ... ok
testFromFd (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecv (test.test_socket.BasicTCPTest) ... ok
testOverFlowRecvFrom (test.test_socket.BasicTCPTest) ... ok
testRecv (test.test_socket.BasicTCPTest) ... ok
testRecvFrom (test.test_socket.BasicTCPTest) ... ok
testSendAll (test.test_socket.BasicTCPTest) ... ok
testShutdown (test.test_socket.BasicTCPTest) ... ok
testClose (test.test_socket.TCPCloserTest) ... ok
testInterruptedTimeout (test.test_socket.TCPTimeoutTest) ... ok
testTCPTimeout (test.test_socket.TCPTimeoutTest) ... ok
testTimeoutZero (test.test_socket.TCPTimeoutTest) ... ok
testExceptionTree (test.test_socket.TestExceptions) ... ok
testRecvFromIntoArray (test.test_socket.BufferIOTest) ... ok
testRecvFromIntoBytearray (test.test_socket.BufferIOTest) ... ok
testRecvFromIntoMemoryview (test.test_socket.BufferIOTest) ... ok
testRecvIntoArray (test.test_socket.BufferIOTest) ... ok
testRecvIntoBytearray (test.test_socket.BufferIOTest) ... ok
testRecvIntoMemoryview (test.test_socket.BufferIOTest) ... ok
testDup (test.test_socket.BasicTCPTest2) ... ok
testFromFd (test.test_socket.BasicTCPTest2) ... ok
testOverFlowRecv (test.test_socket.BasicTCPTest2) ... ok
testOverFlowRecvFrom (test.test_socket.BasicTCPTest2) ... ok
testRecv (test.test_socket.BasicTCPTest2) ... ok
testRecvFrom (test.test_socket.BasicTCPTest2) ... ok
testSendAll (test.test_socket.BasicTCPTest2) ... ok
testShutdown (test.test_socket.BasicTCPTest2) ... ok
testRecvFrom (test.test_socket.BasicUDPTest) ... ok
testRecvFromNegative (test.test_socket.BasicUDPTest) ... ok
testSendtoAndRecv (test.test_socket.BasicUDPTest) ... ok
testTimeoutZero (test.test_socket.UDPTimeoutTest) ... ok
testUDPTimeout (test.test_socket.UDPTimeoutTest) ... ok
testAccept (test.test_socket.NonBlockingTCPTests) ... ok
testConnect (test.test_socket.NonBlockingTCPTests) ... ok
testRecv (test.test_socket.NonBlockingTCPTests) ... ok
testSetBlocking (test.test_socket.NonBlockingTCPTests) ... ok
testClosedAttr (test.test_socket.FileObjectClassTestCase) ... ok
testFullRead (test.test_socket.FileObjectClassTestCase) ... ok
testReadline (test.test_socket.FileObjectClassTestCase) ... ok
testReadlineAfterRead (test.test_socket.FileObjectClassTestCase) ... ok
testReadlineAfterReadNoNewline (test.test_socket.FileObjectClassTestCase) ... ok
testSmallRead (test.test_socket.FileObjectClassTestCase) ... ok
testUnbufferedRead (test.test_socket.FileObjectClassTestCase) ... ok
test_default (test.test_socket.FileObjectInterruptedTestCase) ... ok
test_no_buffer (test.test_socket.FileObjectInterruptedTestCase) ... ok
test_with_1k_buffer (test.test_socket.FileObjectInterruptedTestCase) ... ok
testClosedAttr (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testFullRead (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testReadline (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testReadlineAfterRead (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testReadlineAfterReadNoNewline (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testSmallRead (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedRead (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testUnbufferedReadline (test.test_socket.UnbufferedFileObjectClassTestCase) ... ok
testClosedAttr (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testFullRead (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testReadline (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testReadlineAfterRead (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testReadlineAfterReadNoNewline (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testSmallRead (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead (test.test_socket.LineBufferedFileObjectClassTestCase) ... ok
testClosedAttr (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testFullRead (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testReadline (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testReadlineAfterRead (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testReadlineAfterReadNoNewline (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testSmallRead (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testUnbufferedRead (test.test_socket.SmallBufferedFileObjectClassTestCase) ... ok
testClose (test.test_socket.Urllib2FileobjectTest) ... ok
test_connect (test.test_socket.NetworkConnectionNoServer) ... ok
test_create_connection (test.test_socket.NetworkConnectionNoServer) ... ok
test_create_connection_timeout (test.test_socket.NetworkConnectionNoServer) ... ok
testFamily (test.test_socket.NetworkConnectionAttributesTest) ... ok
testSourceAddress (test.test_socket.NetworkConnectionAttributesTest) ... ok
testTimeoutDefault (test.test_socket.NetworkConnectionAttributesTest) ... ok
testTimeoutNone (test.test_socket.NetworkConnectionAttributesTest) ... ok
testTimeoutValueNamed (test.test_socket.NetworkConnectionAttributesTest) ... ok
testTimeoutValueNonamed (test.test_socket.NetworkConnectionAttributesTest) ... ok
testInsideTimeout (test.test_socket.NetworkConnectionBehaviourTest) ... ok
testOutsideTimeout (test.test_socket.NetworkConnectionBehaviourTest) ... ok
testRecv (test.test_socket.BasicSocketPairTest) ... ok
testSend (test.test_socket.BasicSocketPairTest) ... ok
testLinuxAbstractNamespace (test.test_socket.TestLinuxAbstractNamespace) ... ok
testMaxName (test.test_socket.TestLinuxAbstractNamespace) ... ok
testNameOverflow (test.test_socket.TestLinuxAbstractNamespace) ... ok

----------------------------------------------------------------------
Ran 113 tests in 9.957s

OK (skipped=3)
1 test OK.

----------

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

From report at bugs.python.org  Mon Feb  4 19:28:33 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Feb 2013 18:28:33 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1359995486.55.0.675667544046.issue12502@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0=hqA_7jk_BYz4hNRMQWmK+S=vw4ZRu5tBGFB5AgkFug@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Using handle_accept() in my code and remembering to call listen() in my
> asyncore.dispatcher server's constructor did the trick.
>
> I am not sure if we still have a bug here though, since if the subclass
> doesn't define  a proper handle_accept() we get into the select() loop and
> 100% CPU utilization after the initial client connection.

No, it's not a bug.
The attached test case was for Python 3: Python 2 doesn't have
handle_accepted(), and since the default implementation of
handle_accept() doesn't nothing, the handler is called in a loop,
because the socket is effectively always ready for accept.

----------

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

From report at bugs.python.org  Mon Feb  4 19:28:33 2013
From: report at bugs.python.org (Noah Yetter)
Date: Mon, 04 Feb 2013 18:28:33 +0000
Subject: [issue17127] multiprocessing.dummy.Pool does not accept
	maxtasksperchild argument
Message-ID: <1360002513.52.0.4376358205.issue17127@psf.upfronthosting.co.za>


New submission from Noah Yetter:

Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.

The docs claim that "multiprocessing.dummy replicates the API of multiprocessing but is no more than a wrapper around the threading module." however dummy's Pool method does not replicate the API of multiprocessing's Pool method:

>>> import inspect
>>> import multiprocessing
>>> inspect.getargspec(multiprocessing.Pool)
ArgSpec(args=['processes', 'initializer', 'initargs', 'maxtasksperchild'], varargs=None, keywords=None, defaults=(None, None, (), None))
>>> import multiprocessing.dummy
>>> inspect.getargspec(multiprocessing.dummy.Pool)
ArgSpec(args=['processes', 'initializer', 'initargs'], varargs=None, keywords=None, defaults=(None, None, ()))

Thus when attempting to downshift from multiprocessing to threading like so...

import multiprocessing.dummy as multiprocessing

...code that supplies the maxtasksperchild argument to Pool() will not run.

----------
components: Library (Lib)
messages: 181365
nosy: Noah.Yetter
priority: normal
severity: normal
status: open
title: multiprocessing.dummy.Pool does not accept maxtasksperchild argument
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Feb  4 19:31:20 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Feb 2013 18:31:20 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
Message-ID: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>


New submission from Ned Deily:

Apple has deprecated use of openssl in OS X due to its unstable API between versions:

"If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app"

https://developer.apple.com/library/mac/#documentation/security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html

Currently OS X ships with patched versions of libssl 0.9.7 and 0.9.8.  The 32-bit python.org installer links with and dynamically loads 0.9.7 and the 64-/32-bit installer with 0.9.8.

build-installer.py should be enhanced to build and link with its own universal more up-to-date static libssl, as is done for several other OS X-supplied libraries.  Since apparently the openssl upstream builds do not support OS X universal builds, build-installer.py will need to learn how to build each arch separately and lipo them together.

With the current discussion around security issues, are there features in openssl 1.x.x that warrant making this a release blocker for 2.7.4 and 3.2.4?  I should be able to implement and test this over the next few days if so.

Setting to release blocker for release managers' decision.

----------
assignee: ned.deily
components: Build, Macintosh
messages: 181366
nosy: benjamin.peterson, georg.brandl, larry, ned.deily, ronaldoussoren
priority: release blocker
severity: normal
stage: needs patch
status: open
title: OS X system openssl deprecated - installer should build local libssl
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 19:33:20 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Feb 2013 18:33:20 +0000
Subject: [issue13994] incomplete revert in 2.7 Distutils left two copies of
	customize_compiler
In-Reply-To: <1328978516.66.0.574088250223.issue13994@psf.upfronthosting.co.za>
Message-ID: <1360002800.61.0.324999825224.issue13994@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Thanks for getting this in, Eric !

----------

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

From report at bugs.python.org  Mon Feb  4 19:37:05 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Mon, 04 Feb 2013 18:37:05 +0000
Subject: [issue1326841] SIGALRM alarm signal kills interpreter
Message-ID: <1360003025.82.0.368973225153.issue1326841@psf.upfronthosting.co.za>


ddvento at ucar.edu added the comment:

Paul,
I agree with you, this default behavior is painful. And in fact even the author of the test_socket case for the python regression suite agree with us (maybe even implicitly and by mistake, but regardless...) See Issue17085 for details

----------
nosy: +ddvento at ucar.edu

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

From report at bugs.python.org  Mon Feb  4 19:40:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 18:40:47 +0000
Subject: [issue17126] test_gdb fails
In-Reply-To: <1360000320.96.0.343533657729.issue17126@psf.upfronthosting.co.za>
Message-ID: <1360003247.01.0.361845446972.issue17126@psf.upfronthosting.co.za>


R. David Murray added the comment:

The autoloading error will be fixed in 2.7.4 (due out Real Soon Now, but not immediately).

I've nosied the author, Dave Malcolm, to address the other issues.

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

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

From report at bugs.python.org  Mon Feb  4 19:49:06 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 18:49:06 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360003746.9.0.60833418586.issue17124@psf.upfronthosting.co.za>


Dave Jones added the comment:

I think I found something but I do not know what it means.
Everytime the import hangs, it seems to leave behind a "time.pyc"
There are only 29 files in this directory.

[jonesda0 at linux-2py2 pycode]$ ls -1tr
py5.py*
py4.py*
py3.py*
py2.py*
py1.py*
print_func.py
test.py
ex3-4.py
time.py
time2.py
sample.py
os_test.py
params.py
changeparam.py
parity.py
remove_vowels.py
sqlite_version.py
sqlite_version_with.py
sqlite_insert.py
sqlite_insert2.py
sqlite_friends_last.py
sqlite_getall.py
dc4g2-report.rpt
out_dc4g2-report.rpt
num_guess.py
report_db_import.py*
test-sp.py
sp.py
test/
[jonesda0 at linux-2py2 pycode]$ python sp.py 
100000000
Done.......
[jonesda0 at linux-2py2 pycode]$ ls -1tr
py5.py*
py4.py*
py3.py*
py2.py*
py1.py*
print_func.py
test.py
ex3-4.py
time.py
time2.py
sample.py
os_test.py
params.py
changeparam.py
parity.py
remove_vowels.py
sqlite_version.py
sqlite_version_with.py
sqlite_insert.py
sqlite_insert2.py
sqlite_friends_last.py
sqlite_getall.py
dc4g2-report.rpt
out_dc4g2-report.rpt
num_guess.py
report_db_import.py*
test-sp.py
sp.py
test/
time.pyc <<<<<<<<<<<<<<<

----------

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

From report at bugs.python.org  Mon Feb  4 18:52:01 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Mon, 04 Feb 2013 17:52:01 +0000
Subject: [issue17126] test_gdb fails
Message-ID: <1360000320.96.0.343533657729.issue17126@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

Using older versions of gdb failed with the "Unhandled dwarf expression opcode 0xf3" error. Therefore, I am running the latest and greatest gdb v7.5. The first problem is that the tests fail with a:

warning: File "such-and-such" auto-loading has been declined by your `auto-load safe-path\' set to "$debugdir:$datadir/auto-load

Which can be fixed with the creation of the file ~/.gdbinit containing the following line:
set auto-load safe-path / 

After that, many tests are still failing, with more test-dependant issues. To me, at least some these tests seems just making weird assumptions of what the output of gdb should be. See for example test_truncation.



./python Lib/test/regrtest.py -v test_gdb
== CPython 2.7.3 (default, Feb 2 2013, 11:27:13) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/build/test_python_20889
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_gdb
test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled ... FAIL
test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully ... FAIL
test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully ... FAIL
test_builtin_function (test.test_gdb.PrettyPrintTests) ... FAIL
test_builtin_method (test.test_gdb.PrettyPrintTests) ... FAIL
test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled ... FAIL
test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances ... FAIL
test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully ... FAIL
test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled ... FAIL
test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled ... FAIL
test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries ... FAIL
test_exceptions (test.test_gdb.PrettyPrintTests) ... FAIL
test_frames (test.test_gdb.PrettyPrintTests) ... ok
test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets ... FAIL
test_getting_backtrace (test.test_gdb.PrettyPrintTests) ... ok
test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values ... FAIL
test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists ... FAIL
test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values ... FAIL
test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances ... FAIL
test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval ... FAIL
test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval ... FAIL
test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL
test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests) ... FAIL
test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets ... FAIL
test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None ... FAIL
test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings ... FAIL
test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass ... FAIL
test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass ... FAIL
test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated ... FAIL
test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples ... FAIL
test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values ... FAIL
test_basic_command (test.test_gdb.PyListTests)
Verify that the "py-list" command works ... skipped 'Python was compiled with optimizations'
test_one_abs_arg (test.test_gdb.PyListTests)
Verify the "py-list" command with one absolute argument ... skipped 'Python was compiled with optimizations'
test_two_abs_args (test.test_gdb.PyListTests)
Verify the "py-list" command with two absolute arguments ... skipped 'Python was compiled with optimizations'
test_down_at_bottom (test.test_gdb.StackNavigationTests)
Verify handling of "py-down" at the bottom of the stack ... ok
test_pyup_command (test.test_gdb.StackNavigationTests)
Verify that the "py-up" command works ... skipped 'Python was compiled with optimizations'
test_up_at_top (test.test_gdb.StackNavigationTests)
Verify handling of "py-up" at the top of the stack ... ok
test_up_then_down (test.test_gdb.StackNavigationTests)
Verify "py-up" followed by "py-down" ... skipped 'Python was compiled with optimizations'
test_basic_command (test.test_gdb.PyBtTests)
Verify that the "py-bt" command works ... skipped 'Python was compiled with optimizations'
test_basic_command (test.test_gdb.PyPrintTests)
Verify that the "py-print" command works ... skipped 'Python was compiled with optimizations'
test_print_after_up (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations'
test_printing_builtin (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations'
test_printing_global (test.test_gdb.PyPrintTests) ... skipped 'Python was compiled with optimizations'
test_basic_command (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations'
test_locals_after_up (test.test_gdb.PyLocalsTests) ... skipped 'Python was compiled with optimizations'

======================================================================
FAIL: test_NULL_instance_dict (test.test_gdb.PrettyPrintTests)
Ensure that a PyInstanceObject with with a NULL in_dict is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 446, in test_NULL_instance_dict
    exptype='Foo')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo at remote 0x2aaaaaf04560>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<Foo(an_int=42) at remote 0x2aaaaaf04560>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<Foo at remote 0x2aaaaaf04560>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<Foo at remote 0x2aaaaaf04560>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo at remote 0x2aaaaaf04560>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x66a5a0, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x610410, flags=<optimized out>, locals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, globals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", start=start at entry=257, globals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals={'foo': <Foo at remote 0x2aaaaaf04560>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_int = 42\nprint foo\n", flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 417, in test_NULL_ob_type
    'set op->ob_type=0')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<unknown at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<unknown at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_NULL_ptr (test.test_gdb.PrettyPrintTests)
Ensure that a NULL PyObject* is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 412, in test_NULL_ptr
    self.assertEqual(gdb_repr, '0x0')
AssertionError: '0x0, op at entry=42' != '0x0'

======================================================================
FAIL: test_builtin_function (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 549, in test_builtin_function
    self.assertEqual(gdb_repr, '<built-in function len>')
AssertionError: 'op at entry=<built-in function len>' != '<built-in function len>'

======================================================================
FAIL: test_builtin_method (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 556, in test_builtin_method
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<built-in method readlines of file object at remote 0x2aaaaaeba1e0>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a40, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103f0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "import sys; print sys.stdout.readlines\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', 'sys': <module at remote 0x2aaaaaea2b78>, '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcac0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "import sys; print sys.stdout.readlines\n", flags=flags at entry=0x7fffffffcac0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_builtins_help (test.test_gdb.PrettyPrintTests)
Ensure that the new-style class _Helper in site.py can be handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 456, in test_builtins_help
    msg='Unexpected rendering %r' % gdb_repr)
AssertionError: Unexpected rendering 'op at entry=<_Helper at remote 0x2aaaab3ae350>'

======================================================================
FAIL: test_classic_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of classic class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 330, in test_classic_class
    msg='Unexpected classic-class rendering %r' % gdb_repr)
AssertionError: Unexpected classic-class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaf04560>'

======================================================================
FAIL: test_corrupt_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a corrupt ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 423, in test_corrupt_ob_type
    expvalue=42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<unknown at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<unknown at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_flags is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 429, in test_corrupt_tp_flags
    expvalue=42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<int at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<int at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<int at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<int at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with a type with corrupt tp_name is handled
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 435, in test_corrupt_tp_name
    expvalue=42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 402, in assertSane
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<unknown at remote 0x61dbc8>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<unknown at remote 0x61dbc8>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<unknown at remote 0x61dbc8>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<unknown at remote 0x61dbc8>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_dicts (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of dictionaries
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 221, in test_dicts
    self.assertGdbRepr({})
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry={}, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry={}, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op={}) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry={}, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print {}\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print {}\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_exceptions (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 307, in test_exceptions
    "exceptions.RuntimeError('I am an error',)")
AssertionError: "op at entry=exceptions.RuntimeError('I am an error',)" != "exceptions.RuntimeError('I am an error',)"

======================================================================
FAIL: test_frozensets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of frozensets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 288, in test_frozensets
    self.assertGdbRepr(frozenset())
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=frozenset([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=frozenset([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=frozenset([])) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=frozenset([]), f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print frozenset([])\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcad0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print frozenset([])\n", flags=flags at entry=0x7fffffffcad0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_int (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "int" values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 200, in test_int
    self.assertGdbRepr(42)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=42, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=42) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=42, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 42\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 42\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of lists
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 227, in test_lists
    self.assertGdbRepr([])
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=[], fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=[], fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=[]) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=[], f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print []\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print []\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_long (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of various "long" values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 208, in test_long
    self.assertGdbRepr(0L)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=0L, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=0L, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=0L) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=0L, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print 0L\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print 0L\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_modern_class (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of new-style class instances
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 342, in test_modern_class
    msg='Unexpected new-style class rendering %r' % gdb_repr)
AssertionError: Unexpected new-style class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaee5150>'

======================================================================
FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a dict doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 477, in test_selfreferential_dict
    self.assertEqual(gdb_repr, "{'foo': {'bar': {...}}}")
AssertionError: "op at entry={'foo': {'bar': {...}}}" != "{'foo': {'bar': {...}}}"

======================================================================
FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests)
Ensure that a reference loop involving a list doesn't lead proxyval
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 464, in test_selfreferential_list
    self.assertEqual(gdb_repr, '[3, 4, 5, [...]]')
AssertionError: 'op at entry=[3, 4, 5, [...]]' != '[3, 4, 5, [...]]'

======================================================================
FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 503, in test_selfreferential_new_style_instance
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x66a5a0, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x610410, flags=<optimized out>, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "\nclass Foo(object):\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", start=start at entry=257, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaee5150>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <type at remote 0x66a910>, '__doc__': None}, flags=flags at entry=0x7fffffffcaa0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "\nclass Foo(object):\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffcaa0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 490, in test_selfreferential_old_style_instance
    (gdb_repr, gdb_output))
AssertionError: Unexpected gdb representation: 'op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>'
Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=<Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x66a5a0, for file <string>, line 6, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb3bb0, globals=globals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals=locals at entry={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x610410, flags=<optimized out>, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", start=start at entry=257, globals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, locals={'foo': <Foo(an_attr=<...>) at remote 0x2aaaaaf04518>, '__builtins__': <module at remote 0x2aaaaaea2ad0>, '__package__': None, '__name__': '__main__', 'Foo': <classobj at remote 0x2aaaaaedaf58>, '__doc__': None}, flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "\nclass Foo:\n    pass\nfoo = Foo()\nfoo.an_attr = foo\nprint foo\n", flags=flags at entry=0x7fffffffcab0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of sets
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 269, in test_sets
    self.assertGdbRepr(set())
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=set([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=set([]), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=set([])) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=set([]), f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print set([])\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print set([])\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_singletons (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of True, False and None
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 215, in test_singletons
    self.assertGdbRepr(True)
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=True, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=True, fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=True) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=True, f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print True\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print True\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of strings
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 232, in test_strings
    self.assertGdbRepr('')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry='', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry='', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op='') at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry='', f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print ''\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print ''\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a list subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 355, in test_subclassing_list
    msg='Unexpected new-style class rendering %r' % gdb_repr)
AssertionError: Unexpected new-style class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaef56d8>'

======================================================================
FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of an instance of a tuple subclass
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 369, in test_subclassing_tuple
    msg='Unexpected new-style class rendering %r' % gdb_repr)
AssertionError: Unexpected new-style class rendering 'op at entry=<Foo(an_int=42) at remote 0x2aaaaaef2530>'

======================================================================
FAIL: test_truncation (test.test_gdb.PrettyPrintTests)
Verify that very long output is truncated
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 523, in test_truncation
    "[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, "
AssertionError: 'op at entry=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)' != '[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226...(truncated)'

======================================================================
FAIL: test_tuples (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of tuples
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 239, in test_tuples
    self.assertGdbRepr(tuple())
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=(), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=(), fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=()) at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=(), f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print ()\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print ()\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


======================================================================
FAIL: test_unicode (test.test_gdb.PrettyPrintTests)
Verify the pretty-printing of unicode values
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 246, in test_unicode
    self.assertGdbRepr(u'')
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere-gdb-without-tipc/Lib/test/test_gdb.py", line 196, in assertGdbRepr
    self.assertEqual(gdb_repr, repr(val), gdb_output)
AssertionError: Breakpoint 1 (PyObject_Print) pending.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, PyObject_Print (op=op at entry=u'', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
330         return internal_print(op, fp, flags, 0);
#0  PyObject_Print (op=op at entry=u'', fp=0x32c879b780 <_IO_2_1_stdout_>, flags=flags at entry=1) at Objects/object.c:330
#1  0x00002aaaaab1cfb8 in file_PyObject_Print (flags=1, f=0x2aaaaaeba1e0, op=u'') at Objects/fileobject.c:110
#2  PyFile_WriteObject (v=v at entry=u'', f=f at entry=<file at remote 0x2aaaaaeba1e0>, flags=flags at entry=1) at Objects/fileobject.c:2507
#3  0x00002aaaaab9ea57 in PyEval_EvalFrameEx (f=f at entry=Frame 0x669a30, for file <string>, line 1, in <module> (), throwflag=throwflag at entry=0) at Python/ceval.c:1770
#4  0x00002aaaaaba1c18 in PyEval_EvalCodeEx (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253
#5  0x00002aaaaaba1d52 in PyEval_EvalCode (co=co at entry=0x2aaaaaeb36b0, globals=globals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals=locals at entry={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}) at Python/ceval.c:667
#6  0x00002aaaaabc31ed in run_mod (arena=0x6103e0, flags=<optimized out>, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, filename=0x2aaaaabf175d "<string>", mod=<optimized out>) at Python/pythonrun.c:1353
#7  PyRun_StringFlags (str=str at entry=0x601010 "print u''\n", start=start at entry=257, globals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, locals={'__builtins__': <module at remote 0x2aaaaaea2ad0>, '__name__': '__main__', '__doc__': None, '__package__': None}, flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:1316
#8  0x00002aaaaabc3d5b in PyRun_SimpleStringFlags (command=command at entry=0x601010 "print u''\n", flags=flags at entry=0x7fffffffcae0) at Python/pythonrun.c:969
#9  0x00002aaaaabd90c8 in Py_Main (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:583
#10 0x00000032c841ecdd in __libc_start_main () from /lib64/libc.so.6
#11 0x0000000000400789 in _start ()


----------------------------------------------------------------------
Ran 45 tests in 5.770s

FAILED (failures=29, skipped=12)
test test_gdb failed -- multiple errors occurred
1 test failed:
    test_gdb

----------
components: Tests
messages: 181358
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: test_gdb fails
versions: Python 2.7

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

From report at bugs.python.org  Mon Feb  4 19:55:36 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 18:55:36 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360004136.39.0.676740346306.issue17124@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

Could you give us the contents of your time.py file? I wonder if there's something in that file that is causing the import to hang. It's the only reason I can think of as to why the time.pyc file shows up.

Also, if you want to check before-hand, make a new directory with just those two files and see what happens.

----------
nosy: +icordasc

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

From report at bugs.python.org  Mon Feb  4 19:57:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 18:57:37 +0000
Subject: [issue17123] Add OCSP support to ssl module
In-Reply-To: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>
Message-ID: <1360004257.07.0.238549839911.issue17123@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Christian, I really don't agree this should be a release blocker, and especially not for bugfix branches.

----------
priority: release blocker -> normal

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

From report at bugs.python.org  Mon Feb  4 19:57:57 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 18:57:57 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360004277.69.0.940438258478.issue17124@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

As a further note, on python 2.6, I just touched a file called time.py, and in the interpreter imported subprocess. It didn't hang because the file was empty but it did generate a pyc file. This is almost certainly the root of your problem. I doubt this is a core python problem.

----------

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

From report at bugs.python.org  Mon Feb  4 19:59:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 18:59:33 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360004373.1.0.416061939469.issue17121@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Wow. Can we calm down? Setting many feature requests as release blockers certainly won't magically solve issues.

----------

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

From report at bugs.python.org  Mon Feb  4 20:06:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 19:06:43 +0000
Subject: [issue17107] test_sni in test_urllib2net could be enabled
In-Reply-To: <1359843352.18.0.227762212958.issue17107@psf.upfronthosting.co.za>
Message-ID: <1360004803.41.0.710600910336.issue17107@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the patch :)
Since the test doesn't access a remote host (the version before it was skipped used to), I think it could be moved to test_urllib2_localnet. Also, the transient_internet() shouldn't be necessary.

----------

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

From report at bugs.python.org  Mon Feb  4 20:13:42 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Feb 2013 19:13:42 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1360005222.16.0.730371300074.issue17069@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

?ric, thanks for the comment. URLopener and FancyURLopener is deprecated, so that reference to that can be removed from 3.4 (after removing the URLopener and FancyURLopener class). Rest of the patch can stay the same.

----------

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

From report at bugs.python.org  Mon Feb  4 20:18:25 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 04 Feb 2013 19:18:25 +0000
Subject: [issue10517] test_concurrent_futures crashes with "--with-pydebug" on
	RHEL5 with "Fatal Python error: Invalid thread state for this thread"
In-Reply-To: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>
Message-ID: <1360005505.19.0.544051021889.issue10517@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/issue10517>
_______________________________________

From report at bugs.python.org  Mon Feb  4 20:21:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 19:21:08 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360005668.73.0.569827776353.issue17121@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Benjamin requested that I should set the priority of all tickets to 'release blocker' that needs be be addressed, discussed and possibly fixed for the upcoming releases.

----------

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

From report at bugs.python.org  Mon Feb  4 20:23:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 19:23:50 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360005830.3.0.106010935933.issue17121@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, and why do you think this should be addressed in the next bugfix release? If HTTPS is so broken that you can't upload important data with it, then perhaps patching Python is not the most important thing to do?

In other words: don't you think you're overreacting?

----------

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

From report at bugs.python.org  Mon Feb  4 20:32:33 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 19:32:33 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
Message-ID: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>


New submission from Christian Heimes:

For effective SSL server cert validation a bundle of trustworthy CA certs is required. Most system ship such a bundle but it's not always possible to access the bundle from Python / OpenSSL. Windows and Mac OS X come into my mind. wget and curl ship a copy of Mozilla's CA cert bundle.

The site http://curl.haxx.se/docs/caextract.html explains how to extract the CA certs in PEM format. I suggest that we ship the CA bundle with Python and use a lookup chain:

- user defined path to a cacert directory or cacert.pem file

- cacert directory or PEM file in the user's home directory: 
  cacertdir = os.path.join(site.USER_SITE, os.pardir, "cacert")
  cacertfile = os.path.join(site.USER_SITE, os.pardir, "cacert.pem")

- system's ca cert directory (/etc/ssl/certs on Linux)

- CA cert bundle shipped with the Python installation.

----------
components: Library (Lib)
messages: 181379
nosy: christian.heimes
priority: high
severity: normal
status: open
title: Include CA bundle and provide access to system's CA
type: security
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Feb  4 20:32:58 2013
From: report at bugs.python.org (Benjamin Ash)
Date: Mon, 04 Feb 2013 19:32:58 +0000
Subject: [issue12502] 100% cpu usage when using asyncore with UNIX socket
In-Reply-To: <1309886737.55.0.564500561229.issue12502@psf.upfronthosting.co.za>
Message-ID: <1360006378.46.0.880737137338.issue12502@psf.upfronthosting.co.za>


Benjamin Ash added the comment:

Ok, thanks for quick followup. I didn't realize that the patch for Python-3, sorry about that.

The issue  I had was due to never calling self.listen() in the constructor of my server (asyncore.dispatcher). If this is not done the CPU spikes to 100%.

Thanks again.

----------

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

From report at bugs.python.org  Mon Feb  4 20:33:56 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 19:33:56 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1360006436.54.0.655130989268.issue12226@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
dependencies: +Include CA bundle and provide access to system's CA

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

From report at bugs.python.org  Mon Feb  4 20:34:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2013 19:34:50 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360006490.5.0.933000367032.issue17121@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Perhaps a tiny bit. ;) My brain is in paranoid mode ...

----------

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

From report at bugs.python.org  Mon Feb  4 20:42:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Feb 2013 19:42:07 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360006927.44.0.0751776179324.issue17129@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Shouldn't it be a duplicate of issue13655?

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

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

From report at bugs.python.org  Mon Feb  4 20:46:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Feb 2013 19:46:21 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1360007181.95.0.0630125816848.issue2175@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch, which made xml.sax.xmlreader and related utilities to support character stream. A?lot of new tests added (including Yitz Gale's tests from issue1483). Some old tests fixed (they were used text stream as byte stream, this doesn't work in general case).

----------
components:  -Documentation, Extension Modules
keywords: +patch
nosy: +ezio.melotti
stage:  -> patch review
versions: +Python 3.4
Added file: http://bugs.python.org/file28954/sax_character_stream.patch

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

From report at bugs.python.org  Mon Feb  4 21:00:29 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Feb 2013 20:00:29 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360008029.7.0.949657929977.issue17121@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Too much of a new feature IMO.

----------
priority: release blocker -> normal

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

From report at bugs.python.org  Mon Feb  4 21:25:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 20:25:22 +0000
Subject: [issue16811] email.message.Message flatten dies of list index out of
	range
In-Reply-To: <1356776594.55.0.534961583044.issue16811@psf.upfronthosting.co.za>
Message-ID: <3Z0L5G2Ww2zShr@mail.python.org>


Roundup Robot added the comment:

New changeset e64b74227198 by R David Murray in branch '3.3':
#16811: Fix folding of headers with no value in provisional policies.
http://hg.python.org/cpython/rev/e64b74227198

New changeset fe7f3e2e49ce by R David Murray in branch 'default':
Merge #16811: Fix folding of headers with no value in provisional policies.
http://hg.python.org/cpython/rev/fe7f3e2e49ce

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Feb  4 21:28:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 20:28:05 +0000
Subject: [issue16811] email.message.Message flatten dies of list index out of
	range
In-Reply-To: <1356776594.55.0.534961583044.issue16811@psf.upfronthosting.co.za>
Message-ID: <1360009685.52.0.848124413644.issue16811@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed, thanks.  There are some other issues with folding values consisting of only blanks, but I'll deal with that in the context of other issues.  With this fix the new folding algorithm works at least as well as the old folding algorithm on blank values.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 21:59:47 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 20:59:47 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	700+ files in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360011587.3.0.68784678304.issue17124@psf.upfronthosting.co.za>


Dave Jones added the comment:

Hello Ian.
Thank you for the reply.

As I imagine you understand, I delete the "time.pyc" file every time it comes back.

That being said, there *is* a "time.py" script in there from some testing I was doing:

[jonesda0 at toshiba pycode]$ ls -1tr *.py* | egrep "sp|time"
time.py
time2.py
test-sp.py
sp.py
--------------------------------------------
[jonesda0 at toshiba pycode]$ cat time.py
i = 0
j = 0

while (i < 100000000):
    # i = i + 1
    i+=1
    # j = j + 1
    j+=1

print j

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

[jonesda0 at toshiba pycode]$ python sp.py
100000000
Done.......
[jonesda0 at toshiba pycode]$ ls -1tr *.py* | egrep "sp|time"
time.py
time2.py
test-sp.py
sp.py
time.pyc

------------------------------
I am not calling any sort of "time.py" anywhere:
[jonesda0 at toshiba pycode]$ cat sp.py  ## still took about 25 seconds

import subprocess

print ("Done.......")
------------------------------

So where does this behavior come from?

[jonesda0 at toshiba pycode]$ cat time.pyc  ## There is all sorts of Escape code in the file, obviously.

???Pc@s<dZdZ
x$ed
kr2ed7Ze
d7Z
qWe
GHdS(ii??i
N(t
it
j(((s
/home/jonesda0/pycode/time.py<module>
s


[jonesda0 at toshiba pycode]$ file time.pyc
time.pyc: python 2.7 byte-compiled
[jonesda0 at toshiba pycode]$ 


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

[jonesda0 at toshiba pycode]$ rm -f time.pyc
[jonesda0 at toshiba pycode]$ mv time.py time.py.bad
[jonesda0 at toshiba pycode]$ time python sp.py
Done.......

real	0m0.027s
user	0m0.021s
sys	0m0.005s

[jonesda0 at toshiba pycode]$ ls -1tr *.py* | egrep "sp|time"
time.py.bad
time2.py
test-sp.py
sp.py

--------------------------
Your hypothesis is clearly accurate, but my question is now *WHY*?
I was in no way calling a python time function or time.py, it just happened to be in the directory!

Thanks

----------

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

From report at bugs.python.org  Mon Feb  4 22:01:54 2013
From: report at bugs.python.org (Dave Jones)
Date: Mon, 04 Feb 2013 21:01:54 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	time.py file in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360011714.71.0.463822516716.issue17124@psf.upfronthosting.co.za>


Dave Jones added the comment:

Tried to edit subject to make it easier to search

----------
title: import subprocess hangs for ~25 seconds, 700+ files in dir - py 2.7.3, & 2.6.6 -> import subprocess hangs for ~25 seconds, time.py file in dir - py 2.7.3, & 2.6.6

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

From report at bugs.python.org  Mon Feb  4 22:23:30 2013
From: report at bugs.python.org (Ed Campbell)
Date: Mon, 04 Feb 2013 21:23:30 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360013010.11.0.0798053797079.issue17128@psf.upfronthosting.co.za>


Changes by Ed Campbell <drescampbell at gmail.com>:


----------
nosy: +esc24

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

From report at bugs.python.org  Mon Feb  4 22:27:27 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Feb 2013 21:27:27 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360013247.18.0.421399595789.issue17128@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

As you are the MacOSX expert, I'm going to defer your judgement (and/or Ronald's). I don't think the release will be for several days at least, so you should have time to test.

----------

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

From report at bugs.python.org  Mon Feb  4 22:30:22 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Feb 2013 21:30:22 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360013422.87.0.573872105023.issue17121@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Feb  4 22:36:27 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 04 Feb 2013 21:36:27 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	time.py file in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360013787.32.0.793996734396.issue17124@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

You happen to have a script named time.py, so when the subprocess module is imported, it imports this script instead of the correct time module.
Nothing is wrong, closing.

----------
nosy: +neologix
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  4 22:39:57 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 21:39:57 +0000
Subject: [issue17124] import subprocess hangs for ~25 seconds,
	time.py file in dir - py 2.7.3, & 2.6.6
In-Reply-To: <1359996654.02.0.220330260052.issue17124@psf.upfronthosting.co.za>
Message-ID: <1360013997.0.0.617382867262.issue17124@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

Dave, at some point during the import of subprocess the time module is apparently imported. Because of how imports work, it is importing your local copy instead of the standard library version.

I would wager money that if you ran time python time.py (on your script) it would take roughly 25 seconds. If I run python verbosely and then import subprocess, I get the following output

>>> import subprocess
# /usr/lib64/python2.6/subprocess.pyc matches /usr/lib64/python2.6/subprocess.py
import subprocess # precompiled from /usr/lib64/python2.6/subprocess.pyc
# /usr/lib64/python2.6/traceback.pyc matches /usr/lib64/python2.6/traceback.py
import traceback # precompiled from /usr/lib64/python2.6/traceback.pyc
import gc # builtin
dlopen("/usr/lib64/python2.6/lib-dynload/time.so", 2);
import time # dynamically loaded from /usr/lib64/python2.6/lib-dynload/time.so

That is without the time.py file in the directory. When the file does exist there, I get the following:
>>> import subprocess
# /usr/lib64/python2.6/subprocess.pyc matches /usr/lib64/python2.6/subprocess.py
import subprocess # precompiled from /usr/lib64/python2.6/subprocess.pyc
# /usr/lib64/python2.6/traceback.pyc matches /usr/lib64/python2.6/traceback.py
import traceback # precompiled from /usr/lib64/python2.6/traceback.pyc
import gc # builtin
import time # from time.py
# wrote time.pyc

In short, python checks your current working directory for a file to import. If it finds it, it uses that first. You can examine the order in which python looks for modules and packages by importing sys and looking at sys.path.

This issue can be closed. If you have further questions Dave, feel free to email me personally and I'll do my best to answer them.

----------

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

From report at bugs.python.org  Mon Feb  4 22:46:09 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 04 Feb 2013 21:46:09 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360014369.59.0.968360053393.issue17128@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I'm not sure if it is worthwhile to switch right now.  Apple does deprecate the use of OpenSSL, but there version does offer a feature that's not in the default tree: it verifies SSL certificates against the CA list in the system keychain.   

This means that users that verify certificates (cert_reqs=CERT_REQUIRED in the ssl module) could see a regression when they don't specificy a custom CA list. Not having to maintain such a list manually is very convenient.

In the longer run I'd like to try if it is possible to implement the SSL module (and other extensions linking with openssl) using Apple's crypto APIs.

(Note that a clear disadvantage of the latter is that those APIs are "above" the unix layer and likely cause problems when you use fork(2) without exec(2)).

----------

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

From report at bugs.python.org  Mon Feb  4 23:15:40 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 22:15:40 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360016140.13.0.0904656008939.issue17121@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Feb  4 23:20:25 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 22:20:25 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1360016425.18.0.597431758999.issue12226@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
priority: release blocker -> high

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

From report at bugs.python.org  Mon Feb  4 23:26:31 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 22:26:31 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1360016791.44.0.68791506685.issue16555@psf.upfronthosting.co.za>


?ric Araujo added the comment:

They come from the X.org project.  See comments in http://hg.python.org/cpython/file/default/Lib/locale.py#l601

I had forgotten there was a makelocalealias.py script; maybe we could run it instead of adding an entry manually.

----------

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

From report at bugs.python.org  Mon Feb  4 23:37:39 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Feb 2013 22:37:39 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1360017459.46.0.0451557791319.issue16555@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yes, please. See what makelocalealias.py does.

----------

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

From report at bugs.python.org  Mon Feb  4 23:39:43 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 04 Feb 2013 22:39:43 +0000
Subject: [issue16203] Proposal: add re.fullmatch() method
In-Reply-To: <1349991042.0.0.875123830426.issue16203@psf.upfronthosting.co.za>
Message-ID: <1360017583.0.0.131410300775.issue16203@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I've attached a patch.

----------
Added file: http://bugs.python.org/file28955/issue16203_mrab.patch

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

From report at bugs.python.org  Mon Feb  4 23:45:54 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 04 Feb 2013 22:45:54 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1360016791.44.0.68791506685.issue16555@psf.upfronthosting.co.za>
Message-ID: <51103A21.9050000@egenix.com>


Marc-Andre Lemburg added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo added the comment:
> 
> They come from the X.org project.  See comments in http://hg.python.org/cpython/file/default/Lib/locale.py#l601
> 
> I had forgotten there was a makelocalealias.py script; maybe we could run it instead of adding an entry manually.

Hi Eric,

let me know if you need help with the script.

----------

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

From report at bugs.python.org  Mon Feb  4 23:48:12 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Feb 2013 22:48:12 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360018092.12.0.862922486631.issue17128@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yes, as we've discussed, using the Apple Crypto APIs would be nice longer-term assuming the compatibility issues can be managed: the set of available APIs appear to have been evolving over the past several OS X releases.  But moving away from openssl seems out of scope for maintenance releases.  The reason why I brought this up now is to try to determine if there are any newer ssl features that may be need to be batteries-included to deal with possible changes to Distutils and/or its users (pip, et al).   

Managing the CA certificates certainly is another issue.  We should investigate what Apple and third-party distributors of openssl on OS X do.  It would be best to be able to use the system-supplied ones since they are actively managed by Apple and can be by the user.

Also, it would be good to know how the Python Windows distribution handles openssl and certificates.  Martin?  Brian?

----------
nosy: +brian.curtin, loewis

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

From report at bugs.python.org  Tue Feb  5 01:14:25 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 05 Feb 2013 00:14:25 +0000
Subject: [issue17013] Allow waiting on a mock
In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za>
Message-ID: <1360023265.43.0.369319142513.issue17013@psf.upfronthosting.co.za>


Michael Foord added the comment:

There is a similar feature request on the mock issue tracker: http://code.google.com/p/mock/issues/detail?id=189

I prefer this proposal to the other one though. (Although technically allowing a wait for multiple calls is more flexible.)

----------

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

From report at bugs.python.org  Tue Feb  5 01:17:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Feb 2013 00:17:02 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1360023422.52.0.0483614912038.issue10365@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It seems like a logic error to try to remove something that is not there. But it is not obvious from the traceback that your problem has anything to do with *opening* a file. Unbinding should only happen when *closing* a file. So I suspect this is a different issue.

Please
1. copy and paste the 'sign-in' line that looks like this:
"Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32"
2. add the OS version (like 'Win 7')
3. say *exactly* what you do and what happens when. In particular, do you get the traceback when you close a file? Or only when you actually press the [Open] button.

Try different python files to make sure it is not a problem with the specific file. Does your IDLE otherwise seem to run normally?

----------

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

From report at bugs.python.org  Tue Feb  5 01:25:44 2013
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 05 Feb 2013 00:25:44 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1360023944.7.0.933216809034.issue16555@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The es_CU locale has been added to GNU libc (in version 2.15)[1], but
Tools/i18n/makelocalealias.py script uses the /usr/share/X11/locale/locale.alias file to generate the locale_alias dictionary. I think
/usr/share/X11/locale/locale.alias needs to be updated to recognize
the new GNU libc locales.

See for more information:

* https://bugs.freedesktop.org/show_bug.cgi?id=1544
* http://translate.sourceforge.net/wiki/guide/locales_x11

[1] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=1eb0b490809a681ea801a1cbd93df5b51a4a47e0;hp=c24a9a8aaea37ac630611eb2c75a6517802a1a9d

----------

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

From report at bugs.python.org  Tue Feb  5 01:35:26 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Feb 2013 00:35:26 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za>
Message-ID: <1360024526.8.0.950161668316.issue16137@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Benjamin,

I am assigning this to you because 2.7.4 release is probably the last chance to do something about this behavior in 2.7 series.

I am tentatively resolving this as "won't fix."  In 3.x, we decided that well defined behavior is more important than bug compatibility on broken platforms.  For 2.x, however, the priorities are different.  In this particular case, it is very easy to work around platform bug, but if we add a bound check, we may break code that works.

For example, on a recent Mac OS X release and preloaded Python 2.7, I get:

Python 2.7.2 (default, Jun 20 2012, 16:23:33)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.asctime((2011,1,1,-1,0,0,0,0,0))
'Mon Jan  1 -01:00:00 2011\n'

This behavior is not "obviously wrong."

Please close this or make it a release blocker.  I don't think there is any value in letting this linger past 2.7.4 release.

----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> pending

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

From report at bugs.python.org  Tue Feb  5 01:53:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2013 00:53:23 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360025603.03.0.619121284907.issue6696@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can someone review Thomas's patch?  It's nearly a year old...  I just discovered this same issue.

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Tue Feb  5 01:55:00 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2013 00:55:00 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
Message-ID: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

The profile module exports convenience functions for run() and runctx(), which wrap the corresponding methods of the Profile object.  But perhaps the most useful method, runcall(), is not wrapped. :-(

----------
messages: 181403
nosy: gvanrossum
priority: normal
severity: normal
stage: needs patch
status: open
title: Add runcall() function to profile.py and cProfile.py
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb  5 03:47:26 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 05 Feb 2013 02:47:26 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360032446.38.0.121619133466.issue17121@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/issue17121>
_______________________________________

From report at bugs.python.org  Tue Feb  5 03:51:00 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 02:51:00 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360032660.9.0.818025971936.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I learned a lot of that stuff recently thanks to a tutorial from Greg Ward.  Reviewing the patch now.

----------
stage: needs patch -> patch review
versions: +Python 3.4

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

From report at bugs.python.org  Tue Feb  5 03:53:33 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 05 Feb 2013 02:53:33 +0000
Subject: [issue17121] SSH upload for distutils
In-Reply-To: <1359972222.78.0.301395503133.issue17121@psf.upfronthosting.co.za>
Message-ID: <1360032813.22.0.0138798997958.issue17121@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Python 2.6 can get remote certificate and compute a hash of it, and compare that hash with a known fingerprint. This is what mercurial does.

No proper certificate chain, but secure as far as the PYPI certificate doesn't change.

This would be not a "final" solution, but it is a tiny patch and far safer than current approach.

Then cross fingers for PYPI certificate stability :-).

----------

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

From report at bugs.python.org  Tue Feb  5 04:04:05 2013
From: report at bugs.python.org (Roger Serwy)
Date: Tue, 05 Feb 2013 03:04:05 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1360033445.11.0.785928418653.issue10365@psf.upfronthosting.co.za>


Roger Serwy added the comment:

Patrick, see Issue8900. It described your problem.

----------

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

From report at bugs.python.org  Tue Feb  5 04:06:22 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 03:06:22 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360033582.9.0.329938269362.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Tom, I?m sory your contribution was ignored, and I hope you still get Python bugs email.  The patch is great.  I made comments about contents and form on the code review site; you can follow the ?review? link in the list of files on the top of this page if you didn?t get an email from the review app.

----------

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

From report at bugs.python.org  Tue Feb  5 04:08:41 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 03:08:41 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360033721.91.0.418444046844.issue17128@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Using the CA bundle from the OS sounds great, not only for Macs :)

----------
nosy: +eric.araujo, pitrou

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

From report at bugs.python.org  Tue Feb  5 04:08:54 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 03:08:54 +0000
Subject: [issue16555] Add es_cu to locale aliases
In-Reply-To: <1353900143.47.0.688085135262.issue16555@psf.upfronthosting.co.za>
Message-ID: <1360033734.37.0.378051222489.issue16555@psf.upfronthosting.co.za>


?ric Araujo added the comment:

On Debian testing, I get a few changes that look like fixes but not es_CU yet:

@@ -807,0 +818,1 @@ locale_alias = {
+    'bokm\xef\xbf\xbd':                     'nb_NO.ISO8859-1',
@@ -822,0 +834,1 @@ locale_alias = {
+    'c.ascii':                              'C',
@@ -936,0 +949,3 @@ locale_alias = {
+    'en_dk':                                'en_DK.ISO8859-1',
+    'en_dk.iso88591':                       'en_DK.ISO8859-1',
+    'en_dk.iso885915':                      'en_DK.ISO8859-15',
@@ -976,1 +991,1 @@ locale_alias = {
-    'english.iso88591':                     'en_EN.ISO8859-1',
+    'english.iso88591':                     'en_US.ISO8859-1',
@@ -1114,0 +1130,1 @@ locale_alias = {
+    'fran\xef\xbf\xbdis':                   'fr_FR.ISO8859-1',
@@ -1164,2 +1180,2 @@ locale_alias = {
-    'hebrew':                               'iw_IL.ISO8859-8',
-    'hebrew.iso88598':                      'iw_IL.ISO8859-8',
+    'hebrew':                               'he_IL.ISO8859-8',
+    'hebrew.iso88598':                      'he_IL.ISO8859-8',
@@ -1246,0 +1263,1 @@ locale_alias = {
+    'km':                                   'km_KH.UTF-8',
@@ -1413,1 +1430,1 @@ locale_alias = {
-    'russian':                              'ru_RU.ISO8859-5',
+    'russian':                              'ru_RU.KOI8-R',
@@ -1427,0 +1445,1 @@ locale_alias = {
+    'sid_et':                               'sid_ET.UTF-8',

I could hunt down the very latest upstream X.org locale.alias file and try the script again.  And/or we can do this one addition (es_CU) now, unless there are issues with Python recognizing a locale that the OS doesn?t know about yet.


MAL: the script needed no change at all to find the file and run! :)  We could make it more similar to token/keyword/etc and have it update locale.py in 3.4+.  Also maybe make updating the aliases a part of feature release workflow, or even bugfix releases.

----------

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

From report at bugs.python.org  Tue Feb  5 04:18:03 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Feb 2013 03:18:03 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360034283.38.0.919740200575.issue17128@psf.upfronthosting.co.za>


Ned Deily added the comment:

Somewhat coincidentally, Issue17129 addresses the topic of certificate management across multiple platforms.

----------

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

From report at bugs.python.org  Tue Feb  5 04:24:11 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Feb 2013 03:24:11 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360034651.94.0.532174766457.issue17129@psf.upfronthosting.co.za>


Ned Deily added the comment:

FYI, at the moment, the PSF OS X installers dynamically link with the operating system supplied libssl and use its CA management policies.  Issue17128 proposes changing that because Apple has deprecated the use of the system openssl in OS X.

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

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

From report at bugs.python.org  Tue Feb  5 04:32:02 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 05 Feb 2013 03:32:02 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360035122.29.0.00541647564113.issue17129@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/issue17129>
_______________________________________

From report at bugs.python.org  Tue Feb  5 04:41:03 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Feb 2013 03:41:03 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za>
Message-ID: <1360035663.57.0.294967829844.issue16137@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is long behavior standing, which we can leave in 2.x.

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

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

From report at bugs.python.org  Tue Feb  5 04:49:16 2013
From: report at bugs.python.org (Patrick)
Date: Tue, 05 Feb 2013 03:49:16 +0000
Subject: [issue10365] IDLE Crashes on File Open Dialog when code window closed
	before other file opened
In-Reply-To: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>
Message-ID: <1360036156.07.0.891173448311.issue10365@psf.upfronthosting.co.za>


Patrick added the comment:

Thanks for the pointer to the other issue. It looks spot on.

----------

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

From report at bugs.python.org  Tue Feb  5 04:50:23 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 03:50:23 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1360036223.54.0.794800068099.issue13655@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I propose to change the scope of this request to: ssl module should provide a way to access the OS CA bundle.

----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Tue Feb  5 04:51:17 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 03:51:17 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360036277.01.0.216293797777.issue17129@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Agree this is a duplicate.  I also think it?s a feature request.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Feb  5 04:53:08 2013
From: report at bugs.python.org (Patrick)
Date: Tue, 05 Feb 2013 03:53:08 +0000
Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit
	Window
In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>
Message-ID: <1360036388.06.0.166012493157.issue8900@psf.upfronthosting.co.za>


Patrick added the comment:

I am seeing this as well. It does not repro 100% of the time, but frequently enough that its hard to get anything done. My repro is a little simpler and might help understanding the fix.

Win7
Python 3.3

I start IDLE normally from the shortcut in the install.
Ctrl-N to open and edit window.
Ctrl-O to open a file.
Select file and then Idle exits.

As mentioned, using the menu to open the file seems to work more reliably. I've not had a crash that way.

----------
nosy: +Patrick.Walters

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

From report at bugs.python.org  Tue Feb  5 05:07:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2013 04:07:21 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1360033582.9.0.329938269362.issue6696@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJSfivM0frDpPEVBcpE5utuZ9oDB9SYOCb==wwC5+8XSw@mail.gmail.com>


Guido van Rossum added the comment:

Eric, you could also check it in with your own changes added.

How far can we backport docs?

----------

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

From report at bugs.python.org  Tue Feb  5 05:23:44 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 04:23:44 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360038224.47.0.154634711406.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

2.7 and 3.2.

I?ll wait a few days to let Thomas get the email and reply if he wants.

----------

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

From report at bugs.python.org  Tue Feb  5 06:26:53 2013
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 05 Feb 2013 05:26:53 +0000
Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit
	Window
In-Reply-To: <1360036388.06.0.166012493157.issue8900@psf.upfronthosting.co.za>
Message-ID: <CA+WuaSfKsUGpom9oqHfQF-4EorB7KxgZZ544JZ3vB7sDwmYkkw@mail.gmail.com>


Bruce Sherwood added the comment:

For what it's worth (maybe not much?), the version of IDLE produced by
Guilherme Polo in the 2009 Google Summer of Code, which VPython (vpython.org)
uses under the name VIDLE, does not have any problem with starting with an
edit window and in fact I always use it that way.

Bruce Sherwood

On Mon, Feb 4, 2013 at 8:53 PM, Patrick <report at bugs.python.org> wrote:

>
> Patrick added the comment:
>
> I am seeing this as well. It does not repro 100% of the time, but
> frequently enough that its hard to get anything done. My repro is a little
> simpler and might help understanding the fix.
>
> Win7
> Python 3.3
>
> I start IDLE normally from the shortcut in the install.
> Ctrl-N to open and edit window.
> Ctrl-O to open a file.
> Select file and then Idle exits.
>
> As mentioned, using the menu to open the file seems to work more reliably.
> I've not had a crash that way.
>
> ----------
> nosy: +Patrick.Walters
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue8900>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Feb  5 07:53:50 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Feb 2013 06:53:50 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360047230.46.0.986587995402.issue17128@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Replacing openssl by the supported crypto api's is something for 3.4 or even 3.5.

There is a way to keep the current functionality while still shipping a build of openssl: apply the patch that implements the feature to the upstream version when building it (the patch is available on opensource.apple.com, that's how I know that they do this in the first place).

Something that should be tested before this gets merged: what happens when a user installs pyOpenSSL with python 2.7.3 install (linked to system openssl) and then upgrades to 2.7.4 linked to a custom build of openssl without changing pyOpenSSL.  

I wouldn't expect problems when looking at the documentation (there doesn't seem to be a way to transfer SSL state at the C level), and something similar can already happen: python is linked with a fairly old version of OpenSSL, and you get a later version when linking on a newer OSX release (hence a lot of users that download the binary installer and then install pyOpenSSL already have a version mismatch between the two extensions using openssl).

----------

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

From report at bugs.python.org  Tue Feb  5 07:53:58 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 06:53:58 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360047238.61.0.028581394303.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's an updated patch.  I still have some ref-counting issues, but the patch is much closer to what I expect will be the final version.  At this point it passes all the main unit tests (segfaults in some of the supplemental Mapping tests).

One key thing is that for now the various iterators are faked using lists.  Once everything is sorted out I'll plug my implementation of the iterators back in (which I'd already mostly finished).

I see room for efficiency improvements in a couple spots.  As well, I plan on improving the subclass-ability of the type once it's otherwise happy.

Any feedback at the point would be helpful.  Regardless, I'm being careful to get this right and I'm no expert with the C-API, so it's taking a while.  :)

Some other considerations:

   * ensure that __init__() can reset and populate an existing dictionary:
             d=OrderedDict(); d[0]=1; d.__init__() # resets
   * avoid any reference cycles so that dicts can clean-up right-away when their ref-count drops to zero
     rather than waiting on GC.
   * possibly use the GIL to make the link updates atomic, trying to make the overall class thread safe.
   * methods like get() pop() or setdefault() shouldn't rely on __getitem__ raising KeyError
     because __missing__ may be present in a subclass

----------
Added file: http://bugs.python.org/file28956/odict.diff

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

From report at bugs.python.org  Tue Feb  5 07:54:08 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 06:54:08 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360047248.84.0.187590508354.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file28762/odict.diff

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

From report at bugs.python.org  Tue Feb  5 08:17:14 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 07:17:14 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360048634.08.0.246258537154.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

Looks like I didn't get the patch lined up to tip so the review link isn't showing up.  I'll have to fix that tomorrow.

----------

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

From report at bugs.python.org  Tue Feb  5 08:24:50 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 05 Feb 2013 07:24:50 +0000
Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like
	NFS)
In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za>
Message-ID: <1360049090.21.0.801753198531.issue17076@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
versions: +Python 3.4

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

From report at bugs.python.org  Tue Feb  5 08:26:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 07:26:20 +0000
Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like
	NFS)
In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za>
Message-ID: <3Z0clv48rxzSqw@mail.python.org>


Roundup Robot added the comment:

New changeset 47c65639390d by Hynek Schlawack in branch '3.3':
#17076: Make copying of xattrs more permissive of missing FS support
http://hg.python.org/cpython/rev/47c65639390d

New changeset 7ccdbd1cd213 by Hynek Schlawack in branch 'default':
#17076: Make copying of xattrs more permissive of missing FS support
http://hg.python.org/cpython/rev/7ccdbd1cd213

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  5 09:16:53 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 05 Feb 2013 08:16:53 +0000
Subject: [issue17076] shutil.copytree failing on xattr-less filesystems (like
	NFS)
In-Reply-To: <1359483492.58.0.639649244817.issue17076@psf.upfronthosting.co.za>
Message-ID: <1360052213.78.0.152181021687.issue17076@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

The buildbots look happy, thank you for spotting & the patch Thomas!

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

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

From report at bugs.python.org  Tue Feb  5 10:54:59 2013
From: report at bugs.python.org (S Arrowsmith)
Date: Tue, 05 Feb 2013 09:54:59 +0000
Subject: [issue17131] subprocess.Popen.terminate can raise exception on Posix
Message-ID: <1360058099.4.0.320628892834.issue17131@psf.upfronthosting.co.za>


New submission from S Arrowsmith:

Compare this with the script in #14252:

p = Popen(['/bin/sleep', '1'])
time.sleep(1)
p.terminate()
print p.poll()
p.terminate()

Output is:

0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/subprocess.py", line 1269, in terminate
    self.send_signal(signal.SIGTERM)
  File "/usr/lib/python2.6/subprocess.py", line 1264, in send_signal
    os.kill(self.pid, sig)
OSError: [Errno 3] No such process

The 0 return from poll() indicates that the subprocess ran to completion, rather than being terminated by the first terminate. So the first terminate does nothing, but the second terminate raises an exception. In http://bugs.python.org/issue14252#msg155396 :

"Raising an exception on terminate is a bug."

----------
components: Library (Lib)
messages: 181425
nosy: siona
priority: normal
severity: normal
status: open
title: subprocess.Popen.terminate can raise exception on Posix
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  5 11:13:20 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Feb 2013 10:13:20 +0000
Subject: [issue13829] exception error in _scproxy.so
In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>
Message-ID: <1360059200.56.0.834485515677.issue13829@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I've once again reviewed the _scproxy code and that code seems correct (although that doesn't say too much for subtle bugs because I wrote the initial version of the module).

Dan: is it possible to tell moviegrabber to use another python installation (in particular /Library/Frameworks/Python.framework)? If so, is the problem reproducable with the latest binaries on www.python.org?

The crash report says that the actual crash occurs inside a function called by SCDynamicStoreCopyProxies and I wouldn't know how Python's use of that function is wrong. 

The crash could still be caused by the way the moviegrabber application uses python, but I'd consider that a bug in moviegrabber unless there is a clear indication of a bug in python itself.

BTW. Is Moviegrabber this software? : http://sourceforge.net/projects/moviegrabber/

----------

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

From report at bugs.python.org  Tue Feb  5 11:19:17 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Feb 2013 10:19:17 +0000
Subject: [issue13829] exception error in _scproxy.so
In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>
Message-ID: <1360059557.23.0.541633919459.issue13829@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

If it is the moviegrabber I linked to: that's a 100% python script using some other opensource libraries.

It does use multiprocessing, and that might mean this is the same problem as issue9405. That issue should be fixed in the repository (for a long time, the issue is not yet closed because I wanted to write a test case).

----------

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

From report at bugs.python.org  Tue Feb  5 12:08:41 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Feb 2013 11:08:41 +0000
Subject: [issue15730] Silence unused value warnings under Mac OS X 10.8/clang
In-Reply-To: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za>
Message-ID: <1360062521.91.0.472700130241.issue15730@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

This is an alternate patch, it replaces the PyObject_INIT and PyObject_INIT_VAR macros by inline functions with macro wrappers for compatibility (the macros are used to suppress type warnings).

I don't particularly like my patch, but it might be a better way to ensure that the warning stays away and also fixes the warning in 3th-party code.

BTW. I wouldn't mind feedback of other core developers on either patch.

----------
Added file: http://bugs.python.org/file28957/redefine-init-macros.txt

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

From report at bugs.python.org  Tue Feb  5 12:41:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 11:41:33 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za>
Message-ID: <1360064493.01.0.843791504013.issue16137@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> 'Mon Jan  1 -01:00:00 2011\n'

This is obviously wrong because trailing '\n' was not dropped.

The issue is not about what is more wrong. The issue is about Python crash. At least we should add a warning in the documentation that incorrect data may crash Python on some platforms.

----------

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

From report at bugs.python.org  Tue Feb  5 13:27:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 12:27:05 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za>
Message-ID: <1360067225.55.0.131487026603.issue16137@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A?new patch uses asctime_s() on Windows (this crash was observed only on Windows). This should prevent a crash. In additional it drops '\n' from a result even if the result is longer than usually (this happened on Linux when an invalid time is used).

Please run test_time on Windows.

----------

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

From report at bugs.python.org  Tue Feb  5 13:30:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 12:30:25 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <1349390143.92.0.685174043431.issue16137@psf.upfronthosting.co.za>
Message-ID: <1360067425.28.0.437383688165.issue16137@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file28958/asctime_s.patch

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

From report at bugs.python.org  Tue Feb  5 13:56:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 12:56:18 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <1360068978.95.0.145793644236.issue12983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

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

From report at bugs.python.org  Tue Feb  5 13:57:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 12:57:05 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360069025.08.0.150967112417.issue17128@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Tue Feb  5 14:13:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Feb 2013 13:13:44 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <1360067425.31.0.218637282369.issue16137@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbc54EF9HkyS7eQa6KWDK2csKaTFsHR+2_iKH=qOUnAdQ@mail.gmail.com>


STINNER Victor added the comment:

asctime_s.patch: you should catch ValueError on each call to
self.assertNotIn(). You can use PyString_FromStringAndSize() instead
of writing the NUL character, it may be safer (to not modify the
output of asctime).

2013/2/5 Serhiy Storchaka <report at bugs.python.org>:
>
> Changes by Serhiy Storchaka <storchaka at gmail.com>:
>
>
> Added file: http://bugs.python.org/file28958/asctime_s.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16137>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Feb  5 14:14:10 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 13:14:10 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360070050.84.0.170449906661.issue17128@psf.upfronthosting.co.za>


Christian Heimes added the comment:

On Windows urllib.request.urlopen("http://www.google.com", cadefault=True) fails with "certificate verify failed". (tested with Python 3.3 64bit)

----------

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

From report at bugs.python.org  Tue Feb  5 14:17:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:17:08 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359919302.36.0.56127295617.issue17118@psf.upfronthosting.co.za>
Message-ID: <201302051516.51348.storchaka@gmail.com>


Serhiy Storchaka added the comment:

I missed existing test_tcl. Patches updated, now they add new tests into 
test_tcl.

----------
Added file: http://bugs.python.org/file28959/tkinter_test_passing_values_2.patch
Added file: http://bugs.python.org/file28960/tkinter_test_passing_values-2.7_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17118>
_______________________________________
-------------- next part --------------
diff -r 7ccdbd1cd213 Lib/test/test_tcl.py
--- a/Lib/test/test_tcl.py	Tue Feb 05 08:25:24 2013 +0100
+++ b/Lib/test/test_tcl.py	Tue Feb 05 15:10:21 2013 +0200
@@ -151,6 +151,26 @@
         # exit code must be zero
         self.assertEqual(f.close(), None)
 
+    def test_passing_values(self):
+        def passValue(value):
+            return self.interp.call('set', '_', value)
+
+        self.assertEqual(passValue(True), True)
+        self.assertEqual(passValue(False), False)
+        self.assertEqual(passValue('string'), 'string')
+        self.assertEqual(passValue('string\u20ac'), 'string\u20ac')
+        for i in (0, 1, -1, 2**31-1, -2**31):
+            self.assertEqual(passValue(i), i)
+        for f in (0.0, 1.0, -1.0, 1/3,
+                  sys.float_info.min, sys.float_info.max,
+                  -sys.float_info.min, -sys.float_info.max):
+            self.assertEqual(passValue(f), f)
+        for f in float('nan'), float('inf'), -float('inf'):
+            if f != f: # NaN
+                self.assertNotEqual(passValue(f), f)
+            else:
+                self.assertEqual(passValue(f), f)
+        self.assertEqual(passValue((1, '2', (3.4,))), (1, '2', (3.4,)))
 
 
 def test_main():
diff -r 7ccdbd1cd213 Lib/tkinter/test/test_tkinter/test_nogui.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/tkinter/test/test_tkinter/test_nogui.py	Tue Feb 05 15:10:21 2013 +0200
@@ -0,0 +1,36 @@
+import unittest
+import sys
+import tkinter
+from test import support
+
+class NoguiTest(unittest.TestCase):
+
+    def setUp(self):
+        self.call = tkinter.Tcl().tk.call
+
+    def test_passing_values(self):
+        def passValue(value):
+            return self.call('set', '_', value)
+        #self.assertEqual(passValue(()), True)
+        self.assertEqual(passValue(True), True)
+        self.assertEqual(passValue(False), False)
+        self.assertEqual(passValue('string'), 'string')
+        self.assertEqual(passValue('string\u20ac'), 'string\u20ac')
+        for i in (0, 1, -1, 2**31-1, -2**31):
+            self.assertEqual(passValue(i), i)
+        for f in (0.0, 1.0, -1.0, 1/3,
+                  sys.float_info.min, sys.float_info.max,
+                  -sys.float_info.min, -sys.float_info.max):
+            self.assertEqual(passValue(f), f)
+        for f in float('nan'), float('inf'), -float('inf'):
+            if f != f: # NaN
+                self.assertNotEqual(passValue(f), f)
+            else:
+                self.assertEqual(passValue(f), f)
+        self.assertEqual(passValue((1, '2', (3.4,))), (1, '2', (3.4,)))
+
+
+tests_gui = (NoguiTest,)
+
+if __name__ == "__main__":
+    support.run_unittest(*tests_gui)
-------------- next part --------------
diff -r 20f0c5398e97 Lib/lib-tk/test/test_tkinter/test_nogui.py
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Lib/lib-tk/test/test_tkinter/test_nogui.py	Tue Feb 05 15:14:22 2013 +0200
@@ -0,0 +1,37 @@
+import unittest
+import sys
+import Tkinter as tkinter
+import test.test_support as support
+
+class NoguiTest(unittest.TestCase):
+
+    def setUp(self):
+        self.call = tkinter.Tcl().tk.call
+
+    def test_passing_values(self):
+        def passValue(value):
+            return self.call('set', '_', value)
+        self.assertEqual(passValue(True), True)
+        self.assertEqual(passValue(False), False)
+        self.assertEqual(passValue('string'), 'string')
+        self.assertEqual(passValue('string\u20ac'), 'string\u20ac')
+        self.assertEqual(passValue(u'string'), u'string')
+        self.assertEqual(passValue(u'string\u20ac'), u'string\u20ac')
+        for i in (0, 1, -1, int(2**31-1), int(-2**31)):
+            self.assertEqual(passValue(i), i)
+        for f in (0.0, 1.0, -1.0, 1/3,
+                  sys.float_info.min, sys.float_info.max,
+                  -sys.float_info.min, -sys.float_info.max):
+            self.assertEqual(passValue(f), f)
+        for f in float('nan'), float('inf'), -float('inf'):
+            if f != f: # NaN
+                self.assertNotEqual(passValue(f), f)
+            else:
+                self.assertEqual(passValue(f), f)
+        self.assertEqual(passValue((1, '2', (3.4,))), (1, '2', (3.4,)))
+
+
+tests_gui = (NoguiTest,)
+
+if __name__ == "__main__":
+    support.run_unittest(*tests_gui)
diff -r 20f0c5398e97 Lib/test/test_tcl.py
--- a/Lib/test/test_tcl.py	Mon Feb 04 10:29:38 2013 -0500
+++ b/Lib/test/test_tcl.py	Tue Feb 05 15:14:22 2013 +0200
@@ -1,6 +1,7 @@
 #!/usr/bin/env python
 
 import unittest
+import sys
 import os
 from test import test_support
 
@@ -151,6 +152,27 @@
         # exit code must be zero
         self.assertEqual(f.close(), None)
 
+    def test_passing_values(self):
+        def passValue(value):
+            return self.interp.call('set', '_', value)
+        self.assertEqual(passValue(True), True)
+        self.assertEqual(passValue(False), False)
+        self.assertEqual(passValue('string'), 'string')
+        self.assertEqual(passValue('string\u20ac'), 'string\u20ac')
+        self.assertEqual(passValue(u'string'), u'string')
+        self.assertEqual(passValue(u'string\u20ac'), u'string\u20ac')
+        for i in (0, 1, -1, int(2**31-1), int(-2**31)):
+            self.assertEqual(passValue(i), i)
+        for f in (0.0, 1.0, -1.0, 1/3,
+                  sys.float_info.min, sys.float_info.max,
+                  -sys.float_info.min, -sys.float_info.max):
+            self.assertEqual(passValue(f), f)
+        for f in float('nan'), float('inf'), -float('inf'):
+            if f != f: # NaN
+                self.assertNotEqual(passValue(f), f)
+            else:
+                self.assertEqual(passValue(f), f)
+        self.assertEqual(passValue((1, '2', (3.4,))), (1, '2', (3.4,)))
 
 
 def test_main():

From report at bugs.python.org  Tue Feb  5 14:18:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:18:02 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360070282.76.0.42625264632.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28946/tkinter_test_passing_values.patch

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

From report at bugs.python.org  Tue Feb  5 14:18:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:18:14 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360070294.65.0.639466443056.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28946/tkinter_test_passing_values.patch

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

From report at bugs.python.org  Tue Feb  5 14:18:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:18:30 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360070310.82.0.87432704122.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28947/tkinter_test_passing_values-2.7.patch

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

From report at bugs.python.org  Tue Feb  5 14:18:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:18:45 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360070325.17.0.490146555442.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28959/tkinter_test_passing_values_2.patch

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

From report at bugs.python.org  Tue Feb  5 14:19:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:19:12 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360070352.89.0.469864765662.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28960/tkinter_test_passing_values-2.7_2.patch

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

From report at bugs.python.org  Tue Feb  5 14:19:57 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 05 Feb 2013 13:19:57 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360070397.22.0.919368456631.issue17128@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

It doesn't raise an exception on OSX (close to the tip of the default branch), both for http://www.google.com/ and https://www.google.com/

----------

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

From report at bugs.python.org  Tue Feb  5 14:20:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 13:20:44 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360070444.84.0.890039766561.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file28961/tkinter_test_passing_values_2.patch
Added file: http://bugs.python.org/file28962/tkinter_test_passing_values-2.7_2.patch

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

From report at bugs.python.org  Tue Feb  5 14:38:36 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Tue, 05 Feb 2013 13:38:36 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360071516.23.0.729339029341.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Thanks for the feedback!

I'll incorporate it this weekend and make a new patch, though also feel free to just go ahead and make the changes yourself if you'd rather not wait for me.

----------

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

From report at bugs.python.org  Tue Feb  5 15:07:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 14:07:29 +0000
Subject: [issue17043] Invalid read in test_codecs
In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za>
Message-ID: <1360073249.88.0.847865887855.issue17043@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

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

From report at bugs.python.org  Tue Feb  5 15:12:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 14:12:57 +0000
Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates
	prematurely
In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za>
Message-ID: <1360073577.54.0.815850278597.issue16723@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Senthil, Antoine, anyone, what you think about this patch?

----------

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

From report at bugs.python.org  Tue Feb  5 15:33:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 14:33:29 +0000
Subject: [issue16137] Using time.asctime() with an array with negative tm_hour
	causes Python Crash.
In-Reply-To: <CAMpsgwbc54EF9HkyS7eQa6KWDK2csKaTFsHR+2_iKH=qOUnAdQ@mail.gmail.com>
Message-ID: <201302051633.13001.storchaka@gmail.com>


Serhiy Storchaka added the comment:

Thank you for comments, Victor. Here is an updated patch.

----------
Added file: http://bugs.python.org/file28963/asctime_s_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16137>
_______________________________________
-------------- next part --------------
diff -r 20f0c5398e97 Lib/test/test_time.py
--- a/Lib/test/test_time.py	Mon Feb 04 10:29:38 2013 -0500
+++ b/Lib/test/test_time.py	Tue Feb 05 16:04:32 2013 +0200
@@ -128,10 +128,15 @@
         # self.assertRaises(ValueError, time.asctime,
         #                  (12345, 1, 0, 0, 0, 0, 0, 0, 0))
         # XXX: For now, just make sure we don't have a crash:
-        try:
-            time.asctime((12345, 1, 1, 0, 0, 0, 0, 1, 0))
-        except ValueError:
-            pass
+        def check(tm):
+            try:
+                self.assertNotIn('\n', time.asctime(tm))
+            except ValueError:
+                pass
+        check((12345, 1, 1, 0, 0, 0, 0, 1, 0))
+        # Issue #16137
+        check((2013, 2, 5, -1, 0, 0, 0, 0, 0))
+        check((2013, 2, 5, 101, 0, 0, 0, 0, 0))
 
     @unittest.skipIf(not hasattr(time, "tzset"),
         "time module has no attribute tzset")
diff -r 20f0c5398e97 Misc/NEWS
--- a/Misc/NEWS	Mon Feb 04 10:29:38 2013 -0500
+++ b/Misc/NEWS	Tue Feb 05 16:04:32 2013 +0200
@@ -199,6 +199,10 @@
 Library
 -------
 
+- Issue #16137: Fix a segmentation fault when time.asctime() called with an
+  illegal time (i.e. with a negative hour) on Windows.  On other platforms a
+  result of such call no more contains a trailing '\n'.
+
 - Issue #6083: Fix multiple segmentation faults occured when PyArg_ParseTuple
   parses nested mutating sequence.
 
diff -r 20f0c5398e97 Modules/timemodule.c
--- a/Modules/timemodule.c	Mon Feb 04 10:29:38 2013 -0500
+++ b/Modules/timemodule.c	Tue Feb 05 16:04:32 2013 +0200
@@ -563,7 +563,10 @@
 {
     PyObject *tup = NULL;
     struct tm buf;
-    char *p;
+    char *p, *q;
+#ifdef MS_WINDOWS
+    char sbuf[100];
+#endif
     if (!PyArg_UnpackTuple(args, "asctime", 0, 1, &tup))
         return NULL;
     if (tup == NULL) {
@@ -571,14 +574,24 @@
         buf = *localtime(&tt);
     } else if (!gettmarg(tup, &buf))
         return NULL;
+#ifdef MS_WINDOWS
+    if (asctime_s(sbuf, sizeof(sbuf) - 1, &buf) != 0)
+        p = NULL;
+    else {
+        p = sbuf;
+        sbuf[sizeof(sbuf) - 1] = '\0';
+    }
+#else
     p = asctime(&buf);
+#endif
     if (p == NULL) {
         PyErr_SetString(PyExc_ValueError, "invalid time");
         return NULL;
     }
-    if (p[24] == '\n')
-        p[24] = '\0';
-    return PyString_FromString(p);
+    q = strchr(p, '\n');
+    if (q == NULL)
+        q = strchr(p, '\0'); /* end of string */
+    return PyString_FromStringAndSize(p, q - p);
 }
 
 PyDoc_STRVAR(asctime_doc,

From report at bugs.python.org  Tue Feb  5 15:38:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 14:38:55 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1360075135.54.0.351225883293.issue10557@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Tue Feb  5 16:08:33 2013
From: report at bugs.python.org (Josh Lee)
Date: Tue, 05 Feb 2013 15:08:33 +0000
Subject: [issue17132] yield_arg missing from symbol.sym_name
Message-ID: <1360076913.18.0.0139666205615.issue17132@psf.upfronthosting.co.za>


New submission from Josh Lee:

>>> symbol.sym_name[337]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 337

It should be 'yield_arg'.

----------
components: Library (Lib)
messages: 181440
nosy: Josh.Lee
priority: normal
severity: normal
status: open
title: yield_arg missing from symbol.sym_name
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  5 16:11:49 2013
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Tue, 05 Feb 2013 15:11:49 +0000
Subject: [issue14910] argparse: disable abbreviation
In-Reply-To: <1337943742.57.0.897347214609.issue14910@psf.upfronthosting.co.za>
Message-ID: <1360077109.23.0.456582945993.issue14910@psf.upfronthosting.co.za>


Changes by Ugra D?niel <daniel.ugra at gmail.com>:


----------
nosy: +daniel.ugra

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

From report at bugs.python.org  Tue Feb  5 16:14:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 15:14:15 +0000
Subject: [issue17132] yield_arg missing from symbol.sym_name
In-Reply-To: <1360076913.18.0.0139666205615.issue17132@psf.upfronthosting.co.za>
Message-ID: <3Z0q7q1N8dzSgV@mail.python.org>


Roundup Robot added the comment:

New changeset 23850c3899e8 by Benjamin Peterson in branch '3.3':
update symbol.py for yield from grammar changes (closes #17132)
http://hg.python.org/cpython/rev/23850c3899e8

New changeset 0fcd975765a7 by Benjamin Peterson in branch 'default':
merge 3.3 (#17132)
http://hg.python.org/cpython/rev/0fcd975765a7

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  5 16:14:25 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 05 Feb 2013 15:14:25 +0000
Subject: [issue17133] ssl.wrap_socket doesn't take server_hostname as a kwarg
Message-ID: <1360077265.48.0.644174005672.issue17133@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

The wrap_socket function in ssl.py (unlike the method of the same name in SSLContext) doesn't accept a server_hostname argument, despite the fact that it's a one-liner calling SSLSocket, which does take that argument. It it like this for a reason, or just an oversight?

Unless there is some reason not to do so, I think a server_hostname kwarg should be added to the wrap_socket function.

----------
messages: 181442
nosy: pitrou, vinay.sajip
priority: normal
severity: normal
status: open
title: ssl.wrap_socket doesn't take server_hostname as a kwarg
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb  5 16:18:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 15:18:57 +0000
Subject: [issue16811] email.message.Message flatten dies of list index out of
	range
In-Reply-To: <1356776594.55.0.534961583044.issue16811@psf.upfronthosting.co.za>
Message-ID: <3Z0qFF2hXTzSxG@mail.python.org>


Roundup Robot added the comment:

New changeset 4553dfcafac7 by R David Murray in branch '3.3':
News item for issue #16811 fix.
http://hg.python.org/cpython/rev/4553dfcafac7

New changeset 68be406e76e1 by R David Murray in branch 'default':
Merge: News item for issue #16811 fix.
http://hg.python.org/cpython/rev/68be406e76e1

----------

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

From report at bugs.python.org  Tue Feb  5 16:27:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 15:27:03 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360078023.43.0.551652168218.issue17129@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Yes, it's a duplicate of #13665. Sorry, I didn't make a proper search. Although this is a new feature it's a fundament for cert validation.

----------

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

From report at bugs.python.org  Tue Feb  5 16:29:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 15:29:03 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
Message-ID: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I found a recipe how to access the Windows certificate store and dump its content as PEM. The code doesn't look complicated and could be added to _ssl.c

http://fixunix.com/openssl/254866-re-can-openssl-use-windows-certificate-store.html

----------
components: Extension Modules
messages: 181445
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Use Windows' certificate store for CA certs
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Feb  5 16:32:18 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 15:32:18 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1360078338.38.0.785304171449.issue17134@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


Added file: http://bugs.python.org/file28964/certstore.cpp

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

From report at bugs.python.org  Tue Feb  5 16:33:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 15:33:58 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360078438.43.0.262427989995.issue17129@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I found a recipe to retrieve CA certs from Window's cert store, see #17134.

----------

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

From report at bugs.python.org  Tue Feb  5 16:39:59 2013
From: report at bugs.python.org (Greg Hellings)
Date: Tue, 05 Feb 2013 15:39:59 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1360078799.08.0.764191210678.issue3754@psf.upfronthosting.co.za>


Greg Hellings added the comment:

I'm trying to cross-compile the latest default out of Mercurial based on the status of this. Currently it fails with the following invocation:

$ ../configure --host=i686-w64-mingw32 --build=x86_64-redhat-linux-gnu --target=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32/sys-root/mingw --exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw --bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin --sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin --sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc --datadir=/usr/i686-w64-mingw32/sys-root/mingw/share --includedir=/usr/i686-w64-mingw32/sys-root/mingw/include --libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib --libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec --localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var --sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com --mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man --infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info --enable-ipv6 --enable-shared --with-computed-gotos=yes --with-dbmliborder=gdbm:ndbm:bdb --with-system-expat --with-system-ffi --with-pydebug --with-tsc
checking for hg... found
checking build system type... x86_64-redhat-linux-gnu
checking host system type... i686-w64-mingw32
checking for python interpreter for cross build... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... configure: error: cross build not supported for i686-w64-mingw32
error: Bad exit status from /var/tmp/rpm-tmp.sZjjCl (%build)

This is in a Fedora 18 environment using its included MinGW packages to do the cross compile. I have applied no patches and just did the hg clone this morning from the official repository. Are any of these attached patches still necessary? Is there any documentation about what the process is now for doing the cross-compile build?

----------

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

From report at bugs.python.org  Tue Feb  5 16:49:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 15:49:53 +0000
Subject: [issue17073] Integer overflow in sqlite module
In-Reply-To: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za>
Message-ID: <1360079393.29.0.0235580831447.issue17073@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here are tests for some bugs.

----------
assignee:  -> serhiy.storchaka
Added file: http://bugs.python.org/file28965/sqlite_int_overflow_tests.patch

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

From report at bugs.python.org  Tue Feb  5 17:04:43 2013
From: report at bugs.python.org (Ray Donnelly)
Date: Tue, 05 Feb 2013 16:04:43 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1360080283.58.0.671261741602.issue3754@psf.upfronthosting.co.za>


Ray Donnelly added the comment:

Yes, patches are still required.

Mainly Roumen's big patch [1] and then a load more too. Matthias Klose has merged a few cross compilation patches.

Here my project with patches for 3.3.0 and an emphasis on cross:
https://github.com/mingwandroid/crucifixion-freedom

...and here's mingwbuilds with the exact same patches (but likely tidier build scripts) without the cross focus:
https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0

Next time there's a release of Python 3, I'll rebase my patches against that.

[1] http://bugs.python.org/issue3871

----------

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

From report at bugs.python.org  Tue Feb  5 17:09:41 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:09:41 +0000
Subject: [issue17135] imp doc should direct to importlib
Message-ID: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

Title says it all.

----------
assignee: docs at python
components: Documentation
messages: 181450
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: imp doc should direct to importlib
versions: Python 3.1, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb  5 17:18:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 16:18:34 +0000
Subject: [issue16203] Proposal: add re.fullmatch() method
In-Reply-To: <1349991042.0.0.875123830426.issue16203@psf.upfronthosting.co.za>
Message-ID: <1360081114.0.0.132710878288.issue16203@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I did not analyze the patch deeply, only left on Rietveld comments on first sight. Need to update the documentation.

----------

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

From report at bugs.python.org  Tue Feb  5 17:20:37 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:20:37 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360081237.06.0.188325565043.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

There is no rush, even if this doesn?t get into the docs distributed with the releases that are due next week-end, people will see it in the online docs a day after it?s committed.

----------
assignee: docs at python -> eric.araujo

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

From report at bugs.python.org  Tue Feb  5 17:22:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Feb 2013 16:22:27 +0000
Subject: [issue17133] ssl.wrap_socket doesn't take server_hostname as a kwarg
In-Reply-To: <1360077265.48.0.644174005672.issue17133@psf.upfronthosting.co.za>
Message-ID: <1360081347.34.0.887141960481.issue17133@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The reason is that wrap_socket() is there only for compatibility reasons, and I'd like people to switch to SSLContext instead. 12-argument functions are only good for LISPers ;-)

As for SSLSocket, its constructor isn't a public API.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Feb  5 17:23:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Feb 2013 16:23:16 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1360081396.72.0.483562327253.issue17134@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/issue17134>
_______________________________________

From report at bugs.python.org  Tue Feb  5 17:24:11 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 05 Feb 2013 16:24:11 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
Message-ID: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman:

I recently filed http://llvm.org/bugs/show_bug.cgi?id=15153, prompted by https://bugs.gentoo.org/show_bug.cgi?id=427338 (for 2.7, and https://bugs.gentoo.org/show_bug.cgi?id=427330 for 3.2), for which I found http://bugs.python.org/issue9852. Similar issues have subsequently been found in http://bugs.python.org/issue13370. The latter has been fixed in http://hg.python.org/cpython/rev/a425f2697273 (for 2.7 -- other branches were affected as well), but that fix is incorrectly scoped to just OS X.

It looks like clang is actually right here, and gcc is wrong; see their bug at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942 (clang has a bug for this at http://llvm.org/bugs/show_bug.cgi?id=15153).

----------
components: ctypes
messages: 181454
nosy: djc
priority: normal
severity: normal
status: open
title: ctypes tests fail with clang on non-OS X
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Feb  5 17:26:14 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Feb 2013 16:26:14 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1360081574.02.0.177446300281.issue10557@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Sure, this can be closed as far as I'm concerned.

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

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

From report at bugs.python.org  Tue Feb  5 17:26:22 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Feb 2013 16:26:22 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1360081582.15.0.617892524059.issue10557@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/issue10557>
_______________________________________

From report at bugs.python.org  Tue Feb  5 17:35:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 16:35:02 +0000
Subject: [issue16948] email.mime.text.MIMEText: QP encoding broken with
	charset!=ISO-8859-1
In-Reply-To: <1358016775.26.0.412297588527.issue16948@psf.upfronthosting.co.za>
Message-ID: <3Z0rx15gHqzSWl@mail.python.org>


Roundup Robot added the comment:

New changeset 801cb3918212 by R David Murray in branch '3.2':
#16948: Fix quopri encoding of non-latin1 character sets.
http://hg.python.org/cpython/rev/801cb3918212

New changeset e644058e8e7b by R David Murray in branch '3.3':
Merge: #16948: Fix quopri encoding of non-latin1 character sets.
http://hg.python.org/cpython/rev/e644058e8e7b

New changeset 009dc81e8bc9 by R David Murray in branch 'default':
Merge: #16948: Fix quopri encoding of non-latin1 character sets.
http://hg.python.org/cpython/rev/009dc81e8bc9

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  5 17:36:02 2013
From: report at bugs.python.org (Greg Hellings)
Date: Tue, 05 Feb 2013 16:36:02 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1360082162.14.0.416984460894.issue3754@psf.upfronthosting.co.za>


Greg Hellings added the comment:

Bummer, the patches in that issue do not apply cleanly to either the 3.3.0 released tarball nor to the 3.3 branch from hg.

----------

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

From report at bugs.python.org  Tue Feb  5 17:37:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Feb 2013 16:37:14 +0000
Subject: [issue16948] email.mime.text.MIMEText: QP encoding broken with
	charset!=ISO-8859-1
In-Reply-To: <1358016775.26.0.412297588527.issue16948@psf.upfronthosting.co.za>
Message-ID: <1360082234.3.0.608550101649.issue16948@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed.  I'm glad you caught this before the final release of 3.2.  This is a bit of an embarrassing bug :(.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Tue Feb  5 17:39:55 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:39:55 +0000
Subject: [issue17129] Include CA bundle and provide access to system's CA
In-Reply-To: <1360006353.36.0.371711249441.issue17129@psf.upfronthosting.co.za>
Message-ID: <1360082395.65.0.574073819275.issue17129@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Python SSL stack doesn't have a default CA Store

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

From report at bugs.python.org  Tue Feb  5 17:43:02 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:43:02 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1360082582.25.0.671969438704.issue17134@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Isn?t this part of #13655?  One feature is usually discussed for all platforms in one bug report.  (Sorry for all the bureaucracy in your recent reports, but it helps keep things manageable :)

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Feb  5 17:44:06 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:44:06 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1360082646.06.0.394334325009.issue13655@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Copy of a message by Christian Heimes on a duplicate report:
  
For effective SSL server cert validation a bundle of trustworthy CA certs is required. Most system ship such a bundle but it's not always possible to access the bundle from Python / OpenSSL. Windows and Mac OS X come into my mind. wget and curl ship a copy of Mozilla's CA cert bundle.

The site http://curl.haxx.se/docs/caextract.html explains how to extract the CA certs in PEM format. I suggest that we ship the CA bundle with Python and use a lookup chain:

- user defined path to a cacert directory or cacert.pem file

- cacert directory or PEM file in the user's home directory: 
  cacertdir = os.path.join(site.USER_SITE, os.pardir, "cacert")
  cacertfile = os.path.join(site.USER_SITE, os.pardir, "cacert.pem")

- system's ca cert directory (/etc/ssl/certs on Linux)

- CA cert bundle shipped with the Python installation.

----------

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

From report at bugs.python.org  Tue Feb  5 17:48:53 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Feb 2013 16:48:53 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360082933.52.0.385159157771.issue17136@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +meador.inge, ronaldoussoren

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

From report at bugs.python.org  Tue Feb  5 18:11:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 17:11:24 +0000
Subject: [issue14263] switch_index_if_fails fails on py2
In-Reply-To: <1331580575.36.0.0269890072564.issue14263@psf.upfronthosting.co.za>
Message-ID: <1360084284.46.0.499700021541.issue14263@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Should it be closed?

----------
nosy: +serhiy.storchaka
status: open -> pending

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

From report at bugs.python.org  Tue Feb  5 18:16:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 17:16:01 +0000
Subject: [issue14263] switch_index_if_fails fails on py2
In-Reply-To: <1331580575.36.0.0269890072564.issue14263@psf.upfronthosting.co.za>
Message-ID: <1360084561.85.0.746653566109.issue14263@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Right, I probably kept this open for the packaging backport, so now it?s moot.

BTW, there are many distutils2 bugs that I haven?t closed, as they will still be useful for the successors of d2.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: pending -> closed
versions: +3rd party -Python 2.6, Python 2.7

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

From report at bugs.python.org  Tue Feb  5 18:30:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2013 17:30:50 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1360085450.9.0.856560886362.issue17134@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I like to split up tasks in small subtasks.

It's true that #13655 benefits from this feature but it can be implemented without this ticket. This enhancement also requires some addition to API and bindings to Windows' crypt32.dll. It might be inappropriate to add it to #13655 because we need to backport #13655 to Python 2.6 to 3.3.

----------

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

From report at bugs.python.org  Tue Feb  5 18:31:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 17:31:08 +0000
Subject: [issue12177] re.match raises MemoryError
In-Reply-To: <1306346665.06.0.86860516028.issue12177@psf.upfronthosting.co.za>
Message-ID: <1360085468.73.0.334655948064.issue12177@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue9669.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> regexp: zero-width matches in MIN_UNTIL

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

From report at bugs.python.org  Tue Feb  5 18:32:22 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Tue, 05 Feb 2013 17:32:22 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
Message-ID: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>


New submission from Jan Lachnitt:

Python 3.3 64-bit seems to compile one of my files incorrectly. Specifically, os.path.isdir returns True for a nonexistent folder. The important point is that the code works correctly when it is performed step-by-step in pdb.

Python version:
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32

OS:
Windows 8 64-bit

The code works fine in Python 3.2.3 32-bit on Windows XP.

My project is quite complex and it interacts with other software packages. I tried to make a reduced test-case but I could not reproduce the problem this way. What files do you need for processing this bug report? Will e.g. the source file in question and the corresponding compiled file (*.pyc) be enough? Or should I upload the whole project here, along with the instructions on how to run it?

----------
messages: 181465
nosy: pepalogik
priority: normal
severity: normal
status: open
title: Malfunctioning compiled code in Python 3.3 x64
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  5 19:42:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 18:42:59 +0000
Subject: [issue15359] Sockets support for CAN_BCM
In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>
Message-ID: <3Z0vmg0FhQzST2@mail.python.org>


Roundup Robot added the comment:

New changeset f714af60508d by Charles-Fran?ois Natali in branch 'default':
Issue #15359: Add CAN_BCM protocol support to the socket module. Patch by Brian
http://hg.python.org/cpython/rev/f714af60508d

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  5 19:47:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Feb 2013 18:47:12 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1360090032.6.0.10639843087.issue17134@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sounds promising. Do you think this should be hooked into SSLContext.set_default_verify_paths, or be exposed as a separate method?

----------

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

From report at bugs.python.org  Tue Feb  5 20:15:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Feb 2013 19:15:32 +0000
Subject: [issue16203] Proposal: add re.fullmatch() method
In-Reply-To: <1349991042.0.0.875123830426.issue16203@psf.upfronthosting.co.za>
Message-ID: <1360091732.06.0.222300342138.issue16203@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The patch doesn't seem to include failure cases for fullmatch (i.e. cases where fullmatch returns None where match or search would return a match).

----------

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

From report at bugs.python.org  Tue Feb  5 20:17:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 19:17:07 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360091827.67.0.120240984752.issue16800@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In general it looks good to me. But we can get rid of Python file and use only os.open/os.write/os.close. Here is an updated patch which carefully close a file descriptor and remove a file even if write or close failed.

Amir Szekely, can you please submit a contributor form?

http://python.org/psf/contrib/contrib-form/
http://python.org/psf/contrib/

----------
nosy: +georg.brandl, ncoghlan, serhiy.storchaka
Added file: http://bugs.python.org/file28966/fix_tempfile_leaving_files_behind_2.patch

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

From report at bugs.python.org  Tue Feb  5 20:19:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 19:19:42 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360091982.19.0.807196398102.issue16800@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In general it looks good to me. But we can get rid of Python file and use only os.open/os.write/os.close. Here is an updated patch which carefully close a file descriptor and remove a file even if write or close failed.

Amir Szekely, can you please submit a contributor form?

http://python.org/psf/contrib/contrib-form/
http://python.org/psf/contrib/

----------
Added file: http://bugs.python.org/file28967/fix_tempfile_leaving_files_behind_2.patch

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

From report at bugs.python.org  Tue Feb  5 20:20:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 19:20:24 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360092024.06.0.750182006982.issue16800@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg181470

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

From report at bugs.python.org  Tue Feb  5 20:20:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 19:20:31 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360092031.98.0.273686654142.issue16800@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28967/fix_tempfile_leaving_files_behind_2.patch

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

From report at bugs.python.org  Tue Feb  5 20:28:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 19:28:37 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1360091827.67.0.120240984752.issue16800@psf.upfronthosting.co.za>
Message-ID: <201302052128.09721.storchaka@gmail.com>


Serhiy Storchaka added the comment:

And here are patches for 2.7 and 3.2 (there are some peculiarities, i.e. in 
exception handling).

----------
Added file: http://bugs.python.org/file28968/fix_tempfile_leaving_files_behind_2-2.7.patch
Added file: http://bugs.python.org/file28969/fix_tempfile_leaving_files_behind_2-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16800>
_______________________________________
-------------- next part --------------
diff -r 20f0c5398e97 Lib/tempfile.py
--- a/Lib/tempfile.py	Mon Feb 04 10:29:38 2013 -0500
+++ b/Lib/tempfile.py	Tue Feb 05 20:57:18 2013 +0200
@@ -193,14 +193,16 @@
             name = namer.next()
             filename = _os.path.join(dir, name)
             try:
-                fd = _os.open(filename, flags, 0600)
-                fp = _os.fdopen(fd, 'w')
-                fp.write('blat')
-                fp.close()
-                _os.unlink(filename)
-                del fp, fd
+                fd = _os.open(filename, flags, 0o600)
+                try:
+                    try:
+                        _os.write(fd, b'blat')
+                    finally:
+                        _os.close(fd)
+                finally:
+                    _os.unlink(filename)
                 return dir
-            except (OSError, IOError), e:
+            except (OSError, IOError) as e:
                 if e[0] != _errno.EEXIST:
                     break # no point trying more names in this directory
                 pass
diff -r 20f0c5398e97 Lib/test/test_support.py
--- a/Lib/test/test_support.py	Mon Feb 04 10:29:38 2013 -0500
+++ b/Lib/test/test_support.py	Tue Feb 05 20:57:18 2013 +0200
@@ -1298,6 +1298,33 @@
             except:
                 break
 
+ at contextlib.contextmanager
+def swap_attr(obj, attr, new_val):
+    """Temporary swap out an attribute with a new object.
+
+    Usage:
+        with swap_attr(obj, "attr", 5):
+            ...
+
+        This will set obj.attr to 5 for the duration of the with: block,
+        restoring the old value at the end of the block. If `attr` doesn't
+        exist on `obj`, it will be created and then deleted at the end of the
+        block.
+    """
+    if hasattr(obj, attr):
+        real_val = getattr(obj, attr)
+        setattr(obj, attr, new_val)
+        try:
+            yield
+        finally:
+            setattr(obj, attr, real_val)
+    else:
+        setattr(obj, attr, new_val)
+        try:
+            yield
+        finally:
+            delattr(obj, attr)
+
 def py3k_bytes(b):
     """Emulate the py3k bytes() constructor.
 
diff -r 20f0c5398e97 Lib/test/test_tempfile.py
--- a/Lib/test/test_tempfile.py	Mon Feb 04 10:29:38 2013 -0500
+++ b/Lib/test/test_tempfile.py	Tue Feb 05 20:57:18 2013 +0200
@@ -1,7 +1,9 @@
 # tempfile.py unit tests.
 import tempfile
+import errno
 import os
 import signal
+import shutil
 import sys
 import re
 import warnings
@@ -202,8 +204,45 @@
 
 test_classes.append(test__candidate_tempdir_list)
 
+# We test _get_default_tempdir some more by testing gettempdir.
 
-# We test _get_default_tempdir by testing gettempdir.
+class TestGetDefaultTempdir(TC):
+    """Test _get_default_tempdir()."""
+
+    def test_no_files_left_behind(self):
+        # use a private empty directory
+        our_temp_directory = tempfile.mkdtemp()
+        try:
+            # force _get_default_tempdir() to consider our empty directory
+            def our_candidate_list():
+                return [our_temp_directory]
+
+            with test_support.swap_attr(tempfile, "_candidate_tempdir_list",
+                                        our_candidate_list):
+                # verify our directory is empty after _get_default_tempdir()
+                tempfile._get_default_tempdir()
+                self.assertEqual(os.listdir(our_temp_directory), [])
+
+                def raise_OSError(*args, **kwargs):
+                    raise OSError(-1)
+
+                with test_support.swap_attr(os, "open", raise_OSError):
+                    # test again with failing os.open()
+                    with self.assertRaises(IOError) as cm:
+                        tempfile._get_default_tempdir()
+                    self.assertEqual(cm.exception.errno, errno.ENOENT)
+                    self.assertEqual(os.listdir(our_temp_directory), [])
+
+                with test_support.swap_attr(os, "write", raise_OSError):
+                    # test again with failing os.write()
+                    with self.assertRaises(IOError) as cm:
+                        tempfile._get_default_tempdir()
+                    self.assertEqual(cm.exception.errno, errno.ENOENT)
+                    self.assertEqual(os.listdir(our_temp_directory), [])
+        finally:
+            shutil.rmtree(our_temp_directory)
+
+test_classes.append(TestGetDefaultTempdir)
 
 
 class test__get_candidate_names(TC):
-------------- next part --------------
diff -r 801cb3918212 Lib/tempfile.py
--- a/Lib/tempfile.py	Tue Feb 05 10:49:49 2013 -0500
+++ b/Lib/tempfile.py	Tue Feb 05 20:57:09 2013 +0200
@@ -175,11 +175,13 @@
             filename = _os.path.join(dir, name)
             try:
                 fd = _os.open(filename, _bin_openflags, 0o600)
-                fp = _io.open(fd, 'wb')
-                fp.write(b'blat')
-                fp.close()
-                _os.unlink(filename)
-                del fp, fd
+                try:
+                    try:
+                        _os.write(fd, b'blat')
+                    finally:
+                        _os.close(fd)
+                finally:
+                    _os.unlink(filename)
                 return dir
             except (OSError, IOError) as e:
                 if e.args[0] != _errno.EEXIST:
diff -r 801cb3918212 Lib/test/test_tempfile.py
--- a/Lib/test/test_tempfile.py	Tue Feb 05 10:49:49 2013 -0500
+++ b/Lib/test/test_tempfile.py	Tue Feb 05 20:57:09 2013 +0200
@@ -1,5 +1,6 @@
 # tempfile.py unit tests.
 import tempfile
+import errno
 import os
 import signal
 import sys
@@ -211,8 +212,42 @@
 
 test_classes.append(test__candidate_tempdir_list)
 
+# We test _get_default_tempdir some more by testing gettempdir.
 
-# We test _get_default_tempdir by testing gettempdir.
+class TestGetDefaultTempdir(TC):
+    """Test _get_default_tempdir()."""
+
+    def test_no_files_left_behind(self):
+        # use a private empty directory
+        with tempfile.TemporaryDirectory() as our_temp_directory:
+            # force _get_default_tempdir() to consider our empty directory
+            def our_candidate_list():
+                return [our_temp_directory]
+
+            with support.swap_attr(tempfile, "_candidate_tempdir_list",
+                                   our_candidate_list):
+                # verify our directory is empty after _get_default_tempdir()
+                tempfile._get_default_tempdir()
+                self.assertEqual(os.listdir(our_temp_directory), [])
+
+                def raise_OSError(*args, **kwargs):
+                    raise OSError(-1)
+
+                with support.swap_attr(os, "open", raise_OSError):
+                    # test again with failing os.open()
+                    with self.assertRaises(IOError) as cm:
+                        tempfile._get_default_tempdir()
+                    self.assertEqual(cm.exception.args[0], errno.ENOENT)
+                    self.assertEqual(os.listdir(our_temp_directory), [])
+
+                with support.swap_attr(os, "write", raise_OSError):
+                    # test again with failing os.write()
+                    with self.assertRaises(IOError) as cm:
+                        tempfile._get_default_tempdir()
+                    self.assertEqual(cm.exception.errno, errno.ENOENT)
+                    self.assertEqual(os.listdir(our_temp_directory), [])
+
+test_classes.append(TestGetDefaultTempdir)
 
 
 class test__get_candidate_names(TC):

From report at bugs.python.org  Tue Feb  5 20:38:42 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 05 Feb 2013 19:38:42 +0000
Subject: [issue15359] Sockets support for CAN_BCM
In-Reply-To: <1342357855.99.0.608670333225.issue15359@psf.upfronthosting.co.za>
Message-ID: <1360093122.77.0.223787274482.issue15359@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Committed.
Brian, thanks for the patch!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  5 20:42:25 2013
From: report at bugs.python.org (Gutzwiller)
Date: Tue, 05 Feb 2013 19:42:25 +0000
Subject: [issue17138] XPath error in xml.etree.ElementTree
Message-ID: <1360093345.6.0.651330972741.issue17138@psf.upfronthosting.co.za>


New submission from Gutzwiller:

$ python3
Python 3.3.0 (default, Jan 25 2013, 09:38:18) 
[GCC 4.4.5] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> xml = ET.fromstring("<root><h1>1</h1><p><h1>2</h1></p></root>")
>>> result = xml.find(".//h1[2]")        
>>> print(result)
None

========================================================================
Expected result : "<Element 'h1' at ...>"  (<h1>2</h1>)

----------
components: XML
messages: 181473
nosy: Antoine2008
priority: normal
severity: normal
status: open
title: XPath error in xml.etree.ElementTree
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Feb  5 20:52:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Feb 2013 19:52:12 +0000
Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates
	prematurely
In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za>
Message-ID: <1360093932.76.0.846105260846.issue16723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This looks ok to me. I am slightly surprised that isclosed() isn't documented anywhere (but perhaps it's better).

----------

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

From report at bugs.python.org  Tue Feb  5 21:06:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Feb 2013 20:06:25 +0000
Subject: [issue2840] Expat parser locks XML source file if ContentHandler
	raises an exception
In-Reply-To: <1210621474.39.0.327877522239.issue2840@psf.upfronthosting.co.za>
Message-ID: <1360094785.02.0.133406256809.issue2840@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue15388. Parser doesn't close an input source's stream if an exception raised.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> SAX parse (ExpatParser) leaks file handle when given filename input

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

From report at bugs.python.org  Tue Feb  5 21:14:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 20:14:34 +0000
Subject: [issue17122] Fix and cleanup test_functools
In-Reply-To: <1359980964.91.0.854026651157.issue17122@psf.upfronthosting.co.za>
Message-ID: <3Z0xpK5nNlzSNy@mail.python.org>


Roundup Robot added the comment:

New changeset 2a369c32f1f1 by Serhiy Storchaka in branch 'default':
Issue #17122: Fix and cleanup test_functools.py.
http://hg.python.org/cpython/rev/2a369c32f1f1

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  5 21:24:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Feb 2013 20:24:57 +0000
Subject: [issue17107] test_sni in test_urllib2net could be enabled
In-Reply-To: <1359843352.18.0.227762212958.issue17107@psf.upfronthosting.co.za>
Message-ID: <3Z0y2J2z6CzSZY@mail.python.org>


Roundup Robot added the comment:

New changeset f74a12e23aaa by Antoine Pitrou in branch 'default':
Issue #17107: Test client-side SNI support in urllib.request thanks to the new server-side SNI support in the ssl module.
http://hg.python.org/cpython/rev/f74a12e23aaa

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Feb  5 21:26:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Feb 2013 20:26:28 +0000
Subject: [issue17107] test_sni in test_urllib2net could be enabled
In-Reply-To: <1359843352.18.0.227762212958.issue17107@psf.upfronthosting.co.za>
Message-ID: <1360095988.61.0.32000303088.issue17107@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've tweaked the patch a bit and committed it. Thank you!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 3.5

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

From report at bugs.python.org  Tue Feb  5 21:30:15 2013
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=)
Date: Tue, 05 Feb 2013 20:30:15 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360096215.28.0.174290123291.issue16038@psf.upfronthosting.co.za>


Micha? Jastrz?bski added the comment:

Hello,

I've made patch which address this issue.

----------
keywords: +patch
nosy: +inc0
Added file: http://bugs.python.org/file28970/ftplib_maxline.patch

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

From report at bugs.python.org  Tue Feb  5 21:32:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 20:32:35 +0000
Subject: [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1360096355.92.0.809315249791.issue17135@psf.upfronthosting.co.za>


Eric Snow added the comment:

Agreed.  It should also link to the new import section in the language reference rather than to the import statement.

----------
nosy: +eric.snow

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

From report at bugs.python.org  Tue Feb  5 21:36:14 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Feb 2013 20:36:14 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360096574.11.0.365316050044.issue17137@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Reminds me of this question on StackOverflow:

http://stackoverflow.com/questions/14135846/string-concatenation-with-python-33-isdir-always-returns-true-3-hours-head

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

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

From report at bugs.python.org  Tue Feb  5 21:55:38 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Feb 2013 20:55:38 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360097738.37.0.262904693325.issue17137@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The SO post is scary.  Maybe a non-normalized (smallest representation) PEP393 string is escaping into the wild?

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

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

From report at bugs.python.org  Tue Feb  5 21:56:41 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Feb 2013 20:56:41 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360097801.41.0.412657979483.issue17137@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Feb  5 22:10:21 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 05 Feb 2013 21:10:21 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360098621.57.0.440686304399.issue17136@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

The changes in CPython mentioned by you are in bundled copy of libffi for OS X (Modules/_ctypes/libffi_osx).
You probably should report the problem to libffi upstream.
Gentoo ebuilds of CPython use --with-system-ffi option, so any fixes in bundled copy of libffi (Modules/_ctypes/libffi) would not help in Gentoo.

----------
nosy: +Arfrever

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

From report at bugs.python.org  Tue Feb  5 22:17:16 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Feb 2013 21:17:16 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360099036.83.0.468326532677.issue17137@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
keywords: +3.3regression
nosy: +flox, haypo

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

From report at bugs.python.org  Tue Feb  5 22:23:11 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Feb 2013 21:23:11 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360099391.9.0.16230114186.issue17137@psf.upfronthosting.co.za>


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


----------
priority: normal -> high

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

From report at bugs.python.org  Tue Feb  5 22:43:47 2013
From: report at bugs.python.org (Dave)
Date: Tue, 05 Feb 2013 21:43:47 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
Message-ID: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>


New submission from Dave:

Calling datetime.datetime.now() will return only the Date and time to the second w/o the decimal portion when the second increments when also running firefox w/shockwave flash enabled on a windows 7 machine.

  
Example output: 
counter1 is: 23360 time is: 2013-02-05 16:32:24.999000      
counter1 is: 23361 time is: 2013-02-05 16:32:25
counter1 is: 23362 time is: 2013-02-05 16:32:25.002000
Notice the missing decimal value on the middle one.

To reproduce:
Code:
    counter = 0
    while(True):
        counter +=1
            time = datetime.datetime.now()
            numericDateTime = 
            print("counter1 is: " + str(counter) + " time is: " + time)

I can get this to occur every time that firefox is running with Shockwave flash enabled.
datetime.now() works fine w/o firefox running w/shockwave flash enabled.

I believe the datetime.now() should always return the same format.

----------
components: Windows
messages: 181484
nosy: Dave
priority: normal
severity: normal
status: open
title: dateTime.now() return format missing decimal seconds.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Feb  5 22:46:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Feb 2013 21:46:07 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360100767.93.0.000664734720617.issue17139@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I believe the datetime.now() should always return the same format.

It's now how it was implemented:
http://docs.python.org/dev/library/datetime.html#datetime.datetime.__str__
and
http://docs.python.org/dev/library/datetime.html#datetime.datetime.isoformat

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Feb  5 22:48:54 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Feb 2013 21:48:54 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360100934.68.0.774951314514.issue17139@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

See also issue #1074462

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

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

From report at bugs.python.org  Tue Feb  5 22:53:51 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Feb 2013 21:53:51 +0000
Subject: [issue17138] XPath error in xml.etree.ElementTree
In-Reply-To: <1360093345.6.0.651330972741.issue17138@psf.upfronthosting.co.za>
Message-ID: <1360101231.53.0.107114127637.issue17138@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +eli.bendersky, flox

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

From report at bugs.python.org  Tue Feb  5 22:57:51 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Feb 2013 21:57:51 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360101471.76.0.478588287744.issue17139@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

This is a feature request rather than a bug report;  changing fields accordingly.

Also, given the discussion leading to the rejection of issue 1074462, and the fact that you can now use %f in strftime as an easy way to get consistent output (issue 1158), I'm closing this as rejected.

>>> d = datetime.datetime(2013, 10, 11, 12, 34, 56, 0)
>>> d.strftime("%Y-%m-%d %H:%M:%S.%f")
'2013-10-11 12:34:56.000000'

----------
resolution:  -> rejected
status: open -> closed
type: behavior -> enhancement
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Tue Feb  5 23:01:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Feb 2013 22:01:40 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360101700.28.0.742398914749.issue17137@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On Windows, os.path.isdir calls nt._isdir(). Core of this C function:

        wchar_t *wpath = PyUnicode_AsUnicode(po);
        if (wpath == NULL)
            return NULL;

        attributes = GetFileAttributesW(wpath);
        if (attributes == INVALID_FILE_ATTRIBUTES)
            Py_RETURN_FALSE;
        ...

Can you please try to call directly nt._isdir()? Can also also compare with stat.S_ISDIR(os.stat(fn).st_mode)?

If the problem is something with the implementation of Unicode, it would be interesting to try to get the content of the string using:

 * print(ascii(path.encode("unicode_internal"))) # should be result of PyUnicode_AsUnicode() which is cached
 * print(ascii(path.encode("utf-8")))

----------

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

From report at bugs.python.org  Tue Feb  5 23:03:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Feb 2013 22:03:49 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360101829.04.0.148374343514.issue17137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Unicode, Windows
nosy: +ezio.melotti
versions: +Python 3.4

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

From report at bugs.python.org  Tue Feb  5 23:13:54 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Tue, 05 Feb 2013 22:13:54 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1360102434.06.0.606521883028.issue13655@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

?ric's suggestion is also implemented in python-requests if I remember correctly. It allows for user-specified PEM files and tries to find the operating system bundle. This would be a wonderful inclusion in the standard library.

----------
nosy: +icordasc

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

From report at bugs.python.org  Wed Feb  6 00:01:30 2013
From: report at bugs.python.org (Dave)
Date: Tue, 05 Feb 2013 23:01:30 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360105290.8.0.500925875315.issue17139@psf.upfronthosting.co.za>


Dave added the comment:

I appreciate you guys looking into this so quickly, but let's dig a little deeper.

1. STINNER Victor, you claim this is already fixed in 3.4 by the link, however this doesn't really help since I'm not even up to 3.3 yet (though I'm considering it, I meant to select 3.2 above).  No one has yet provided any insight into why this condition only occurs when firefox is up running shockwave flash...(to me this is an even bigger question as I have a 7 other rather under tasked cores at my disposal).

2.  Mark Dickinson, let's break this down.  I've already worked around it as I?m sure that EVERYONE ELSE WHO USES IT has already done as well...  We know as coders it's more difficult to work with a varying format (no advantage there).  Which begs the question why not fix it so everyone doesn't have to?  By the issue you referenced it's been known and unfixed since at least since 2004.  Also, no curiosity why this only occurs when running firefox w/shockwave flash?

Again I do appreciate you guys looking into this so quickly, but I don't know if this is actually going to get fixed, why it wasn't fixed in 2004, or is the Python motto "it's not broke if there exists a workaround".  Odd that more time was spent talking about this (and Mark and myself independently implemented actual fixes) than the fix would have taken to apply to the baseline(I used to see this much other places I've worked).  But I'm happy to say, I never saw responses back so quickly, which is very hopeful.

Sincerely,
Dave

----------
versions: +Python 3.2 -Python 3.4

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

From report at bugs.python.org  Wed Feb  6 00:06:24 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 23:06:24 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360105584.83.0.135906191818.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Added file: http://bugs.python.org/file28971/cleanup-test-collections.diff

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

From report at bugs.python.org  Wed Feb  6 00:06:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 23:06:39 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360105599.2.0.128810596173.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Added file: http://bugs.python.org/file28972/odict.diff

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

From report at bugs.python.org  Wed Feb  6 00:10:05 2013
From: report at bugs.python.org (Dave)
Date: Tue, 05 Feb 2013 23:10:05 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360105805.92.0.911636614612.issue17139@psf.upfronthosting.co.za>


Dave added the comment:

Point was/is that I'd be willing to fix this so that others don't have to.  It's for OTHERS SAKE that I submitted this issue as my system is already bullet proof from this defect/lack of feature situation.  This is also my first attempt to get involved with the freeware community.

Thanks,
Dave

----------

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

From report at bugs.python.org  Wed Feb  6 00:12:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Feb 2013 23:12:01 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360105921.8.0.510961645117.issue17139@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think Victor meant "not" instead of "now".

It doesn't only occur when your run particular programs, it occurs whenever the microseconds are zero.  It is possible that your particular combination of programs produces a timing pattern that means you see microseconds zero more often in your tests.

Keep in mind that the str is a *convenience* representation.  As such it is *much* more convenient to not print the zero microseconds in the very common case of constructed datetimes that have zero microseconds.

If you want to strictly control the representation you want to use specific formatting, which you can do.  

Thus the rejection.

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

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

From report at bugs.python.org  Wed Feb  6 00:18:55 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 23:18:55 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360106335.44.0.278603661874.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file28971/cleanup-test-collections.diff

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

From report at bugs.python.org  Wed Feb  6 00:19:01 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 23:19:01 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360106341.47.0.753763144763.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file28972/odict.diff

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

From report at bugs.python.org  Wed Feb  6 00:22:34 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 05 Feb 2013 23:22:34 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360106554.59.0.100529353163.issue16991@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

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

From report at bugs.python.org  Wed Feb  6 01:28:03 2013
From: report at bugs.python.org (Dave)
Date: Wed, 06 Feb 2013 00:28:03 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360110483.15.0.665729340474.issue17139@psf.upfronthosting.co.za>


Dave added the comment:

Thanks David Murry for clearing up STINNER Victor comments.  I already feel like I work here;)  So "it's not broke if there exists a workaround".  

In that case it's time to update the documents (which often takes longer than the code to update) to reflect this inconsistency so others won't run into this like I did (it took time to trouble shoot this as it was occurring prior to my logging being set up).  It then took time to trap until I started web browsing:)

State clearly in the API that the output format is either:
"2013-02-05 16:32:24.999000" or      
"2013-02-05 16:32:25"
depending on the time returned.


I would also suggest deprecating the now(), __str__ and any method that exhibits this inconsistent multi-format output behavior since everyone after reading the updated comments will switch to another method immediately for simpler/more robust code. 

David Murry, said "Keep in mind that the str is a *convenience* representation.  As such it is *much* more convenient to not print the zero microseconds in the very common case of constructed datetimes that have zero microseconds."  Interesting since currently datetime does print the zeros microseconds in my example: "2013-02-05 16:32:24.999000" (notice the last 3 zeros are microseconds returned/printed by datetime.now()).  Apparently this is inconvenient by your standards was well.  

I'm moving the status back to open for the documentation update and we'll see how anyone feels about the deprecation.

All these little efforts have added up to something great "Python" and I hope these discussion will help further that cause.  I appreciate everyone who has participated.

Thanks,
Dave

----------
resolution: rejected -> 
status: closed -> open
type: enhancement -> behavior

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

From report at bugs.python.org  Wed Feb  6 02:53:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Feb 2013 01:53:32 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360115612.75.0.431264521446.issue17139@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, it is not "it's not broke because there's a workaround", it is not broken because it is *working as designed*.

The str of any object in python is intended to be a convenient representation of that object.  Note that this applies to *all* objects in Python, not just datetime.  (Thus, talking about deprecating __str__ doesn't make any sense.)

The most convenient representation of a datetime has been deemed to be yyyy-mm-dd hh:mm:ss if there microseconds is equal to zero, and yyy-mm-dd hh:mm:ss.MMMMMM if microseconds is not equal to zero, and in practice this has, in general, worked out very well.  It is too bad that Python can't read the programmer's mind and know whether or not zero microseconds are important in a given str call, but sadly it can't, so the above algorithm is the most convenient for the typical uses of str on a datetime.

Now, if you are writing an application and you are doing output that needs to be in a particular format, you should *format your output* to be the way you want it.  This applies to any data, not just datetimes.  It means using a format specification, to which the str of an object might or might not be an input.  In the case of datetime, you don't want to use its str as the input to the format, because that can loose information, as you have discovered.  Instead you want to specify an strftime format string that causes the data to be displayed *exactly as you want it to be*:

    >>> counter1 = 23360
    >>> x = datetime.datetime(2013, 2, 5, 20, 45)
    >>> x
    datetime.datetime(2013, 2, 5, 20, 45)
    >>> str(x)
    '2013-02-05 20:45:00'
    >>> "counter1 is: {:6d} time is: {:%Y-%m-%d %H:%M:%S.%f}".format(counter1, x)
    'counter 1 is:  23360 time is: 2013-02-05 20:45:00.000000'

str is a generic function that is a convenience.  A format specification is, well, *specific* to a particular application.  Note how it is necessary to also use a format for the counter in order to obtain output records with consistent spacing.

Now, as far as documentation goes, __str__ references isoformat, and isoformat says:

    datetime.isoformat(sep='T')

        Return a string representing the date and time in ISO 8601 format,
        YYYY-MM-DDTHH:MM:SS.mmmmmm or, if microsecond is 0,
        YYYY-MM-DDTHH:MM:SS

It is hard to see how the documentation can get clearer than that.  

(As an aside, I *can* see the argument, as was made in the other issue, that the isoformat method should provide a way to control the micorseconds display.  That would be a feature request, but given the history of this issue you should probably raise it on the python-ideas mailing list first in order to get buy-in before opening a new request for enhancement for it.  Not optimal, I know, but sometimes you have to deal with history when suggesting/requesting a change in a project.

Also note that datetime.now() does not have *any* format.  It is a datetime object.  Only when turning it in to a string by some method does formatting come in to play.

I want to thank you for your enthusiasm for making things better.  I hope that my more detailed explanation will help you understand the reasoning behind the design decisions that have been made here.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  6 03:08:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Feb 2013 02:08:05 +0000
Subject: [issue17140] Provide a more obvious public ThreadPool API
Message-ID: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The multiprocessing module currently provides the "multiprocessing.dummy.ThreadPool" API that exposes the same API as the public multiprocessing.Pool, but is implemented with threads rather than processes. (This is sort of documented - it's existence is implied by the documentation of multiprocessing.dummy, but it doesn't spell out "hey, stdlib ThreadPool implementation!".

Given that this feature is likely useful to many people for parallelising IO bound tasks without migrating to the concurrent.futures API (or where that API doesn't quite fit the use case), it makes sense to make it a more clearly documented feature under a less surprising name.

I haven't looked at the implementation, so I'm not sure how easy it will be to migrate it to a different module, but threading seems like a logical choice given the multiprocessing.ThreadPool vs threading.ThreadPool parallel.

(Honestly, I'd be happier if we moved queue.Queue to threading as well. Having a threading specific data type as a top level module in its own right just makes it harder for people to find for no real reason other than a historical accident)

Alternatively, we could add a "concurrent.pool" module which was little more than:

from multiprocessing import Pool as ProcessPool
from multiprocessing.dummy import ThreadPool

----------
components: Library (Lib)
messages: 181495
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide a more obvious public ThreadPool API
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  6 03:12:23 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 06 Feb 2013 02:12:23 +0000
Subject: [issue16203] Proposal: add re.fullmatch() method
In-Reply-To: <1349991042.0.0.875123830426.issue16203@psf.upfronthosting.co.za>
Message-ID: <1360116743.29.0.700347029261.issue16203@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

3 of the tests expect None when using 'fullmatch'; they won't return None when using 'match'.

----------

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

From report at bugs.python.org  Wed Feb  6 05:48:03 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 06 Feb 2013 04:48:03 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1360126083.73.0.759772349039.issue16801@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Georg: what other functions do you know of where (as you suggest) the signature could be improved?

----------

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

From report at bugs.python.org  Wed Feb  6 06:02:22 2013
From: report at bugs.python.org (Amir Szekely)
Date: Wed, 06 Feb 2013 05:02:22 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360126942.24.0.337834944038.issue16800@psf.upfronthosting.co.za>


Amir Szekely added the comment:

I've submitted a contribution form by e-mail.

----------

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

From report at bugs.python.org  Wed Feb  6 08:52:31 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 06 Feb 2013 07:52:31 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360137151.57.0.657971753614.issue17136@psf.upfronthosting.co.za>


Dirkjan Ochtman added the comment:

Thanks, I've filed https://github.com/atgreen/libffi/issues/29.

----------

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

From report at bugs.python.org  Wed Feb  6 09:01:49 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 06 Feb 2013 08:01:49 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360137709.23.0.126119999918.issue17136@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I don't know how the main copy of libffi in the CPython tree is updated, and if it is a straight copy of the upstream release. Given the mercurial log I'd guess that Modules/_ctypes/libffi is libffi 3.0.11 with a small patch in Modules/_ctypes/libffi.diff.

As Arfrever notes libffi_osx is used on OSX only, and that version is a fork of libffi shared with PyObjC (that is, I try to update the copy in the CPython tree whenever I have to update the copy for PyObjC). 

I agree that the issue with libffi should be fixed upstream first,  otherwise it would get harder and harder to import new upstream versions.

----------
nosy: +doko

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

From report at bugs.python.org  Wed Feb  6 09:10:44 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 06 Feb 2013 08:10:44 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360138244.09.0.399087999775.issue17136@psf.upfronthosting.co.za>


Dirkjan Ochtman added the comment:

Is there a particular reason for not upstreaming the PyObjC changes?

----------

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

From report at bugs.python.org  Wed Feb  6 09:38:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Feb 2013 08:38:53 +0000
Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates
	prematurely
In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za>
Message-ID: <3Z1GK86kjPzSPv@mail.python.org>


Roundup Robot added the comment:

New changeset 6cc5bbfcf04e by Serhiy Storchaka in branch '3.2':
Issue #16723: httplib.HTTPResponse no longer marked closed when the connection
http://hg.python.org/cpython/rev/6cc5bbfcf04e

New changeset 0461ed77ee4e by Serhiy Storchaka in branch '3.3':
Issue #16723: httplib.HTTPResponse no longer marked closed when the connection
http://hg.python.org/cpython/rev/0461ed77ee4e

New changeset 5f8c68281d18 by Serhiy Storchaka in branch 'default':
Issue #16723: httplib.HTTPResponse no longer marked closed when the connection
http://hg.python.org/cpython/rev/5f8c68281d18

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Feb  6 09:41:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 08:41:36 +0000
Subject: [issue17122] Fix and cleanup test_functools
In-Reply-To: <1359980964.91.0.854026651157.issue17122@psf.upfronthosting.co.za>
Message-ID: <1360140096.88.0.874273643635.issue17122@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  6 09:42:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 08:42:36 +0000
Subject: [issue16723] io.TextIOWrapper on urllib.request.urlopen terminates
	prematurely
In-Reply-To: <1355899334.66.0.683261774989.issue16723@psf.upfronthosting.co.za>
Message-ID: <1360140156.3.0.389537170004.issue16723@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  6 09:54:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 08:54:33 +0000
Subject: [issue13541] HTTPResponse (urllib) has no attribute read1 needed for
	TextIOWrapper
In-Reply-To: <1323189899.67.0.308842457665.issue13541@psf.upfronthosting.co.za>
Message-ID: <1360140873.33.0.671403003066.issue13541@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue12591 added support of raw streams without read1() in io.TextIOWrapper().

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  6 10:04:59 2013
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Feb 2013 09:04:59 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1360141499.61.0.0800895804878.issue16801@psf.upfronthosting.co.za>


Georg Brandl added the comment:

For example, any function where an argument has a "sentinel" object as the default value, such as socket.create_connection().

----------

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

From report at bugs.python.org  Wed Feb  6 10:14:19 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Feb 2013 09:14:19 +0000
Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate
In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za>
Message-ID: <1360142059.75.0.403998413959.issue17037@psf.upfronthosting.co.za>


Eric Snow added the comment:

Any objections to what Brett proposed?  Any preferences on a name?  How about DualImplementationTests?  Here's a patch with tests.

I added a pure_python_only() decorator in addition to accelerated_only().  I also made both work as decorators for classes and methods (just like unittest.skip()).

Finally, I added on a with_module_exported() decorator to help with the scenario from issue #16817.  Eli, I know it doesn't quite fill the gap you described in msg180669, but hopefully it's an improvement.

----------
Added file: http://bugs.python.org/file28973/dual-impl-tests.diff

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

From report at bugs.python.org  Wed Feb  6 10:35:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 09:35:17 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1360143317.22.0.883098429059.issue8194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Should this issue be closed?

----------
nosy: +serhiy.storchaka
status: open -> pending

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

From report at bugs.python.org  Wed Feb  6 10:37:33 2013
From: report at bugs.python.org (=?utf-8?q?Mikl=C3=B3s_Fazekas?=)
Date: Wed, 06 Feb 2013 09:37:33 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1360143453.16.0.386539193829.issue7897@psf.upfronthosting.co.za>


Mikl?s Fazekas added the comment:

http://gist.github.com/mfazekas/1710455

I have a parametric delclarator which works is similiar to sweepargs in concept. It can be either applied at class or method level. And it mutates testnames so failure should be nice, and filters can be applied too.

@parametric
class MyTest(unittest.TestCase):
    @parametric(foo=[1,2],bar=[3,4])
    def testWithParams(self,foo,bar):
        self.assertLess(foo,bar)
    def testNormal(self):
        self.assertEqual('foo','foo')

@parametric(foo=[1,2],bar=[3,4])
class MyTest(unittest.TestCase):
     def testPositive(self,foo,bar):
         self.assertLess(foo,bar)
     def testNegative(self,foo,bar):
         self.assertLess(-foo,-bar)

Sample failures:
======================================================================
FAIL: testNegative_bar_3_foo_1 (__main__.MyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Work/temp/parametric.py", line 63, in f
    self.fun(*args,**v)
  File "/Work/temp/parametric.py", line 158, in testNegative
    self.assertLess(-foo,-bar)
AssertionError: -1 not less than -3

======================================================================
FAIL: testNegative_bar_3_foo_2 (__main__.MyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Work/temp/parametric.py", line 63, in f
    self.fun(*args,**v)
  File "/Work/temp/parametric.py", line 158, in testNegative
    self.assertLess(-foo,-bar)
AssertionError: -2 not less than -3

----------
nosy: +Mikl?s.Fazekas

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

From report at bugs.python.org  Wed Feb  6 10:44:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 09:44:39 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1360143879.82.0.418996876451.issue11311@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +IO
keywords: +easy
nosy: +serhiy.storchaka
stage:  -> needs patch

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

From report at bugs.python.org  Wed Feb  6 11:09:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 10:09:21 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1360145361.12.0.284896485583.issue6532@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Wed Feb  6 11:19:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 10:19:22 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360145962.18.0.225877369832.issue5308@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 11:32:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 10:32:25 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360146745.64.0.67757793625.issue12596@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
stage:  -> needs patch

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

From report at bugs.python.org  Wed Feb  6 11:36:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 10:36:52 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360147012.64.0.0937295866363.issue13355@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy
nosy: +serhiy.storchaka
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 13:17:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Feb 2013 12:17:12 +0000
Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate
In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za>
Message-ID: <1360153032.0.0.428892259279.issue17037@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm still a bit skeptic about this.

To summarize my position, I am:
+0 about adding something like this to test.support and use it for new tests;
-1 about mass-rewriting the existing tests to use this (in particular for test_json);
+1 about simplifying the API of import_fresh_module so that it returns both the modules and doesn't require the fresh/blocked args;

----------

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

From report at bugs.python.org  Wed Feb  6 13:24:45 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Wed, 06 Feb 2013 12:24:45 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360153485.13.0.651793958142.issue17137@psf.upfronthosting.co.za>


Jan Lachnitt added the comment:

Here is a part of my code (with some comments added):

    for struct in ini_structures:
        dirname = wrkdir+os.sep+struct.name
        if not os.path.isdir(dirname):  # This works fine. If the directory doesn't exist,...
            try:
                os.mkdir(dirname)       # ... it is created here.
            except OSError:
                raise AutoLEEDError('Cannot create directory "'+dirname+'".')
        dirname += os.sep+'bulk'        # This defines a subdirectory.
        if not os.path.isdir(dirname): ## Though it doesn't exist, os.path.isdir returns True,...
            try:
                os.mkdir(dirname)       # ... so it is not created here.
            except OSError:
                raise AutoLEEDError('Cannot create directory "'+dirname+'".')
        fn = dirname+os.sep+'cluster.i' # This defines a filename.
        print('Writing file "'+fn+'"...')
        straos = struct.write_bulk_cluster(fn,at_rad) # Here it fails (cannot write to file).

According to Victor's post, I have inserted these lines before the line marked ## (and added necessary imports):

        print('dirname =', dirname)
        print('os.path.isdir(dirname) =', os.path.isdir(dirname))
        print('nt._isdir(dirname) =', nt._isdir(dirname))
        print('stat.S_ISDIR(os.stat(dirname).st_mode) =', stat.S_ISDIR(os.stat(dirname).st_mode))
        print(ascii(dirname.encode("unicode_internal")))
        print(ascii(dirname.encode("utf-8")))

Here is the output of these lines (that directory really does not exist but its parent directory does):

dirname = D:\Bug reports\Python\AutoLEED\default\sub-fcc\bulk
os.path.isdir(dirname) = True
nt._isdir(dirname) = True
stat.S_ISDIR(os.stat(dirname).st_mode) = True
b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00A\x00u\x00t\x00o\x00L\x00E\x00E\x00D\x00\\\x00d\x00e\x00f\x00a\x00u\x00l\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00\x00\x002\x00\x03\x00\x00\x00\x00\x00'
b'D:\\Bug reports\\Python\\AutoLEED\\default\\sub-fcc\\bulk'

Yeah, the result of ascii(dirname.encode("unicode_internal")) seems to be wrong (at the end).

----------

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

From report at bugs.python.org  Wed Feb  6 13:29:00 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Feb 2013 12:29:00 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360153740.74.0.0729582781459.issue17136@psf.upfronthosting.co.za>


Matthias Klose added the comment:

I'm planning to update the tip to the next libffi release candidate once it's released. 

Once this is checked in, maybe revisit the extra copy for OS X; an ABI issue with llvm/clang was identified in
http://sourceware.org/ml/libffi-discuss/2013/msg00012.html

and a work-around provided in
http://sourceware.org/ml/libffi-discuss/2013/msg00021.html

----------

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

From report at bugs.python.org  Wed Feb  6 13:38:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 12:38:01 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
Message-ID: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

random.vonmisesvariate(0, 1e16) hangs.

----------
components: Library (Lib)
messages: 181511
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: random.vonmisesvariate() hangs for large kappa
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb  6 13:44:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 12:44:17 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360154657.12.0.74773170379.issue13355@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------

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

From report at bugs.python.org  Wed Feb  6 13:45:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 12:45:07 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360154707.43.0.430267875106.issue13355@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  6 13:53:09 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 06 Feb 2013 12:53:09 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360155189.98.0.799674363982.issue17136@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Matthias: libffi_osx already contains the workaround you refer to.

libffi_osx is the same as the variant of libffi included with PyObjC, and that is derived from the system libffi on OSX (IIRC the last time I merged their changes was around 10.7). 

The system libffi on OSX is a fork of the upstream one, at least partially because upstream didn't support darwin/i386 at the time of the fork.

----------

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

From report at bugs.python.org  Wed Feb  6 13:56:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 12:56:29 +0000
Subject: [issue14012] Misc tarfile fixes
In-Reply-To: <1329235837.42.0.144867770777.issue14012@psf.upfronthosting.co.za>
Message-ID: <1360155389.16.0.933641568929.issue14012@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is desynchronized from current sources.

----------
nosy: +serhiy.storchaka
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 14:19:18 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 06 Feb 2013 13:19:18 +0000
Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate
In-Reply-To: <1360153032.0.0.428892259279.issue17037@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda_kVDdGXN-uEqbQ2RXCE6sJuXuMLWFO6Jcb_gXvwXSGFQ@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Feb 6, 2013 at 4:17 AM, Ezio Melotti <report at bugs.python.org> wrote:

>
> Ezio Melotti added the comment:
>
> I'm still a bit skeptic about this.
>
> To summarize my position, I am:
> +0 about adding something like this to test.support and use it for new
> tests;
> -1 about mass-rewriting the existing tests to use this (in particular for
> test_json);
> +1 about simplifying the API of import_fresh_module so that it returns
> both the modules and doesn't require the fresh/blocked args;
>

I share Ezio's sentiment regarding the new proposal(s). As for
import_fresh_module, if it's only ever used to do what we describe here,
then I propose to rename it to something more descriptive and indeed make
it just return both modules. If it's being used for other stuff, we can add
another function and rewrite all the tests to use that.

py_module, c_module = import_python_module_and_accelerator('module',
'_module')

----------

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

From report at bugs.python.org  Wed Feb  6 14:19:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Feb 2013 13:19:36 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360153485.13.0.651793958142.issue17137@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb2_ghgOERa_2rj7KtRZWcKUTNPCmodd=u1y8dd66VGFg@mail.gmail.com>


STINNER Victor added the comment:

I'm interested by your struct.name string: can you also dump it? Where
does it come from? Does it use ctypes?

 * print(ascii(struct.name))
 * print(ascii(struct.name.encode("unicode_internal")))
 * print(ascii(struct.name.encode("utf-8")))

I'm interested by all variables used to build the final path.

nt._isdir() doesn't check if the path contains a NUL character. It
should: see aksi #13617

> b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00A\x00u\x00t\x00o\x00L\x00E\x00E\x00D\x00\\\x00d\x00e\x00f\x00a\x00u\x00l\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00\x00\x002\x00\x03\x00\x00\x00\x00\x00'

Decoded from UTF-16-LE, it gives:
'D:\\Bug reports\\Python\\AutoLEED\\default\\sub-fcc\x002\x03\x00\x00'

> b'D:\\Bug reports\\Python\\AutoLEED\\default\\sub-fcc\\bulk'

Decode from UTF-8, it gives:
'D:\\Bug reports\\Python\\AutoLEED\\default\\sub-fcc\\bulk'

It looks like the wstr representation of the string is corrupted.

----------

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

From report at bugs.python.org  Wed Feb  6 14:21:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 13:21:27 +0000
Subject: [issue13234] os.listdir breaks with literal paths
In-Reply-To: <1319129686.22.0.325584161741.issue13234@psf.upfronthosting.co.za>
Message-ID: <1360156887.72.0.727905191816.issue13234@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I added minor comments in Rietveld.

Santoso Wijaya, can you please submit a contributor form?

http://python.org/psf/contrib/contrib-form/
http://python.org/psf/contrib/

----------
nosy: +serhiy.storchaka
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 14:23:20 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Feb 2013 13:23:20 +0000
Subject: [issue3871] cross and native build of python for mingw* hosts
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1360157000.26.0.690191456425.issue3871@psf.upfronthosting.co.za>


Matthias Klose added the comment:

> Ray Donnelly added the comment:
> Next time there's a release of Python 3, I'll rebase my patches against that.

sorry, this is the wrong attitude, if you want mingw support to go upstream. fetch tip/trunk, re-apply your patches, and submit them.

----------
components: +Cross-Build -Build

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

From report at bugs.python.org  Wed Feb  6 14:24:26 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Feb 2013 13:24:26 +0000
Subject: [issue3871] cross and native build of python for mingw* hosts
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1360157066.71.0.613706009018.issue3871@psf.upfronthosting.co.za>


Matthias Klose added the comment:

now closing/rejecting this issue. See
http://mail.python.org/pipermail/python-dev/2013-January/123774.html
for the discussion.

----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  6 14:27:50 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Feb 2013 13:27:50 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1360157270.05.0.768582463736.issue3754@psf.upfronthosting.co.za>


Matthias Klose added the comment:

See http://mail.python.org/pipermail/python-dev/2013-January/123774.html
for the discussion.

Not updating the patches for tip/trunk is the best way to keep them out of the project.

----------

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

From report at bugs.python.org  Wed Feb  6 14:29:26 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Feb 2013 13:29:26 +0000
Subject: [issue16526] Python does not cross compile properly
In-Reply-To: <1353535083.98.0.533437922947.issue16526@psf.upfronthosting.co.za>
Message-ID: <1360157366.82.0.44198705511.issue16526@psf.upfronthosting.co.za>


Matthias Klose added the comment:

now closing/rejecting this issue. See
http://mail.python.org/pipermail/python-dev/2013-January/123774.html
for the discussion.

----------
nosy: +doko

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

From report at bugs.python.org  Wed Feb  6 14:29:58 2013
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 06 Feb 2013 13:29:58 +0000
Subject: [issue16526] Python does not cross compile properly
In-Reply-To: <1353535083.98.0.533437922947.issue16526@psf.upfronthosting.co.za>
Message-ID: <1360157398.09.0.72435223579.issue16526@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  6 14:30:12 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 13:30:12 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360157412.47.0.477151887585.issue13355@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Here is a patch.

Where?  :-)

----------

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

From report at bugs.python.org  Wed Feb  6 14:37:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 13:37:11 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1360157831.79.0.266537989258.issue11311@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a very simple patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28974/StringIO_readline0.patch

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

From report at bugs.python.org  Wed Feb  6 15:15:52 2013
From: report at bugs.python.org (Sjoerd Langkemper)
Date: Wed, 06 Feb 2013 14:15:52 +0000
Subject: [issue17142] test_any calls all() instead of any()
Message-ID: <1360160152.63.0.655571539572.issue17142@psf.upfronthosting.co.za>


New submission from Sjoerd Langkemper:

In test_builtin.py, on the fourth in the test_any() function:

self.assertRaises(RuntimeError, all, TestFailingIter())

I think this should be:

self.assertRaises(RuntimeError, any, TestFailingIter())

----------
components: Tests
messages: 181524
nosy: sjoerder
priority: normal
severity: normal
status: open
title: test_any calls all() instead of any()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb  6 15:21:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Feb 2013 14:21:26 +0000
Subject: [issue17142] test_any calls all() instead of any()
In-Reply-To: <1360160152.63.0.655571539572.issue17142@psf.upfronthosting.co.za>
Message-ID: <1360160486.9.0.617690685216.issue17142@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/issue17142>
_______________________________________

From report at bugs.python.org  Wed Feb  6 15:27:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 14:27:23 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360160843.9.0.997775280975.issue13355@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Now it is here.

----------
Added file: http://bugs.python.org/file28975/random_triangular.patch

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

From report at bugs.python.org  Wed Feb  6 15:38:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 14:38:16 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1360161496.21.0.753418238911.issue6532@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch, which made all thread id to be unsigned.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28976/thread_id_unsigned.patch

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

From report at bugs.python.org  Wed Feb  6 16:00:49 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 15:00:49 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360162849.65.0.0797509008041.issue13355@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Looks fine to me.  Raymond: can this be applied?

----------

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

From report at bugs.python.org  Wed Feb  6 16:02:54 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 15:02:54 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360162974.12.0.266289965898.issue13355@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

One minor comment: I'd prefer it if the second test were "elif low == high:", since that more obviously guards against the division by zero.

----------

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

From report at bugs.python.org  Wed Feb  6 16:06:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Feb 2013 15:06:26 +0000
Subject: [issue17142] test_any calls all() instead of any()
In-Reply-To: <1360160152.63.0.655571539572.issue17142@psf.upfronthosting.co.za>
Message-ID: <3Z1QwK2PbqzNNy@mail.python.org>


Roundup Robot added the comment:

New changeset 1fc87fa05333 by R David Murray in branch '3.2':
#17142: fix apparent copy and paste error in test_all.
http://hg.python.org/cpython/rev/1fc87fa05333

New changeset 4db932a303b4 by R David Murray in branch '3.3':
Merge: #17142: fix apparent copy and paste error in test_all.
http://hg.python.org/cpython/rev/4db932a303b4

New changeset acdb0da0df2b by R David Murray in branch 'default':
Merge: #17142: fix apparent copy and paste error in test_all.
http://hg.python.org/cpython/rev/acdb0da0df2b

New changeset d0cfabed2ef3 by R David Murray in branch '2.7':
#17142: fix apparent copy and paste error in test_all.
http://hg.python.org/cpython/rev/d0cfabed2ef3

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Feb  6 16:07:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Feb 2013 15:07:50 +0000
Subject: [issue17142] test_any calls all() instead of any()
In-Reply-To: <1360160152.63.0.655571539572.issue17142@psf.upfronthosting.co.za>
Message-ID: <1360163270.61.0.167020589782.issue17142@psf.upfronthosting.co.za>


R. David Murray added the comment:

Good catch, thanks.  A copy and paste error, I suppose.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: enhancement -> behavior
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Wed Feb  6 16:12:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 15:12:53 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360163573.33.0.393039142006.issue17141@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/issue17141>
_______________________________________

From report at bugs.python.org  Wed Feb  6 16:14:41 2013
From: report at bugs.python.org (Dmitry Jemerov)
Date: Wed, 06 Feb 2013 15:14:41 +0000
Subject: [issue17143] trace.py uses _warn without importing it
Message-ID: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>


New submission from Dmitry Jemerov:

trace.py in Python 3.3 standard library uses the _warn function without importing it. As a result, an attempt to use a now-deprecated function fails with a NameError:

> python3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import trace
>>> trace.modname('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/trace.py", line 827, in modname
    _warn("The trace.modname() function is deprecated",
NameError: global name '_warn' is not defined

----------
components: Library (Lib)
messages: 181531
nosy: Dmitry.Jemerov
priority: normal
severity: normal
status: open
title: trace.py uses _warn without importing it
versions: Python 3.3

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

From report at bugs.python.org  Wed Feb  6 16:37:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 15:37:42 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1360162974.12.0.266289965898.issue13355@psf.upfronthosting.co.za>
Message-ID: <201302061737.25536.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> One minor comment: I'd prefer it if the second test were "elif low ==
> high:", since that more obviously guards against the division by zero.

It is written deliberately. What if low == high != mode?

----------

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

From report at bugs.python.org  Wed Feb  6 16:45:51 2013
From: report at bugs.python.org (Dmitry Jemerov)
Date: Wed, 06 Feb 2013 15:45:51 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360165551.77.0.901053114568.issue17143@psf.upfronthosting.co.za>


Dmitry Jemerov added the comment:

Workaround: "import warnings; trace._warn = warnings.warn" after importing trace

----------

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

From report at bugs.python.org  Wed Feb  6 16:48:05 2013
From: report at bugs.python.org (Dave)
Date: Wed, 06 Feb 2013 15:48:05 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360165685.1.0.789319557054.issue17139@psf.upfronthosting.co.za>


Dave added the comment:

Thanks for the reply, STINNER Victor reply makes more sense in hindsight.  Legacy often rules and we can work with/around things knowing it's full behavior.  

Since this is not documented for datetime.now()(where this issue began), can we add comments something like what was done for __str__, so the two possible output formats are documented? 

Thanks,
Dave

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

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

From report at bugs.python.org  Wed Feb  6 16:51:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 15:51:10 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360165870.93.0.226323884399.issue5308@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 3.x which adds checks for size overflow (only on 64-bit platform).

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file28977/marshal_overflow.patch

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

From report at bugs.python.org  Wed Feb  6 16:52:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 15:52:09 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360165929.93.0.672519191544.issue5308@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And here is a patch for 2.7.

----------
Added file: http://bugs.python.org/file28978/marshal_overflow-2.7.patch

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

From report at bugs.python.org  Wed Feb  6 16:56:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 15:56:03 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360166163.91.0.567019045529.issue5308@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> (And as a matter of principle, 
> INT_MAX isn't really right here: an int might be only 16 bits long on 
>?some strange platforms...).

AFAIK?Python doesn't support such platforms (and C?standard requites at least 32-bit ints). However there are strange platforms with 64-bit ints. That's why I used the explicit constant 0x7FFFFFFF.

----------

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

From report at bugs.python.org  Wed Feb  6 17:07:37 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Wed, 06 Feb 2013 16:07:37 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360166857.59.0.98368717487.issue17137@psf.upfronthosting.co.za>


Jan Lachnitt added the comment:

print(ascii(struct.name))
        print(ascii(struct.name.encode("unicode_internal")))
        print(ascii(struct.name.encode("utf-8")))

produces:

'sub-fcc'
b's\x00u\x00b\x00-\x00f\x00c\x00c\x00'
b'sub-fcc'

and that looks correct.

struct.name originally comes from an ini-file:

    cp = configparser.ConfigParser(interpolation=None)
    try:
        cp.read(filename)
    ...

The ini-file is encoded in pure ASCII (while my Python sources are in UTF-8 with the identification bytes at the beginning of the file). struct.name is the name of a section in this file, as provided by cp.sections() . The name gets through several objects. I am not pasting all the relevant code pieces here because there are too many relevant pieces but they do nothing special (just passing and copying the name). I do not use ctypes.

wrkdir is generated from inp_file_name, which is 'default.ini', by this statement:

    wrkdir = os.path.splitext(os.path.abspath(inp_file_name))[0]

BTW, ascii(dirname.encode("unicode_internal")) result is different in this run:

b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00A\x00u\x00t\x00o\x00L\x00E\x00E\x00D\x00\\\x00d\x00e\x00f\x00a\x00u\x00l\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

----------

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

From report at bugs.python.org  Wed Feb  6 17:09:33 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 16:09:33 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360166973.02.0.713511209662.issue13355@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> What if low == high != mode?

Then we've got garbage in, garbage out;  that case doesn't worry me.

----------

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

From report at bugs.python.org  Wed Feb  6 17:10:32 2013
From: report at bugs.python.org (Danilo Bargen)
Date: Wed, 06 Feb 2013 16:10:32 +0000
Subject: [issue17144] Distutils: "sdist register upload" ignores -r argument
Message-ID: <1360167032.54.0.0794749413911.issue17144@psf.upfronthosting.co.za>


New submission from Danilo Bargen:

Where I work, we use a custom pypi server to upload our internal packages.

With a package that has a setup.py created using setuptools, I can simply issue:

$ python setup.py sdist register upload -r local

...and it will get registered and uploaded to our local server.

If setup.py is using distutils though, this does not work and the -r argument gets ignored. The command above would register and upload the package to pypi.python.org (which can in some situations be a security problem).

As a workaround, this works:

$ python setup.py register -r local
$ python setup.py sdist upload -r local

Tested under Python 2.7...

----------
assignee: eric.araujo
components: Distutils
messages: 181540
nosy: eric.araujo, gwrtheyrn, tarek
priority: normal
severity: normal
status: open
title: Distutils: "sdist register upload" ignores -r argument
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  6 18:12:34 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 06 Feb 2013 17:12:34 +0000
Subject: [issue17145] memoryview(array.array)
Message-ID: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>


New submission from Demian Brecht:

array.array doesn't implement the buffer interface in 2.7, so memoryviews cannot be applied to them. As memoryview has been backported to 2.7, array.array should be updated to support it. Either that, or the 2.7 documentation should be updated to reflect the lack of support for arrays in 2.7 (http://docs.python.org/2.7/c-api/buffer.html).

python3
>>> memoryview(array('I', [1,2,3,4]))
<memory at 0x109e46048>

python
>>> memoryview(array('I', [1,2,3,4]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface

----------
components: None
messages: 181541
nosy: Demian.Brecht
priority: normal
severity: normal
status: open
title: memoryview(array.array)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Feb  6 18:36:45 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 06 Feb 2013 17:36:45 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360172205.8.0.808007529027.issue17143@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Patch attached with tests.

----------
keywords: +patch
nosy: +berker.peksag
Added file: http://bugs.python.org/file28979/issue17143.diff

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

From report at bugs.python.org  Wed Feb  6 18:40:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 17:40:20 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1360172420.05.0.0864902537493.issue10355@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which implements properties for which it has a sense and remove if there is no sense.

----------
assignee:  -> serhiy.storchaka
components: +Library (Lib)
keywords: +patch
nosy: +ncoghlan, serhiy.storchaka
stage: needs patch -> patch review
versions: +Python 3.3, Python 3.4 -Python 3.1
Added file: http://bugs.python.org/file28980/SpooledTemporaryFile_properties.patch

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

From report at bugs.python.org  Wed Feb  6 18:41:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 17:41:06 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1360172466.51.0.802592575195.issue10355@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file28981/SpooledTemporaryFile_properties-2.7.patch

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

From report at bugs.python.org  Wed Feb  6 18:48:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 17:48:52 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1360166973.02.0.713511209662.issue13355@psf.upfronthosting.co.za>
Message-ID: <201302061948.35979.storchaka@gmail.com>


Serhiy Storchaka added the comment:

An exception is better than a garbage result. But I agree, triangular() 
currently is not protectet against a situation when mode is not in low--high 
range.

----------

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

From report at bugs.python.org  Wed Feb  6 18:53:28 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Feb 2013 17:53:28 +0000
Subject: [issue17146] Improve test.support.import_fresh_module()
Message-ID: <1360173207.93.0.545038003831.issue17146@psf.upfronthosting.co.za>


New submission from Eric Snow:

(+nosy list from #17037)

In issue 17037 (related to hiding PEP 399 boilerplate), Ezio and Eli recommended improving on the API of import_fresh_module().  I agree that it could be simplified, wrapped, or otherwise improved.

import_fresh_module() is used in the stdlib tests a number of times, primarily to support testing dual-implementations a la PEP 399 (see msg180809).  However, since it is already used for testing at least once module for a non-PEP-399 case (test_bz2), we need to be careful about any changes we'd make.  Changing test_bz2 to not use import_fresh_module() just so we could make it PEP-399 specific doesn't seem right.

Of the test modules that use import_fresh_module(), several pass multiple names for "fresh" and none pass more than one for "blocked".  Presumably a Python module may be accelerated by more than one accelerator module, hence allowing for lists for the two parameters, but none do so *now*.

Consequently, it may be worth doing something like what Eli suggested in msg181515: add another helper function that *is* PEP-399-specific.  Something like this:

def import_pure_and_accelerated_modules(name, *, fresh=(),
                                        accelerated_fresh=None,
                                        accelerators=None):
    if accelerators is None:
        accelerators = ['_' + name]
    if accelerated_fresh is None:
        accelerated_fresh = list(fresh) + list(accelerators)
    py_module = import_fresh_module(name, fresh=fresh, blocked=accelerators)
    acc_module = import_fresh_module(name, fresh=accelerated_fresh)
    return py_module, acc_module

Then you could use it like this:
    
py_module, c_module = import_pure_and_accelerated_modules('module')
py_module, c_module = import_pure_and_accelerated_modules('module', accelerators=['_other'])

Simply refactoring import_fresh_module() to work this way is an option, especially since it is used almost exclusively for PEP 399 compliance.  That way test.support would not grow yet another function.  The new interface would probably look like this:

def import_fresh_module(name, *, fresh=(), accelerated_fresh=None,
                        accelerators=None, blocked=None, deprecated=False):

It would still return a 2-tuple, but the second module would be None.  For the test_bz2 case, the change would be minimal:

bz2, = support.import_fresh_module("bz2", blocked=("threading",))

Why go to all this trouble?  It saves just one line of code.  Well, it also helps with writing and maintenance of dual-implementation tests, which I expect will be a growing segment of the stdlib unit tests as time goes by.

However, ultimately the point it moot if we have a more comprehensive test helper like what's being discussed in issue 17037.

----------
components: Library (Lib)
messages: 181545
nosy: Arfrever, brett.cannon, eli.bendersky, eric.snow, ezio.melotti, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve test.support.import_fresh_module()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Feb  6 18:55:11 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2013 17:55:11 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360173311.88.0.358159783885.issue16038@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thank you very much!

Have you read and checked what the RFCs about the FTP protocol say about  maximum line length?

----------

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

From report at bugs.python.org  Wed Feb  6 19:03:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 18:03:13 +0000
Subject: [issue11714] threading.Semaphore does not use try...finally
In-Reply-To: <1301429285.55.0.524593153571.issue11714@psf.upfronthosting.co.za>
Message-ID: <1360173793.92.0.123580927609.issue11714@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. 3.x patch a little desynchronized but it is easy to update it. I'll commit it if Antoine have no objections.

Thomas Rachel, can you please submit a contributor form?

http://python.org/psf/contrib/contrib-form/
http://python.org/psf/contrib/

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> commit review
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 19:07:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Feb 2013 18:07:53 +0000
Subject: [issue6532] thread.get_ident() should return unsigned value
In-Reply-To: <1248186325.01.0.817161707988.issue6532@psf.upfronthosting.co.za>
Message-ID: <1360174073.33.0.836122931.issue6532@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You could add a test for it.

----------

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

From report at bugs.python.org  Wed Feb  6 19:09:17 2013
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=)
Date: Wed, 06 Feb 2013 18:09:17 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360174157.6.0.733933935594.issue16038@psf.upfronthosting.co.za>


Micha? Jastrz?bski added the comment:

Well its my understanding, that there is no maximum length specified in RFC959. There is however option to set it up while telnet connection, and that would be other solution to this issue.

----------

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

From report at bugs.python.org  Wed Feb  6 19:14:37 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Feb 2013 18:14:37 +0000
Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate
In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za>
Message-ID: <1360174477.58.0.0933426069985.issue17037@psf.upfronthosting.co.za>


Eric Snow added the comment:

First of all, I agree that the API for import_fresh_module() isn't ideal and could stand some improvement.  I've created issue 17146 for pursuing that avenue.

More importantly for this issue, simplifying import_fresh_module() is not nearly enough of a win for me regarding PEP 399.  My big motivator here was to make complying with PEP 399 much easier.  That encompasses more than eliminating the extra call to import_fresh_module().

There are a number of considerations that I've already outlined, which especially relate to maintenance and writing new dual-implementation tests.  Without a comprehensive helper, existing tests don't automatically benefit from a better way of doing it (or fixes); converting existing tests to dual-implementation isn't as simple; and when someone goes to write new dual-implementation tests they have to do all the boilerplate and cover the corner cases (e.g. pickle-related tests).

I'm coming at this from the perspective of someone who hadn't already written or adjusted tests to accommodate PEP 399.  Having a more comprehensive helper would have saved me the time to figure it out, which I count as somewhat wasted since it's just boilerplate.  I'd rather be working on the tests and the code that I'm testing.  I'd rather not ask anyone else to take the time to get familiar with the boilerplate when I'm sure they'd rather be working on their problem than shaving this yak. :)

For the record, I'm glad we have PEP 399 and that we are making the effort to get more pure Python modules in the stdlib.  A big thanks to Brett for continuing to push for this!

Ezio, I'm on board with your summary, though I'm +1 on adding the helper. :)  I didn't have any plans to refactor any tests, but I would like to use any helper that might come out of this discussion in my testing of OrderedDict.

----------

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

From report at bugs.python.org  Wed Feb  6 19:16:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 18:16:37 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1360174597.6.0.0432969008188.issue11763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I left comments on Rietveld. Tests needed.

----------
nosy: +serhiy.storchaka
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 19:17:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 18:17:53 +0000
Subject: [issue11640] Shelve references globals in its __del__ method
In-Reply-To: <1300832144.38.0.133902930927.issue11640@psf.upfronthosting.co.za>
Message-ID: <1360174673.71.0.980044671496.issue11640@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb  6 19:27:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Feb 2013 18:27:15 +0000
Subject: [issue16203] Proposal: add re.fullmatch() method
In-Reply-To: <1349991042.0.0.875123830426.issue16203@psf.upfronthosting.co.za>
Message-ID: <1360175235.67.0.196803128388.issue16203@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> 3 of the tests expect None when using 'fullmatch'; they won't return 
> None when using 'match'.

Sorry, my bad. Like Serhiy, I can't comment on the changes to re internals, but we can trust you on this. The patch needs documentation, though.

----------

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

From report at bugs.python.org  Wed Feb  6 19:31:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Feb 2013 18:31:42 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360175502.34.0.728242327902.issue16038@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Micha?, thanks for the patch. Could you sign and e-mail a contributor's agreement? http://www.python.org/psf/contrib/

As for the patch:
- the test could be a separate test_ method
- the offset variable isn't used in cmd_retrlarge, there is no need computing it

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

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

From report at bugs.python.org  Wed Feb  6 19:33:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Feb 2013 18:33:29 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360175609.76.0.46372518695.issue5308@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Perhaps you could add a bigmem test for this?
(assuming you have enough memory somewhere to test it)

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

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

From report at bugs.python.org  Wed Feb  6 19:34:43 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 06 Feb 2013 18:34:43 +0000
Subject: [issue17144] Distutils: "sdist register upload" ignores -r argument
In-Reply-To: <1360167032.54.0.0794749413911.issue17144@psf.upfronthosting.co.za>
Message-ID: <1360175683.28.0.0985030701431.issue17144@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

See issue 16926 for another issue about using -r with register.

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Wed Feb  6 19:35:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Feb 2013 18:35:55 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1360175755.84.0.725576197447.issue13773@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is an updated patch.

----------
Added file: http://bugs.python.org/file28982/sqlite_open_uri.patch

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

From report at bugs.python.org  Wed Feb  6 19:44:26 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 06 Feb 2013 18:44:26 +0000
Subject: [issue17144] Distutils: "sdist register upload" ignores -r argument
In-Reply-To: <1360167032.54.0.0794749413911.issue17144@psf.upfronthosting.co.za>
Message-ID: <1360176266.09.0.773438805247.issue17144@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Danilo, does this work any better?

$ python setup.py sdist register -r local upload

----------

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

From report at bugs.python.org  Wed Feb  6 19:55:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Feb 2013 18:55:57 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360176957.78.0.661983444036.issue17139@psf.upfronthosting.co.za>


R. David Murray added the comment:

No.  As I said, datetime.now() returns a *datetime object*.  Formatting only becomes involved when you format an object, and that applies to *any* datetime object, and is correctly documented in __str__ + isoformat.

Please do not reopen the issue again unless you get our agreement.

----------
resolution:  -> invalid
status: open -> closed
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb  6 20:02:44 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 06 Feb 2013 19:02:44 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360177364.16.0.185133483754.issue16038@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> Have you read and checked what the RFCs about the
> FTP protocol say about  maximum line length?

vsftpd seems to use a 4096 limit (and the guy knows his stuff :-):
ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-3.0.2/defs.h

----------
nosy: +neologix

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

From report at bugs.python.org  Wed Feb  6 20:08:42 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 19:08:42 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360177722.34.0.424512811028.issue5308@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> (and C standard requites at least 32-bit ints)

No, that's not true: see Annex E of the standard, where the minimum for INT_MAX is declared to be 32767.

----------

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

From report at bugs.python.org  Wed Feb  6 20:09:01 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 06 Feb 2013 19:09:01 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360177741.79.0.779156912686.issue5308@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

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

From report at bugs.python.org  Wed Feb  6 20:10:56 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Feb 2013 19:10:56 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360177856.68.0.831008329732.issue5308@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Theoretically int may be 16 bits (C99):

5.2.4.2.1 Sizes of integer types <limits.h>

 -- maximum value for an object of type int
    INT_MAX +32767 // 2**15 ? 1


I agree that Python wouldn't compile on such a platform anyway.

----------
nosy: +skrah

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

From report at bugs.python.org  Wed Feb  6 20:11:51 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Feb 2013 19:11:51 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360177911.33.0.841598198072.issue5308@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Hmm, Mark was faster. ;)

----------

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

From report at bugs.python.org  Wed Feb  6 20:14:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 19:14:10 +0000
Subject: [issue17147] BytesIO should be mentioned in SpooledTemporaryFile
	documentation
Message-ID: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently only StringIO is mentioned (which was inherited from Python 2).

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: SpooledTemporaryFile_document_BytesIO.patch
keywords: patch
messages: 181563
nosy: docs at python, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: BytesIO should be mentioned in SpooledTemporaryFile documentation
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28983/SpooledTemporaryFile_document_BytesIO.patch

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

From report at bugs.python.org  Wed Feb  6 20:15:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 19:15:19 +0000
Subject: [issue1423] wave sunau aifc 16bit errors
In-Reply-To: <1194812128.3.0.121145701122.issue1423@psf.upfronthosting.co.za>
Message-ID: <1360178119.88.0.87557356259.issue1423@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb  6 20:19:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 19:19:39 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1360175609.76.0.46372518695.issue5308@psf.upfronthosting.co.za>
Message-ID: <201302062119.21514.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Perhaps you could add a bigmem test for this?
> (assuming you have enough memory somewhere to test it)

I think this is possible.  I now have some experience in the writing of bigmem 
tests. ;)

----------

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

From report at bugs.python.org  Wed Feb  6 20:25:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 19:25:58 +0000
Subject: [issue16203] Proposal: add re.fullmatch() method
In-Reply-To: <1360175235.67.0.196803128388.issue16203@psf.upfronthosting.co.za>
Message-ID: <201302062125.43856.storchaka@gmail.com>


Serhiy Storchaka added the comment:

I can't comment right now, but I am going inspect thoroughly re internals. 
This is a new feature and we have enough time before 3.4 freeze.

----------

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

From report at bugs.python.org  Wed Feb  6 20:47:28 2013
From: report at bugs.python.org (Dave)
Date: Wed, 06 Feb 2013 19:47:28 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360180048.51.0.88012144027.issue17139@psf.upfronthosting.co.za>


Dave added the comment:

Ok, as a c++ guy, it looked like it's returning a string.  The documentation says "Return the current local date and time", but it's actually returning a datetime object (likely an object pointer)  initialized to the current time.  I think this is where every class inherits from a common base class which must include the __str__ method or something to that effect.  Then printing the ptr/ref to the datetime.now() object actually just call's it's __str__ method.  I get this now.

I need to study the Python inner workings to get a better sense of this, but this has helped much (my current books are more functional, but too primitive).  

Thanks again David Murray for taking the time to fully address this issue and to everyone who participated.  Issue closed, action to me to learn more python.  If anyone knows a good deeper book on it, please pass on the title.

Sincerely,
Dave

----------

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

From report at bugs.python.org  Wed Feb  6 20:56:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Feb 2013 19:56:26 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360180586.63.0.406140306203.issue17139@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are correct.  Effectively every class has an __str__, and that is what gets called when you print something without specifying any other formatting.  (I say effectively, because if there is no __str__ the __repr__ gets used, which every class *does* have via inheritance from the base object 'object'.)

For what it is worth, I just gave David Beasly's "Python Essential Reference" to someone who is a relatively new Python programmer but an experienced programmer, and he loved it.

----------

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

From report at bugs.python.org  Wed Feb  6 21:02:15 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 20:02:15 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360180935.09.0.115782356642.issue13355@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> An exception is better than a garbage result.

Agreed.  And ZeroDivisionError is the wrong exception, too---ValueError would be better.  But I'm content that the current patch fixes the immediate issue.

----------

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

From report at bugs.python.org  Wed Feb  6 21:05:53 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Feb 2013 20:05:53 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360181153.35.0.196937483871.issue17145@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Changing array.array would be a new feature, so it cannot go into 2.7.

The documentation could be improved, see also #14198.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, skrah

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

From report at bugs.python.org  Wed Feb  6 21:10:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 20:10:10 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1360177722.34.0.424512811028.issue5308@psf.upfronthosting.co.za>
Message-ID: <201302062209.55241.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> No, that's not true: see Annex E of the standard, where the minimum for
> INT_MAX is declared to be 32767.

My fault. Do I have to support such a case in the code?

----------

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

From report at bugs.python.org  Wed Feb  6 21:17:57 2013
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=)
Date: Wed, 06 Feb 2013 20:17:57 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360181877.57.0.455929999026.issue16038@psf.upfronthosting.co.za>


Micha? Jastrz?bski added the comment:

Well, that is not from RFC (or I hadn't find it):) however I'd lie if I'd call myself an expert, should I change limit to 4096 then?

----------

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

From report at bugs.python.org  Wed Feb  6 21:25:23 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 20:25:23 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360182323.12.0.506997078785.issue5308@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Do I have to support such a case in the code?

No, I don't see any need for that:  after all, you're making the code *more* portable by replacing those occurrences of INT_MAX with 0x7fffffff. :-)

----------

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

From report at bugs.python.org  Wed Feb  6 21:29:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 20:29:13 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360182553.44.0.847020153082.issue5308@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps we should change signatures of w_string() and r_string() -- replace "int" by at least "long".

----------

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

From report at bugs.python.org  Wed Feb  6 21:38:01 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2013 20:38:01 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360183081.19.0.292467843712.issue5308@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Hmm, yes, I think that would also make sense.  I missed those uses of int.

I'll give in, though, and accept that >= 32-bit ints are a de facto standard, even if not de jure.

----------

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

From report at bugs.python.org  Wed Feb  6 22:45:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Feb 2013 21:45:54 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360187154.76.0.386651074583.issue17137@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It would really help if you can write a short script reproducing the problem. Can you reproduce the problem with Python 3.2 on Windows 8, or with Python 3.3 on Windows XP or 7?

----------

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

From report at bugs.python.org  Wed Feb  6 23:36:10 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 06 Feb 2013 22:36:10 +0000
Subject: [issue17148] mingw: nt thread model detection
Message-ID: <1360190170.63.0.398498965196.issue17148@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

Proposed  patch adds test for NT-threads to configure script . It was part of issue3871 and is related only to threading support.

Unlike previous one new patch avoid changes in code like #if A undef B or similar.
For instance 
- avoid presence of header pthread.h in Python/ceval.c and  Python/thread.c (HAVE_PTHREAD_H dependency)
- avoid detection of function pthread_kill  in Modules/signalmodule.c (HAVE_PTHREAD_KILL)
- avoid sem_open() Modules/_multiprocessing/multiprocessing.c (HAVE_SEM_OPEN)
( see patch for reason to skip those checks at configure time)

----------
components: Build
files: 0001-MINGW-BASE-use-NT-thread-model.patch
keywords: patch
messages: 181576
nosy: rpetrov
priority: normal
severity: normal
status: open
title: mingw: nt thread model detection
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file28984/0001-MINGW-BASE-use-NT-thread-model.patch

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

From report at bugs.python.org  Thu Feb  7 02:06:12 2013
From: report at bugs.python.org (Dave)
Date: Thu, 07 Feb 2013 01:06:12 +0000
Subject: [issue17139] dateTime.now() return format missing decimal seconds.
In-Reply-To: <1360100627.57.0.770779965412.issue17139@psf.upfronthosting.co.za>
Message-ID: <1360199172.2.0.410559181953.issue17139@psf.upfronthosting.co.za>


Dave added the comment:

I'll order it. 

Thanks again,
Dave

----------

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

From report at bugs.python.org  Thu Feb  7 03:15:15 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 07 Feb 2013 02:15:15 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360203315.06.0.720158572265.issue17047@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

These are the ones that I think are wrong:

Doc/c-api/long.rst:206

   Return a C :c:type:`size_t` representation of of *pylong*.  *pylong* must be

Doc/c-api/long.rst:218

   Return a C :c:type:`unsigned PY_LONG_LONG` representation of of *pylong*.

Doc/library/email.policy.rst:330

      line breaks and and any (RFC invalid) binary data it may contain.

Doc/library/ipaddress.rst:395

      These attributes are true for the network as a whole if they are true
      true for both the network address and the broadcast address

Doc/library/ipaddress.rst:454

      ``True`` if this network is partly or wholly contained in *other* or
      or *other* is wholly contained in this network.

Doc/library/ipaddress.rst:584

      These attribute is true for the network as a whole if it is true
      true for both the network address and the broadcast address

Doc/library/ssl.rst:826

   The *server_name_callback* function must return ``None`` to allow the
   the TLS negotiation to continue.  If a TLS failure is required, a constant

Doc/library/stdtypes.rst:2640

      Cast 1D/unsigned char to to 2D/unsigned long::

Doc/library/unittest.mock.rst:1011

    attributes that your production code creates at runtime. It is off by by

Doc/library/xml.dom.rst:359

   children, returning *newChild*. If the node was already in
   in the tree, it is removed first.

Doc/whatsnew/3.3.rst:1539

New attribute attribute :data:`multiprocessing.Process.sentinel` allows a

Include/pyport.h:884

 * also also takes care of Apple's universal builds.

Lib/argparse.py:1143

        - encoding -- The file's encoding. Accepts the same values as the
            the builtin open() function.

Lib/ftplib.py:468

          callback: An optional single parameter callable that is called on
                    on each block of data after it is sent.  [default: None]

Lib/ftplib.py:490

          callback: An optional single parameter callable that is called on
                    on each line after it is sent.  [default: None]

Lib/turtle.py:859

    Thus stops execution of turtle graphics script. Main purpose: use in
    in the Demo-Viewer turtle.Demo.py.

Lib/_pyio.py:306

        Change the stream position to byte offset offset. offset is

[It's referring to the byte-offset parameter called "offset"; the parameter is actually called "pos".]

Lib/concurrent/futures/_base.py:520

            fn: A callable that will take take as many arguments as there are

Lib/distutils/command/install.py:266

            raise DistutilsOptionError("can't combine user with with prefix/"

Lib/distutils/tests/test_install.py:168

        # can't combine user with with prefix/exec_prefix/home or

Lib/email/policy.py:26

    The API extensions enabled by this this policy are currently provisional.

Lib/email/_encoded_words.py:17

# to to the CTE tables, but YAGNI for now.  'q' is Quoted Printable, 'b' is

Lib/email/_header_value_parser.py:1866

    We allow anything except the excluded characters, but but if we find any

Lib/email/mime/text.py:29

        # If no _charset was specified, check to see see if there are non-ascii

Lib/idlelib/extend.txt:57

Here is a complete example example:

Lib/idlelib/extend.txt:75

used to to configure the loading of extensions and to establish key (or, more

Lib/idlelib/rpc.py:4

connect to the Idle process, which listens for the connection.  Since Idle has
has only one client per server, this was not a limitation.

Lib/lib2to3/pgen2/grammar.py:23

    """Pgen parsing tables tables conversion class.

Lib/lib2to3/pgen2/grammar.py:48

                     states, each state is is a list of arcs, and each

Lib/msilib/__init__.py:327

        """Add a file to the current component of the directory, starting a new one
        one if there is no current component. By default, the file name in the source

Lib/test/test_decimal.py:4495

        # Do operations and check that it didn't change change internal objects.

Lib/test/test_socket.py:845

        # Try udp, but don't barf it it doesn't exist

[Should be "if it".]

Lib/tkinter/tix.py:1920

                     Val may be: "auto" -- the width of the column is set the
                     the widest cell in the column; a valid Tk screen distance

Lib/tkinter/tix.py:1944

                     Val may be: "auto" -- the height of the row  is  set  the
                     the highest cell in the row; a valid Tk screen distance

Lib/unittest/mock.py:1447

    attributes that your production code creates at runtime. It is off by by

Modules/ossaudiodev.c:233

   SNDCTL_DSP_{SETFMT,CHANNELS,SPEED} -- that that are called from C

Modules/_heapqmodule.c:91

    /* The leaf at pos is empty now.  Put newitem there, and and bubble

Modules/_heapqmodule.c:431

    /* The leaf at pos is empty now.  Put newitem there, and and bubble

Modules/expat/xmltok.c:1587

           way this can fail to be big-endian UTF-16 if it it's an

Modules/zlib/deflate.c:160

 * IN  assertion: all calls to to UPDATE_HASH are made with consecutive

Modules/zlib/deflate.c:173

 * IN  assertion: all calls to to INSERT_STRING are made with consecutive

Modules/zlib/inftrees.h:44

   returns returns 852, and "enough 30 6 15" for distance codes returns 592.

Modules/zlib/zlib.h:815

   success case, the application may save the current current value of total_in

Modules/_ctypes/callproc.c:23

  'inargs', or a completely fresh tuple, depending on several things (is is a

Modules/_ctypes/libffi/src/dlmalloc.c:103

       else. And if if you are sure that your program using malloc has

Modules/_ctypes/libffi/src/dlmalloc.c:609

  are not even meaningful in this version of malloc.  These fields are
  are instead filled by mallinfo() with other numbers that might be of

Modules/_ctypes/libffi/src/dlmalloc.c:1624

  ensured by making all allocations from the the `lowest' part of any

Modules/_ctypes/libffi/src/dlmalloc.c:1830

  parent pointer.)  If a chunk with the same size an an existing node

[Should be "as an".]

Modules/_ctypes/libffi/src/dlmalloc.c:1835

  smallest is 0x100 <= x < 0x180), which is is divided in half at each

Modules/_ctypes/libffi/src/dlmalloc.c:3444

       (disabled if not MORECORE_CONTIGUOUS or not HAVE_MORECORE or
       or main space is mmapped or a previous contiguous call failed)

Modules/_ctypes/libffi/src/ia64/ffi.c:88

/* Return the size of the C type associated with with TYPE.  Which will

Modules/_ctypes/libffi/src/ia64/ffi.c:188

      /* Similarly, except that that HFA is true for double extended,

Tools/msi/msilib.py:493

        """Add a file to the current component of the directory, starting a new one
        one if there is no current component. By default, the file name in the source

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

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

From report at bugs.python.org  Thu Feb  7 08:08:55 2013
From: report at bugs.python.org (moijes12)
Date: Thu, 07 Feb 2013 07:08:55 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1360220935.85.0.174097921659.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

Hi

Is this still open to work on ?

If yes, what were the review comments from the previous review?

----------
nosy: +moijes12

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

From report at bugs.python.org  Thu Feb  7 08:31:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 07 Feb 2013 07:31:15 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1360181877.57.0.455929999026.issue16038@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2SQeH24duUb2t9g7HqhAyEeZ+u=Cy0sbTpnFfNh6gTRw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Well, that is not from RFC (or I hadn't find it):) however I'd lie if I'd call myself an expert, should I change limit to 4096 then?

It's probably not in the RFC: this just shows that the limit chosen
should be enough.

----------

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

From report at bugs.python.org  Thu Feb  7 09:14:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Feb 2013 08:14:21 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360224861.85.0.382956718864.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Lib/tkinter/tix.py:1920
 Val may be: "auto" -- the width of the column is set the
 the widest cell in the column; a valid Tk screen distance

I believe 'the the' should be 'to the width of the'

Lib/tkinter/tix.py:1944
 Val may be: "auto" -- the height of the row  is  set  the
 the highest cell in the row; a valid Tk screen distance

Ditto for heigth instead of width.

----------

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

From report at bugs.python.org  Thu Feb  7 09:17:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Feb 2013 08:17:05 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1360225025.58.0.321862794034.issue12768@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
versions: +Python 3.4

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

From report at bugs.python.org  Thu Feb  7 09:36:05 2013
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Thu, 07 Feb 2013 08:36:05 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1360226165.14.0.948806129405.issue4331@psf.upfronthosting.co.za>


Ulrich Eckhardt added the comment:

Just for the record, the behaviour is documented, unfortunately in the very last line of the functools documentation: "Also, partial objects defined in classes behave like static methods and do not transform into bound methods during instance attribute look-up."

Concerning how exactly they should behave during that lookup, I'd use the least surprising variant, namely that they are not treated differently from other functions: The first parameter is implicitly "self".

----------
nosy: +eckhardt

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

From report at bugs.python.org  Thu Feb  7 09:39:28 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 07 Feb 2013 08:39:28 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1360226368.56.0.37827876877.issue17069@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I shall go ahead with this change. And when the URLopener and FancyURLopener removed, all their references in the docs (including this change) will be removed.

----------

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

From report at bugs.python.org  Thu Feb  7 09:49:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Feb 2013 08:49:53 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <3Z1tWN4V2jzMRY@mail.python.org>


Roundup Robot added the comment:

New changeset fae8e212e870 by Senthil Kumaran in branch '3.2':
Fix Issue17069: Document getcode method in urllib.request.rst
http://hg.python.org/cpython/rev/fae8e212e870

New changeset e15d2ad42d93 by Senthil Kumaran in branch '3.3':
Fix Issue17069: Document getcode method in urllib.request.rst
http://hg.python.org/cpython/rev/e15d2ad42d93

New changeset b79df3e8a9a0 by Senthil Kumaran in branch 'default':
Fix Issue17069: Document getcode method in urllib.request.rst
http://hg.python.org/cpython/rev/b79df3e8a9a0

New changeset 5630f0aff6ac by Senthil Kumaran in branch '2.7':
Fix Issue17069: Document getcode method in urllib.request.rst
http://hg.python.org/cpython/rev/5630f0aff6ac

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  7 09:50:25 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 07 Feb 2013 08:50:25 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1360227025.47.0.154546514713.issue17069@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Thu Feb  7 10:05:06 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Feb 2013 09:05:06 +0000
Subject: [issue17069] HTTP result code in urllib2.urlopen() file object
	undocumented
In-Reply-To: <1359458957.32.0.0277538347747.issue17069@psf.upfronthosting.co.za>
Message-ID: <1360227906.63.0.421817108518.issue17069@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Are these the addinfourl getters that Ezio wants to deprecate?

Yes, see #12707

----------

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

From report at bugs.python.org  Thu Feb  7 10:42:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 09:42:38 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360230158.49.0.850915386328.issue12596@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

As soon as hash randomization is turned on (and it's the default starting with Python 3.3), the pickled representation of dicts will also vary from run to run:

$ python -R -c "import pickle; print pickle.dumps({'a':1, 'b':2})" |md5sum
c0ae6b7f62b9c0839be883dd1efee84e  -
$ python -R -c "import pickle; print pickle.dumps({'a':1, 'b':2})" |md5sum
b03bf608516f3e0244a96d740139b050  -

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

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

From report at bugs.python.org  Thu Feb  7 10:45:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 09:45:47 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360230347.36.0.343641842339.issue16800@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

There are reasons to use buffered I/O rather than os.write: os.write can fail with EINTR, for example.

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

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

From report at bugs.python.org  Thu Feb  7 10:51:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 09:51:08 +0000
Subject: [issue17149] random.vonmisesvariate() returns a value only on the
	half-circle
Message-ID: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

random.vonmisesvariate(mu, kappa) returns a value in the range (mu%2pi)-pi/2 to (mu%2pi)+pi/2 for kappa > 1e-6. For kappa <= 1e-6 it returns an uniform random value over the range 0 to 2*pi.

----------
components: Library (Lib)
messages: 181588
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: random.vonmisesvariate() returns a value only on the half-circle
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb  7 10:51:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 09:51:27 +0000
Subject: [issue17149] random.vonmisesvariate() returns a value only on the
	half-circle
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360230687.91.0.491404216017.issue17149@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Thu Feb  7 10:57:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 09:57:32 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360231052.67.0.831635904383.issue17143@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.4

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

From report at bugs.python.org  Thu Feb  7 11:00:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 10:00:09 +0000
Subject: [issue13655] Python SSL stack doesn't have a default CA Store
In-Reply-To: <1324635534.55.0.434420251569.issue13655@psf.upfronthosting.co.za>
Message-ID: <1360231209.6.0.551612694218.issue13655@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> ?ric's suggestion is also implemented in python-requests if I remember 
> correctly. It allows for user-specified PEM files and tries to find the 
> operating system bundle. This would be a wonderful inclusion in the
> standard library.

Aren't load_verify_locations() and set_default_verify_paths() sufficient?

http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.load_verify_locations

----------

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

From report at bugs.python.org  Thu Feb  7 11:44:39 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 10:44:39 +0000
Subject: [issue17149] random.vonmisesvariate() returns a value only on the
	half-circle
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360233879.86.0.615356546332.issue17149@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I'll take a look at this.

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Feb  7 11:45:15 2013
From: report at bugs.python.org (Danilo Bargen)
Date: Thu, 07 Feb 2013 10:45:15 +0000
Subject: [issue17144] Distutils: "sdist register upload" ignores -r argument
In-Reply-To: <1360167032.54.0.0794749413911.issue17144@psf.upfronthosting.co.za>
Message-ID: <1360233915.35.0.693027332228.issue17144@psf.upfronthosting.co.za>


Danilo Bargen added the comment:

chris, no, that command registers the package with the local index but tries to upload it to pypi.

What works is "setup.py sdist register -r wbrp upload -r wbrp" but that's kind of awful.

----------

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

From report at bugs.python.org  Thu Feb  7 12:25:21 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 07 Feb 2013 11:25:21 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1360236321.96.0.932525598012.issue9253@psf.upfronthosting.co.za>


Changes by Bohuslav "Slavek" Kabrda <bkabrda at redhat.com>:


----------
nosy: +bkabrda

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

From report at bugs.python.org  Thu Feb  7 12:41:03 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 07 Feb 2013 11:41:03 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1360237263.03.0.549003793247.issue6083@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The FreeBSD 6.4 bot is failing, too. Note that the other functions
in test_returnfuncptrs.py do this in order to get strchr():

    dll = CDLL(_ctypes_test.__file__)
    get_strchr = dll.get_strchr
    get_strchr.restype = CFUNCTYPE(c_char_p, c_char_p, c_char)
    strchr = get_strchr()

----------
nosy: +skrah

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

From report at bugs.python.org  Thu Feb  7 12:42:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 11:42:48 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360237368.43.0.771024987677.issue17141@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an implementation which is more precise for small and large kappa, doesn't hang for large kappa, and even a little faster. It is mathematically totally equivalent to existing, but use more accurate calculations.

----------
keywords: +patch
Added file: http://bugs.python.org/file28985/random_vonmisesvariate.diff

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

From report at bugs.python.org  Thu Feb  7 12:43:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 11:43:01 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360237381.59.0.229495577589.issue17141@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Thu Feb  7 13:01:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 12:01:20 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360238480.12.0.920475290096.issue12596@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is surprising that the pickled representation of 1-element dict varies from run to run.

----------
components: +Extension Modules -None

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

From report at bugs.python.org  Thu Feb  7 13:26:04 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 07 Feb 2013 12:26:04 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360239964.53.0.378319036276.issue12596@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Try `./python -R -c "import pickle; print(pickle.dumps({'a':1, 'v':1}))" |md5sum`. The output will differ on subsequent run, while trying `./python -R -c "import pickle; print(pickle.dumps({'a':1}))" |md5sum`, the output is always the same. I suspect because the order of dicts are different on every run (try repr).

----------
nosy: +ramchandra.apte
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb  7 13:26:32 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Thu, 07 Feb 2013 12:26:32 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360239992.22.0.369455240571.issue17137@psf.upfronthosting.co.za>


Jan Lachnitt added the comment:

Knowing that the problem is related to the internal representation of the strings, I have written a short script which reproduces the problem. It is this simple:

import os
name = 'sub-fcc'
wrkdir = 'D:\\Bug reports\\Python\\test'
dirname = wrkdir+os.sep+name
print(dirname)
print(ascii(dirname.encode("unicode_internal")))
dirname += os.sep+'bulk'
print(dirname)
print(ascii(dirname.encode("unicode_internal")))

Output:

D:\Bug reports\Python\test\sub-fcc
b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00t\x00e\x00s\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00'
D:\Bug reports\Python\test\sub-fcc\bulk
b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00t\x00e\x00s\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00\x00\x00\x00\x00\xd8\xa3\x90\x02\x00\x00'

The end of the output varies from run to run.

It works correctly in Python 3.2.3 64-bit on Windows 8.

----------

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

From report at bugs.python.org  Thu Feb  7 13:27:24 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 07 Feb 2013 12:27:24 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360240044.28.0.562237292033.issue12596@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Darn, last sentence has some mistakes.
I suspect this issue is happening because the order of a dictionary is different on every run (try repr).

----------

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

From report at bugs.python.org  Thu Feb  7 13:30:32 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 07 Feb 2013 12:30:32 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360240232.61.0.900567190325.issue12596@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Further proof:
here are the results of two invocations of `./python -R -c "import pickle; print(pickle.dumps({'a':1, 'v':1}))"`

b'\x80\x03}q\x00(X\x01\x00\x00\x00vq\x01K\x01X\x01\x00\x00\x00aq\x02K\x01u.'
b'\x80\x03}q\x00(X\x01\x00\x00\x00aq\x01K\x01X\x01\x00\x00\x00vq\x02K\x01u.'
Notice that in the second pickled data, the pickled data for 'v' has exchanged places with the one for 'a'! ('v' has become 'a' and at the second-last character 'a' has become 'v')

----------

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

From report at bugs.python.org  Thu Feb  7 13:31:29 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Feb 2013 12:31:29 +0000
Subject: [issue16389] re._compiled_typed's lru_cache causes significant
	degradation of the mako_v2 bench
In-Reply-To: <1351880615.07.0.187029674279.issue16389@psf.upfronthosting.co.za>
Message-ID: <1360240289.72.0.197271076817.issue16389@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
nosy: +asvetlov

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

From report at bugs.python.org  Thu Feb  7 13:51:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 12:51:07 +0000
Subject: [issue17150] pprint could use line continuation for long string
	literals
Message-ID: <1360241467.59.0.786252231553.issue17150@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently:

>>> pprint.pprint({"a": "xxx " * 50})
{'a': 'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '}

It would be nicer if it produced something like:

>>> pprint.pprint({"a": "xxx " * 50})
{'a': 'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '
      'xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx '}

(for the record, the real-world use case I encountered was when printing some pyudev data)

----------
components: Library (Lib)
messages: 181599
nosy: fdrake, pitrou
priority: normal
severity: normal
status: open
title: pprint could use line continuation for long string literals
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  7 14:05:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:05:08 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1360242308.45.0.644191009877.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are 6 different ways to get a function (see comment around PyCFuncPtr_new() in Modules/_ctypes/_ctypes.c). The other tests just use other ways.

I'm more carefully read ctype code and found my mistake. Need to import "my_strchr", and not "strchr".

----------

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

From report at bugs.python.org  Thu Feb  7 14:09:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:09:13 +0000
Subject: [issue16389] re._compiled_typed's lru_cache causes significant
	degradation of the mako_v2 bench
In-Reply-To: <1351880615.07.0.187029674279.issue16389@psf.upfronthosting.co.za>
Message-ID: <1360242553.28.0.3454962985.issue16389@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Maybe lru_cache() should have a key argument so you can specify a specialized key function.

It would be interesting to look at the microbenchmarking results.

----------

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

From report at bugs.python.org  Thu Feb  7 14:11:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Feb 2013 13:11:44 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360239992.22.0.369455240571.issue17137@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaDniejm1krCeLed3h4w5oo0z2A6oP4xqMBRMh-gv2wVw@mail.gmail.com>


STINNER Victor added the comment:

> It works correctly in Python 3.2.3 64-bit on Windows 8.

Can you reproduce the issue on other Windows versions?

2013/2/7 Jan Lachnitt <report at bugs.python.org>:
>
> Jan Lachnitt added the comment:
>
> Knowing that the problem is related to the internal representation of the strings, I have written a short script which reproduces the problem. It is this simple:
>
> import os
> name = 'sub-fcc'
> wrkdir = 'D:\\Bug reports\\Python\\test'
> dirname = wrkdir+os.sep+name
> print(dirname)
> print(ascii(dirname.encode("unicode_internal")))
> dirname += os.sep+'bulk'
> print(dirname)
> print(ascii(dirname.encode("unicode_internal")))
>
> Output:
>
> D:\Bug reports\Python\test\sub-fcc
> b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00t\x00e\x00s\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00'
> D:\Bug reports\Python\test\sub-fcc\bulk
> b'D\x00:\x00\\\x00B\x00u\x00g\x00 \x00r\x00e\x00p\x00o\x00r\x00t\x00s\x00\\\x00P\x00y\x00t\x00h\x00o\x00n\x00\\\x00t\x00e\x00s\x00t\x00\\\x00s\x00u\x00b\x00-\x00f\x00c\x00c\x00\x00\x00\x00\x00\xd8\xa3\x90\x02\x00\x00'
>
> The end of the output varies from run to run.
>
> It works correctly in Python 3.2.3 64-bit on Windows 8.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17137>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Feb  7 14:13:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:13:38 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1360242818.7.0.0581264032915.issue12596@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is most probable that the difference is caused by the string interning.

----------

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

From report at bugs.python.org  Thu Feb  7 14:15:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:15:11 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360242911.3.0.0444624381899.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Terry, do you want to provide a patch?

----------

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

From report at bugs.python.org  Thu Feb  7 14:25:25 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 07 Feb 2013 13:25:25 +0000
Subject: [issue17150] pprint could use line continuation for long string
	literals
In-Reply-To: <1360241467.59.0.786252231553.issue17150@psf.upfronthosting.co.za>
Message-ID: <1360243525.4.0.0314044913459.issue17150@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

I like this.

It would be especially nice if it were smart enough to split the segments after sequences of line-ends (r'(\r?\n)+').

----------

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

From report at bugs.python.org  Thu Feb  7 14:27:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Feb 2013 13:27:14 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <3Z20gP3xv0zSMW@mail.python.org>


Roundup Robot added the comment:

New changeset cf98766f464e by Serhiy Storchaka in branch '3.2':
Issue #17114: IDLE?now uses non-strict config parser.
http://hg.python.org/cpython/rev/cf98766f464e

New changeset c2ed79fbb9c6 by Serhiy Storchaka in branch '3.3':
Issue #17114: IDLE?now uses non-strict config parser.
http://hg.python.org/cpython/rev/c2ed79fbb9c6

New changeset 877fae8d6f5b by Serhiy Storchaka in branch 'default':
Issue #17114: IDLE?now uses non-strict config parser.
http://hg.python.org/cpython/rev/877fae8d6f5b

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  7 14:35:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:35:03 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1360244103.69.0.419958580133.issue17114@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Just wait a few weeks to release of 3.2.4 and it's appearance in your distribution.

----------

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

From report at bugs.python.org  Thu Feb  7 14:35:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:35:24 +0000
Subject: [issue17114] Python IDLE GUI does not open in Ubuntu 12.04
In-Reply-To: <1359902233.91.0.660945180349.issue17114@psf.upfronthosting.co.za>
Message-ID: <1360244124.24.0.237570191902.issue17114@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  7 14:42:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Feb 2013 13:42:48 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <3Z211N0D44zSXk@mail.python.org>


Roundup Robot added the comment:

New changeset f7cc6fbd7ae1 by Serhiy Storchaka in branch '2.7':
Issue #17118: Add new tests for testing Python-Tcl interaction.
http://hg.python.org/cpython/rev/f7cc6fbd7ae1

New changeset 148e6ebfe854 by Serhiy Storchaka in branch '3.2':
Issue #17118: Add new tests for testing Python-Tcl interaction.
http://hg.python.org/cpython/rev/148e6ebfe854

New changeset 452344620c97 by Serhiy Storchaka in branch '3.3':
Issue #17118: Add new tests for testing Python-Tcl interaction.
http://hg.python.org/cpython/rev/452344620c97

New changeset f0d603948cff by Serhiy Storchaka in branch 'default':
Issue #17118: Add new tests for testing Python-Tcl interaction.
http://hg.python.org/cpython/rev/f0d603948cff

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  7 14:43:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:43:22 +0000
Subject: [issue17118] Add tests for testing Python-Tcl interaction
In-Reply-To: <1359918630.1.0.399114007008.issue17118@psf.upfronthosting.co.za>
Message-ID: <1360244602.66.0.524256073189.issue17118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  7 15:22:48 2013
From: report at bugs.python.org (Sven Brauch)
Date: Thu, 07 Feb 2013 14:22:48 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360246968.75.0.702316554901.issue16795@psf.upfronthosting.co.za>


Sven Brauch added the comment:

Any news on this yet? ;)

Unfortunately, I'm still having no luck in adding the patch to the review tool (same error message).

----------

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

From report at bugs.python.org  Thu Feb  7 15:30:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Feb 2013 14:30:47 +0000
Subject: [issue17043] Invalid read in test_codecs
In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za>
Message-ID: <3Z224k5NTszSZ4@mail.python.org>


Roundup Robot added the comment:

New changeset 498b54e0e856 by Serhiy Storchaka in branch '2.7':
Issue #17043: The unicode-internal decoder no longer read past the end of
http://hg.python.org/cpython/rev/498b54e0e856

New changeset 0f1c2e2b6bc2 by Serhiy Storchaka in branch '3.2':
Issue #17043: The unicode-internal decoder no longer read past the end of
http://hg.python.org/cpython/rev/0f1c2e2b6bc2

New changeset fec2976c8503 by Serhiy Storchaka in branch '3.3':
Issue #17043: The unicode-internal decoder no longer read past the end of
http://hg.python.org/cpython/rev/fec2976c8503

New changeset eb0370d4686c by Serhiy Storchaka in branch 'default':
Issue #17043: The unicode-internal decoder no longer read past the end of
http://hg.python.org/cpython/rev/eb0370d4686c

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  7 15:38:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Feb 2013 14:38:19 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360247899.35.0.122514964661.issue17137@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you try to following command to get the size in bytes of the wchar_t type?

>>> import types
>>> ctypes.sizeof(ctypes.c_wchar)
4

You can also use _PyObject_Dump() to dump your string:

>>> import ctypes
>>> x="abc"
>>> _PyObject_Dump=ctypes.pythonapi._PyObject_Dump
>>> _PyObject_Dump.argtypes=(ctypes.py_object,)
>>> _PyObject_Dump(x)
object  : 'abc'
type    : str
refcount: 5
address : 0xb70bf980
48

Then you can use _PyObject_Dump() on your string.

You may also try: print(list(dirname)).

It's really strange that something very common like string concatenation returns an invalid string.

----------

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

From report at bugs.python.org  Thu Feb  7 15:43:30 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Feb 2013 14:43:30 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360248210.66.0.215341321894.issue16795@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Are you attaching files directly on Rietveld or on this issue?

----------

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

From report at bugs.python.org  Thu Feb  7 15:51:57 2013
From: report at bugs.python.org (Sven Brauch)
Date: Thu, 07 Feb 2013 14:51:57 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360248717.04.0.480598681996.issue16795@psf.upfronthosting.co.za>


Sven Brauch added the comment:

Attaching files to this bug report here works fine (see corrected patch above), but when I add the file to http://bugs.python.org/review/16795/ under "Add another patchset", I get the error message I described. I tried with firefox, chromium and konqueror.

----------

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

From report at bugs.python.org  Thu Feb  7 15:53:08 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Feb 2013 14:53:08 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360248788.8.0.465728118228.issue16795@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yeah, I think that's broken. It's best just to attach them here.

----------

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

From report at bugs.python.org  Thu Feb  7 15:55:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Feb 2013 14:55:18 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360248918.84.0.888328003185.issue16795@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It's just not supported -- the "Add another patchset" link should be removed from rietveld.

----------

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

From report at bugs.python.org  Thu Feb  7 16:00:10 2013
From: report at bugs.python.org (Sven Brauch)
Date: Thu, 07 Feb 2013 15:00:10 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360249210.9.0.204189351434.issue16795@psf.upfronthosting.co.za>


Sven Brauch added the comment:

Oh, alright, that explains things. In this case, the file I attached on Jan 29 (http://bugs.python.org/file28905/81300-change-var-kwargs-new.diff) should contain all the requested changes.

Greetings

----------

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

From report at bugs.python.org  Thu Feb  7 16:04:28 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 15:04:28 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360249468.49.0.1936368588.issue17137@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I don't think this is just windows;  I see similarly odd results on OS X.  The first encode call gives expected results;  the second ends in garbage.


Python 3.4.0a0 (default:eb0370d4686c+, Feb  7 2013, 14:59:41) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> dir1 = "D:\\Bug reports\\Python\\test\\sub-fcc"
[66291 refs, 23475 blocks]
>>> dir1 += "\\bulk"
[66291 refs, 23474 blocks]
>>> ascii(dir1.encode('unicode_internal'))
"b'D\\x00\\x00\\x00:\\x00\\x00\\x00\\\\\\x00\\x00\\x00B\\x00\\x00\\x00u\\x00\\x00\\x00g\\x00\\x00\\x00 \\x00\\x00\\x00r\\x00\\x00\\x00e\\x00\\x00\\x00p\\x00\\x00\\x00o\\x00\\x00\\x00r\\x00\\x00\\x00t\\x00\\x00\\x00s\\x00\\x00\\x00\\\\\\x00\\x00\\x00P\\x00\\x00\\x00y\\x00\\x00\\x00t\\x00\\x00\\x00h\\x00\\x00\\x00o\\x00\\x00\\x00n\\x00\\x00\\x00\\\\\\x00\\x00\\x00t\\x00\\x00\\x00e\\x00\\x00\\x00s\\x00\\x00\\x00t\\x00\\x00\\x00\\\\\\x00\\x00\\x00s\\x00\\x00\\x00u\\x00\\x00\\x00b\\x00\\x00\\x00-\\x00\\x00\\x00f\\x00\\x00\\x00c\\x00\\x00\\x00c\\x00\\x00\\x00\\\\\\x00\\x00\\x00b\\x00\\x00\\x00u\\x00\\x00\\x00l\\x00\\x00\\x00k\\x00\\x00\\x00'"
[69015 refs, 24925 blocks]
>>> dir1 += "\\bulk"
[69015 refs, 24925 blocks]
>>> ascii(dir1.encode('unicode_internal'))
"b'D\\x00\\x00\\x00:\\x00\\x00\\x00\\\\\\x00\\x00\\x00B\\x00\\x00\\x00u\\x00\\x00\\x00g\\x00\\x00\\x00 \\x00\\x00\\x00r\\x00\\x00\\x00e\\x00\\x00\\x00p\\x00\\x00\\x00o\\x00\\x00\\x00r\\x00\\x00\\x00t\\x00\\x00\\x00s\\x00\\x00\\x00\\\\\\x00\\x00\\x00P\\x00\\x00\\x00y\\x00\\x00\\x00t\\x00\\x00\\x00h\\x00\\x00\\x00o\\x00\\x00\\x00n\\x00\\x00\\x00\\\\\\x00\\x00\\x00t\\x00\\x00\\x00e\\x00\\x00\\x00s\\x00\\x00\\x00t\\x00\\x00\\x00\\\\\\x00\\x00\\x00s\\x00\\x00\\x00u\\x00\\x00\\x00b\\x00\\x00\\x00-\\x00\\x00\\x00f\\x00\\x00\\x00c\\x00\\x00\\x00c\\x00\\x00\\x00\\\\\\x00\\x00\\x00b\\x00\\x00\\x00u\\x00\\x00\\x00l\\x00\\x00\\x00k\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xfb\\xfb\\xfb\\xfb\\xfb\\xfb\\xfb\\xfb\\x00\\x00\\x00\\x00\\x00\\x015\\x1a'"
[69015 refs, 24925 blocks]

----------

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

From report at bugs.python.org  Thu Feb  7 16:08:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Feb 2013 15:08:27 +0000
Subject: [issue17073] Integer overflow in sqlite module
In-Reply-To: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za>
Message-ID: <3Z22wB5WJWzSZq@mail.python.org>


Roundup Robot added the comment:

New changeset 649937bb8f1c by Serhiy Storchaka in branch '2.7':
Issue #17073: Fix some integer overflows in sqlite3 module.
http://hg.python.org/cpython/rev/649937bb8f1c

New changeset 55a89352e220 by Serhiy Storchaka in branch '3.2':
Issue #17073: Fix some integer overflows in sqlite3 module.
http://hg.python.org/cpython/rev/55a89352e220

New changeset c5fb8bc56def by Serhiy Storchaka in branch '3.3':
Issue #17073: Fix some integer overflows in sqlite3 module.
http://hg.python.org/cpython/rev/c5fb8bc56def

New changeset b8a6bc70fc08 by Serhiy Storchaka in branch 'default':
Issue #17073: Fix some integer overflows in sqlite3 module.
http://hg.python.org/cpython/rev/b8a6bc70fc08

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Feb  7 16:09:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 15:09:15 +0000
Subject: [issue17073] Integer overflow in sqlite module
In-Reply-To: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za>
Message-ID: <1360249755.11.0.539387807538.issue17073@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  7 16:19:42 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Thu, 07 Feb 2013 15:19:42 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360250382.4.0.986596464585.issue17137@psf.upfronthosting.co.za>


Jan Lachnitt added the comment:

On Windows XP 32-bit: 3.2.3 works, 3.3.0 fails.

----------

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

From report at bugs.python.org  Thu Feb  7 16:34:19 2013
From: report at bugs.python.org (Franck Michea)
Date: Thu, 07 Feb 2013 15:34:19 +0000
Subject: [issue17151] Python 3 changement of behavior with __ne__:
	documentation not updated
Message-ID: <1360251259.3.0.329716783607.issue17151@psf.upfronthosting.co.za>


New submission from Franck Michea:

Hi. As of python 3, behavior of object.__ne__ changed to call (not object.__eq__) if implemented. This changement can be seen in function object_richcompare in file Objects/typeobject.c.

Documentation didn't change though, still saying[1] that "There are no implied relationships among the comparison operators. [...] Accordingly, when defining __eq__(), one should also define __ne__()".

Maybe a paragraph about this new behavior would be fine? I am not sure if last sentence of last paragraph is what it means, but it was already there in python 2 doc so guess no. I am not sure about how to write it so no patch, sorry.

[1] http://docs.python.org/3.3/reference/datamodel.html#object.__eq__

----------
assignee: docs at python
components: Documentation
messages: 181620
nosy: docs at python, kushou
priority: normal
severity: normal
status: open
title: Python 3 changement of behavior with __ne__: documentation not updated
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Feb  7 16:41:57 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Feb 2013 15:41:57 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360251717.51.0.194785255508.issue17137@psf.upfronthosting.co.za>


Florent Xicluna added the comment:

Confirmed on OSX 64bits with Mark's sample.

$ python3.3
Python 3.3.0 (default, Jan 24 2013, 08:28:09) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> dir1 = "D:\\Bug reports\\Python\\test\\sub-fcc"
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> len(s1), s1[499:]
(586, "00k\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xf0\\xbda\\x00\\x01\\x00\\x00\\x00X\\x1da\\x00\\x01\\x00\\x00\\x00'")
>>> dir1 = "D:\\Bug reports\\Python\\test\\sub-fcc"
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> len(s1), s1[499:]
(586, "00k\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x10\\xbca\\x00\\x01\\x00\\x00\\x00X\\x16a\\x00\\x01\\x00\\x00\\x00'")
>>> dir1 = "D:\\Bug reports\\Python\\test\\sub-fcc"
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> len(s1), s1[499:]
(595, "00k\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00'")
>>> dir1 = "D:\\Bug reports\\Python\\test\\sub-fcc"
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> dir1 += "\\bulk"
>>> s1 = ascii(dir1.encode('unicode_internal'))
>>> len(s1), s1[499:]
(586, "00k\\x00\\x00\\x00\\x00\\x00\\x00\\x00p\\xbba\\x00\\x01\\x00\\x00\\x00\\x88\\x14a\\x00\\x01\\x00\\x00\\x00'")
>>> 


Darwin Kernel Version 10.8.0: Tue Jun  7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64

----------

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

From report at bugs.python.org  Thu Feb  7 16:44:11 2013
From: report at bugs.python.org (Jan Lachnitt)
Date: Thu, 07 Feb 2013 15:44:11 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360251851.7.0.930573232173.issue17137@psf.upfronthosting.co.za>


Jan Lachnitt added the comment:

...
print(ctypes.sizeof(ctypes.c_wchar))
_PyObject_Dump=ctypes.pythonapi._PyObject_Dump
_PyObject_Dump.argtypes=(ctypes.py_object,)
print(_PyObject_Dump(dirname))
print(list(dirname))

in Python 3.3.0 64-bit on Windows 8 produces:

2
object  : 'D:\\Bug reports\\Python\\test\\sub-fcc\\bulk'
type    : str
refcount: 3
address : 00000000028AC298
54
['D', ':', '\\', 'B', 'u', 'g', ' ', 'r', 'e', 'p', 'o', 'r', 't', 's', '\\', 'P', 'y', 't', 'h', 'o', 'n', '\\', 't', 'e', 's', 't', '\\', 's', 'u', 'b', '-', 'f', 'c', 'c', '\\', 'b', 'u', 'l', 'k']

----------

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

From report at bugs.python.org  Thu Feb  7 16:44:53 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 07 Feb 2013 15:44:53 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360251893.99.0.873534248393.issue17137@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
components:  -Windows

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

From report at bugs.python.org  Thu Feb  7 16:53:40 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 07 Feb 2013 15:53:40 +0000
Subject: [issue17152] Array module should support "boolean" natively
Message-ID: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n:

Array module is used, frequently, as a convenient way of saving a lot of memory. I think we should support "boolean" typeobject natively. Implementation should be trivial and efficient, except methods like "pop()" (a bit convoluted, but doable).

Opinions?.

----------
keywords: easy
messages: 181623
nosy: jcea
priority: normal
severity: normal
status: open
title: Array module should support "boolean" natively
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Feb  7 17:17:19 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 07 Feb 2013 16:17:19 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360253839.42.0.0176373178992.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Here's a patch for the docs that adds a little clarity.

----------
keywords: +patch
Added file: http://bugs.python.org/file28986/buffer.patch

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

From report at bugs.python.org  Thu Feb  7 17:19:51 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Feb 2013 16:19:51 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360251894.01.0.235051741789.issue17137@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbauwb-PDWUNWquwN--wvHQfaffzbJr6MTb-atTXztLKQ@mail.gmail.com>


STINNER Victor added the comment:

Ok, it's a bug in the function resize a compact Unicode string,
resize_compact(): wstr field is not updated to the new size.

Attached patch should fix it. The bug was introduced by me in Python 3.3.

I don't think that it's possible to resize wstr buffer instead of
freeing it: it will not be refilled by PyUnicode_AsUnicodeAndSize() if
wstr is not NULL. An alternative is to create a new string (instead of
using realloc) if wstr is not NULL.

2013/2/7 Florent Xicluna <report at bugs.python.org>:
>
> Changes by Florent Xicluna <florent.xicluna at gmail.com>:
>
>
> ----------
> components:  -Windows
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17137>
> _______________________________________

----------
keywords: +patch
Added file: http://bugs.python.org/file28987/pep393.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17137>
_______________________________________
-------------- next part --------------
diff -r b8a6bc70fc08 Lib/test/test_unicode.py
--- a/Lib/test/test_unicode.py	Thu Feb 07 17:05:32 2013 +0200
+++ b/Lib/test/test_unicode.py	Thu Feb 07 17:15:48 2013 +0100
@@ -7,6 +7,7 @@ Written by Marc-Andre Lemburg (mal at lembu
 """#"
 import _string
 import codecs
+import random
 import struct
 import sys
 import unittest
@@ -2191,6 +2192,20 @@ class UnicodeTest(string_tests.CommonTes
         self.assertEqual(args[0], text)
         self.assertEqual(len(args), 1)
 
+    def test_resize(self):
+        for length in range(1, 100, 7):
+            # generate a fresh string (refcount=1)
+            text = 'a' * length + 'b'
+
+            # fill wstr internal field
+            abc = text.encode('unicode_internal')
+            self.assertEqual(abc.decode('unicode_internal'), text)
+
+            text += 'c'
+            abcdef = text.encode('unicode_internal')
+            self.assertNotEqual(abc, abcdef)
+            self.assertEqual(abcdef.decode('unicode_internal'), text)
+
 
 class StringModuleTest(unittest.TestCase):
     def test_formatter_parser(self):
diff -r b8a6bc70fc08 Objects/unicodeobject.c
--- a/Objects/unicodeobject.c	Thu Feb 07 17:05:32 2013 +0200
+++ b/Objects/unicodeobject.c	Thu Feb 07 17:15:48 2013 +0100
@@ -717,6 +717,10 @@ resize_compact(PyObject *unicode, Py_ssi
         if (!PyUnicode_IS_ASCII(unicode))
             _PyUnicode_WSTR_LENGTH(unicode) = length;
     }
+    else if (_PyUnicode_HAS_WSTR_MEMORY(unicode)) {
+        PyObject_DEL(_PyUnicode_WSTR(unicode));
+        _PyUnicode_WSTR(unicode) = NULL;
+    }
 #ifdef Py_DEBUG
     unicode_fill_invalid(unicode, old_length);
 #endif

From report at bugs.python.org  Thu Feb  7 17:23:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Feb 2013 16:23:10 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360254190.61.0.942540511744.issue17137@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Jan Lachnitt: Thanks for your patience and having executed all my commands :-) Thanks for the short script reproducing the issue.

----------

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

From report at bugs.python.org  Thu Feb  7 17:23:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Feb 2013 16:23:24 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360254204.58.0.831331840151.issue17137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +larry
priority: high -> release blocker

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

From report at bugs.python.org  Thu Feb  7 17:24:24 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:24:24 +0000
Subject: [issue17152] Array module should support "boolean" natively
In-Reply-To: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>
Message-ID: <1360254264.72.0.887106497571.issue17152@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

What do you mean by 'natively'?  How much space do you envisage each bool taking?  That is, are you suggesting a packed bool representation with 8 entries to a byte, or storing one bool per byte, or something else?

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

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

From report at bugs.python.org  Thu Feb  7 17:27:09 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:27:09 +0000
Subject: [issue17151] Python 3 changement of behavior with __ne__:
	documentation not updated
In-Reply-To: <1360251259.3.0.329716783607.issue17151@psf.upfronthosting.co.za>
Message-ID: <1360254429.05.0.694038197058.issue17151@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

There's a (long-standing) issue already open for this: #4395.  I'll close this as a duplicate and add a note to that issue;  with any luck, pinging that issue might produce some movement.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
status: open -> closed
superseder:  -> Document auto __ne__ generation; provide a use case for non-trivial __ne__

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

From report at bugs.python.org  Thu Feb  7 17:28:32 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:28:32 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1360254512.04.0.22727183244.issue4395@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Issue #17151 closed as a duplicate of this one.

----------
nosy: +kushou, mark.dickinson

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

From report at bugs.python.org  Thu Feb  7 17:28:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:28:53 +0000
Subject: [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1360254533.25.0.549590891656.issue4395@psf.upfronthosting.co.za>


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


----------
priority: low -> normal

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

From report at bugs.python.org  Thu Feb  7 17:43:21 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Feb 2013 16:43:21 +0000
Subject: [issue17153] tarfile extract fails when Unicode in pathname
Message-ID: <1360255401.83.0.937643629633.issue17153@psf.upfronthosting.co.za>


New submission from Vinay Sajip:

The attached file failing.tar.gz contains a path with UTF-8-encoded Unicode. This causes extractall() to fail, but only when the destination path is Unicode. That's because it leads to a implicit str->unicode conversion using ASCII.

Test script:

import shutil, tarfile, tempfile

tf = tarfile.open('failing.tar.gz', 'r:gz')
workdir = tempfile.mkdtemp()
try:
    # N.B. ensure dest path is Unicode to trigger the failure
    tf.extractall(unicode(workdir))
finally:
    shutil.rmtree(workdir)

Result:

$ python untar.py
Traceback (most recent call last):
  File "untar.py", line 8, in <module>
    tf.extractall(unicode(workdir))
  File "/usr/lib/python2.7/tarfile.py", line 2046, in extractall
    self.extract(tarinfo, path)
  File "/usr/lib/python2.7/tarfile.py", line 2083, in extract
    self._extract_member(tarinfo, os.path.join(path, tarinfo.name))
  File "/usr/lib/python2.7/posixpath.py", line 71, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 44: ordinal not in range(128)

----------
components: Library (Lib), Unicode
messages: 181631
nosy: ezio.melotti, vinay.sajip
priority: normal
severity: normal
status: open
title: tarfile extract fails when Unicode in pathname
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Feb  7 17:44:07 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Feb 2013 16:44:07 +0000
Subject: [issue17153] tarfile extract fails when Unicode in pathname
In-Reply-To: <1360255401.83.0.937643629633.issue17153@psf.upfronthosting.co.za>
Message-ID: <1360255447.05.0.123218281933.issue17153@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file28988/failing.tar.gz

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

From report at bugs.python.org  Thu Feb  7 17:45:09 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Feb 2013 16:45:09 +0000
Subject: [issue17153] tarfile extract fails when Unicode in pathname
In-Reply-To: <1360255401.83.0.937643629633.issue17153@psf.upfronthosting.co.za>
Message-ID: <1360255509.28.0.879711170984.issue17153@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


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

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

From report at bugs.python.org  Thu Feb  7 18:02:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Feb 2013 17:02:50 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1360256570.86.0.191099791319.issue16564@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looking at the documentation, it is clear that (a) what you are trying to do is documented as being correct and (b) it worked in Python2, making this a regression.

I've attached a patch to fix this, which also probably fixes some bugs with BytesGenerator handing of non-text CTE 8bit parts created by BytesParser, but I haven't added tests to confirm that.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28989/encode_noop.patch

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

From report at bugs.python.org  Thu Feb  7 18:49:44 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 07 Feb 2013 17:49:44 +0000
Subject: [issue17154] the 'ignore' pdb command raises IndexError
Message-ID: <1360259384.78.0.34764519237.issue17154@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

An 'ignore' pdb command issued without any parameter raises IndexError.

----------
components: Library (Lib)
messages: 181633
nosy: xdegaye
priority: normal
severity: normal
status: open
title: the 'ignore' pdb command raises IndexError
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb  7 19:00:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Feb 2013 18:00:23 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1360260023.34.0.893952209693.issue16564@psf.upfronthosting.co.za>


R. David Murray added the comment:

Updated patch after review by Ezio and Serhiy.

----------
Added file: http://bugs.python.org/file28990/encode_noop.patch

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

From report at bugs.python.org  Thu Feb  7 19:00:31 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2013 18:00:31 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360260031.31.0.681298631733.issue16038@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

LineTooLong should be added to ftplib.all_errors.
4096 looks enough to me.
The longest lines I can think of occur when processing MLSD command which produces an output of like this:

type=file;size=156;perm=r;modify=20071029155301;unique=801cd2; music.mp3
type=dir;size=0;perm=el;modify=20071127230206;unique=801e33; ebooks
type=file;size=211;perm=r;modify=20071103093626;unique=801e32; module.py

Considering that the file names listed in there are forced to consist of base names (as opposed to *full* path names) I doubt we'll ever hit 4096.
In pyftpdlib I used 2048 bytes.
I can't recall any reference about this in any FTP-related RFC.

----------

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

From report at bugs.python.org  Thu Feb  7 19:02:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 18:02:47 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1360260167.01.0.148817147359.issue16564@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> import io, email
>>> bytesdata = b'\xfa\xfb\xfc\xfd\xfe\xff'
>>> msg = email.mime.application.MIMEApplication(bytesdata, _encoder=encoders.encode_7or8bit)
>>> s = io.BytesIO()
>>> g = email.generator.BytesGenerator(s)
>>> g.flatten(msg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 393, in _handle_text
    if _has_surrogates(msg._payload):
TypeError: can't use a string pattern on a bytes-like object

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Feb  7 19:09:02 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Feb 2013 18:09:02 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1360260542.78.0.717474756884.issue16564@psf.upfronthosting.co.za>


R. David Murray added the comment:

While related, that is a different bug, so I'd rather open a new issue for it.

----------

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

From report at bugs.python.org  Thu Feb  7 19:11:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Feb 2013 18:11:03 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360260663.7.0.517339710757.issue16038@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I suggest that we use twice the size of the largest limit (8192) for the DoS fix and reduce it to 2048 for Python 3.4. 8192 is still a small number for modern computers.

I also like to see comments next to the limit that explain on what grounds we have chosen the value. For example

# vfstpd has a limit of 4096 (ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-3.0.2/defs.h)
# pyftpdlib has a limit of 2048

----------

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

From report at bugs.python.org  Thu Feb  7 19:16:52 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Feb 2013 18:16:52 +0000
Subject: [issue17146] Improve test.support.import_fresh_module()
In-Reply-To: <1360173207.93.0.545038003831.issue17146@psf.upfronthosting.co.za>
Message-ID: <1360261012.12.0.739652685475.issue17146@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't think this is worth it. I say just start with the basics of issue 17037 and that subsumes this.

----------

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

From report at bugs.python.org  Thu Feb  7 19:18:25 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Thu, 07 Feb 2013 18:18:25 +0000
Subject: [issue17155] Logging throwing UnicodeEncodeError exception
Message-ID: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

I've seen *a lot* of people using `logging.exception(exc)` to log exceptions. It all seems okay, until the exc object contains unicode strings, at which point logging throes a UnicodeEncodeError exception.

Example: `exc = Exception(u'operaci\xf3n'); logger.error(exc)` throws an exception, while `exc = Exception(u'operaci\xf3n'); logger.error(u"%s", exc)` does not and works as expected.

The problem for this is in the `_fmt` string in logging being `"%(message)s"`, not `u"%(message)s"`, which ends up getting the string (non-unicode) version of the exception object (returned by `getMessage()`) and failing to apply the formatting since the exception contains unicode.

A solution would be to make the default formatting string a unicode string so the object returned by `getMessage()` (the exception) is converted to unicode by making all formatting strings for logging unicode strings: (could be done for example by changing to `unicode(self._fmt) % record.__dict__` the line logging/__init__.py:467).

Other solution could be to encourage users not to use objects as the first argument to the logging methods, and perhaps even log a warning against it if it's done.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 181640
nosy: Kronuz, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Logging throwing UnicodeEncodeError exception
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17155>
_______________________________________

From report at bugs.python.org  Thu Feb  7 19:20:42 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Feb 2013 18:20:42 +0000
Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate
In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za>
Message-ID: <1360261242.45.0.906636418064.issue17037@psf.upfronthosting.co.za>


Brett Cannon added the comment:

At this point let's just start with the helper class which takes the arguments as necessary to do the proper importing of both the pure Python and accelerated versions of the module and optionally the name of the attribute the test classes expect (otherwise just use the name of the module itself). Then expose two decorator methods to use on subclasses to set the proper class with the proper attribute name. Going fancier with a method that generates the subclasses can come in a separate patch. import_fresh_module() can stay as-is and this class just becomes the preferred way to get both versions of a module at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17037>
_______________________________________

From report at bugs.python.org  Thu Feb  7 20:04:07 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 07 Feb 2013 19:04:07 +0000
Subject: [issue17146] Improve test.support.import_fresh_module()
In-Reply-To: <1360173207.93.0.545038003831.issue17146@psf.upfronthosting.co.za>
Message-ID: <1360263847.72.0.0668800962333.issue17146@psf.upfronthosting.co.za>


Eric Snow added the comment:

My sentiment also.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17146>
_______________________________________

From report at bugs.python.org  Thu Feb  7 20:49:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 19:49:37 +0000
Subject: [issue17150] pprint could use line continuation for long string
	literals
In-Reply-To: <1360241467.59.0.786252231553.issue17150@psf.upfronthosting.co.za>
Message-ID: <1360266577.72.0.41915108826.issue17150@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I was thinking we could re-use textwrap, actually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17150>
_______________________________________

From report at bugs.python.org  Thu Feb  7 20:53:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 19:53:36 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1360260663.7.0.517339710757.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360266633.3512.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I suggest that we use twice the size of the largest limit (8192) for
> the DoS fix and reduce it to 2048 for Python 3.4. 8192 is still a
> small number for modern computers.

Why do you want to reduce it? It doesn't bring any additional security.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Thu Feb  7 22:29:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2013 21:29:58 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1360272598.1.0.81362111693.issue17137@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The "import random" isn't needed in your patch.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17137>
_______________________________________

From report at bugs.python.org  Thu Feb  7 22:37:22 2013
From: report at bugs.python.org (Catalin Iacob)
Date: Thu, 07 Feb 2013 21:37: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: <1360273042.06.0.0200716978677.issue6972@psf.upfronthosting.co.za>


Catalin Iacob added the comment:

There are 2 issues with the documentation changes introduced by these patches.

1. for 2.7, the note added by the doc patch is in the wrong place, at the setpassword method instead of the extract or extractall method

2. for 3.x the "Never extract archives from untrusted sources..." warning got removed but it's still useful for users that read the documentation online and therefore get the updated docs but haven't updated Python to the latest patch release and therefore don't have the fix. For example, anybody reading the docs for 3.2 or 3.3 today doesn't see that extractall is dangerous and there is no released Python containing the fix so by all practical means extractall is still dangerous today.

To address point 2, I think the warning should be kept with an extra mention regarding exact version where it got fixed so that, when reading the documentation, everybody can assess exactly whether extractall is safe for them to use or not.

I can't reopen the bug since I don't have tracker privileges but since it's a security issue I think it's important for these to get addressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Thu Feb  7 22:52:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Feb 2013 21:52:49 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1360273969.82.0.489293862124.issue6972@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Thu Feb  7 22:54:28 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 07 Feb 2013 21:54:28 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1360274068.65.0.743340596973.issue6972@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

reopening as documentation mixups remain to be fixed.

----------
nosy: +benjamin.peterson, larry
priority: high -> release blocker
resolution: fixed -> 
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Thu Feb  7 23:18:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Feb 2013 22:18:39 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <3Z2DSZ2NPczScx@mail.python.org>


Roundup Robot added the comment:

New changeset 3b316ea5aa82 by Victor Stinner in branch '3.3':
Issue #17137: When an Unicode string is resized, the internal wide character
http://hg.python.org/cpython/rev/3b316ea5aa82

New changeset c10a3ddba483 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17137: When an Unicode string is resized, the internal wide
http://hg.python.org/cpython/rev/c10a3ddba483

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17137>
_______________________________________

From report at bugs.python.org  Fri Feb  8 00:02:47 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 07 Feb 2013 23:02:47 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360278167.11.0.16356098498.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Strike that patch, this needs a little more love than during-my-first-coffee-of-the-day work. I'll work on it more and submit a follow-up for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17145>
_______________________________________

From report at bugs.python.org  Fri Feb  8 01:35:14 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Feb 2013 00:35:14 +0000
Subject: [issue17037] Use a test.support helper to wrap the PEP 399 boilerplate
In-Reply-To: <1359179328.16.0.396710574984.issue17037@psf.upfronthosting.co.za>
Message-ID: <1360283714.41.0.708664418367.issue17037@psf.upfronthosting.co.za>


Eric Snow added the comment:

Fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17037>
_______________________________________

From report at bugs.python.org  Fri Feb  8 02:31:18 2013
From: report at bugs.python.org (umedoblock)
Date: Fri, 08 Feb 2013 01:31:18 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
Message-ID: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>


New submission from umedoblock:

I'd like to parse _('?????').
However pygettext.py doesn't parse _('?????').
pygettext.py said me 'IndexError'.
now I attached pygettext.py.patch to fix a bug.
I show you command history.

$ pygettext.py -o - --verbose konnichiha.py
...
#: konnichiha.py:6
msgid "konnichiha"
msgstr ""

#: konnichiha.py:7
Traceback (most recent call last):
  File "/home/umetaro/local/bin/pygettext.py", line 664, in <module>
    main()
  File "/home/umetaro/local/bin/pygettext.py", line 657, in main
    eater.write(fp)
  File "/home/umetaro/local/bin/pygettext.py", line 497, in write
    print('msgid', normalize(k), file=fp)
  File "/home/umetaro/local/bin/pygettext.py", line 250, in normalize
    s = '"' + escape(s) + '"'
  File "/home/umetaro/local/bin/pygettext.py", line 236, in escape
    s[i] = escapes[ord(s[i])]
IndexError: list index out of range

please use pygettext.py.patch.

$ pygettext.py -o - --verbose konnichiha.py
...
#: konnichiha.py:6
msgid "konnichiha"
msgstr ""

#: konnichiha.py:7
msgid "?????"
msgstr ""

----------
components: Demos and Tools
files: konnichiha.py
messages: 181651
nosy: umedoblock
priority: normal
severity: normal
status: open
title: Tools/i18n/pygettext.py doesn't parse unicode string.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file28991/konnichiha.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 02:32:34 2013
From: report at bugs.python.org (umedoblock)
Date: Fri, 08 Feb 2013 01:32:34 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360287154.79.0.4209009065.issue17156@psf.upfronthosting.co.za>


Changes by umedoblock <umedoblock at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file28992/pygettext.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 02:37:15 2013
From: report at bugs.python.org (umedoblock)
Date: Fri, 08 Feb 2013 01:37:15 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360287435.23.0.993119790637.issue17156@psf.upfronthosting.co.za>


umedoblock added the comment:

TOO SORRY.

pygettext.py.patch 	umedoblock, 2013-02-08 10:32

is wrong a patch.

please forget it.

----------
Added file: http://bugs.python.org/file28993/pygettext.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 02:41:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 01:41:53 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360287713.66.0.280128899202.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am working on patch(es) now, against 3.2. But to make 2.7.4/3.2.4, I'd like you to apply, as I am not currently set up to do so properly.
I may do separate patches for doc, lib, module, and others, so none is overwhelming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 04:01:26 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Feb 2013 03:01:26 +0000
Subject: [issue13355] random.triangular error when low = high=mode
In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za>
Message-ID: <1360292486.17.0.504772586635.issue13355@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll look at the patch shortly.  At first glance, it looks over-engineered to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13355>
_______________________________________

From report at bugs.python.org  Fri Feb  8 04:38:56 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 08 Feb 2013 03:38:56 +0000
Subject: [issue17152] Array module should support "boolean" natively
In-Reply-To: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>
Message-ID: <1360294736.73.0.635666612129.issue17152@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

1 byte = 8 bools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17152>
_______________________________________

From report at bugs.python.org  Fri Feb  8 04:41:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 03:41:19 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360294879.68.0.830139941054.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

First batch for Lib/*. Separate 3.2 and 2.7 files as the later required deletion of concurrent patch and adjustment of tix and turtle paths.

----------
keywords: +patch
Added file: http://bugs.python.org/file28994/Lib14707-27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 04:44:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 03:44:33 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360295073.71.0.853161688017.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

These of course do not contain patches for new dups introduced in 3.3. I kept a record and will later make a separate patch for those. (I hope before 3.3.1).

----------
Added file: http://bugs.python.org/file28995/Lib14707-32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 05:02:50 2013
From: report at bugs.python.org (Matt Joiner)
Date: Fri, 08 Feb 2013 04:02:50 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1360296170.0.0.280381043722.issue4331@psf.upfronthosting.co.za>


Matt Joiner added the comment:

What's preventing this from being committed and closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Fri Feb  8 05:19:05 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 08 Feb 2013 04:19:05 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360297145.41.0.939103478531.issue16795@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16795>
_______________________________________

From report at bugs.python.org  Fri Feb  8 07:18:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Feb 2013 06:18:35 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <3Z2R6L0ZLjzSf0@mail.python.org>


Roundup Robot added the comment:

New changeset d73fb6b06891 by Gregory P. Smith in branch '2.7':
Issue #6972: fix the documentation mis applied patch.
http://hg.python.org/cpython/rev/d73fb6b06891

New changeset 1c2d41850147 by Gregory P. Smith in branch '3.2':
Issue #6972: keep the warning about untrusted extraction and mention
http://hg.python.org/cpython/rev/1c2d41850147

New changeset 5fbca37de9b1 by Gregory P. Smith in branch '3.3':
Issue #6972: keep the warning about untrusted extraction and mention
http://hg.python.org/cpython/rev/5fbca37de9b1

New changeset f5e3f2f0fe79 by Gregory P. Smith in branch 'default':
Issue #6972: keep the warning about untrusted extraction and mention
http://hg.python.org/cpython/rev/f5e3f2f0fe79

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Fri Feb  8 07:19:09 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 08 Feb 2013 06:19:09 +0000
Subject: [issue6972] zipfile.ZipFile overwrites files outside destination path
In-Reply-To: <1253657452.09.0.588869541997.issue6972@psf.upfronthosting.co.za>
Message-ID: <1360304349.06.0.719742386733.issue6972@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Fri Feb  8 07:39:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 06:39:49 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360305589.62.0.354655404688.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

C module files. I cannot find python-gdb.py.

----------
Added file: http://bugs.python.org/file28996/Mod14707-27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 07:40:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 06:40:14 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360305614.1.0.537287399049.issue17047@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Added file: http://bugs.python.org/file28997/Mod14707-32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 08:24:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 07:24:10 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360308250.06.0.25752956703.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A majority of doc glitches listed here are new in 3.3. I believe someone make a similar de-double patch some time ago. I put the other 2.7/3.2 fixes here so this is it for those two versions.

----------
Added file: http://bugs.python.org/file28998/Doc17047-27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 08:24:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 07:24:33 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360308273.94.0.518147844306.issue17047@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Added file: http://bugs.python.org/file28999/Doc17047-32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 08:55:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 07:55:02 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360310102.3.0.66461244851.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is for 3.3 and 3.4. It is against tip, but should apply to 3.3 since the lines changed were as reported here for 3.3.

----------
Added file: http://bugs.python.org/file29000/Issue17047-34.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 09:18:57 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Feb 2013 08:18:57 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360311537.46.0.535045432836.issue17128@psf.upfronthosting.co.za>


Ned Deily added the comment:

After spending some time on this, I'm downgrading this from release blocker status.  First, no one has yet identified any immediate need for openssl 1.0.x features to support possible PyPI enhancements, which was my original concern.  Second, since the openssl build system does not support OS X universal builds or SDKs and is not autoconf-based, it does not fit well into the current OS X installer build process.  I have a working first cut of building the libs but there is more to do.  Third, there is the open issue of how to make root certs available.  Ronald, I'm probably missing something obvious here but I don't see which Apple patch you are referring to.  Can you elaborate?

There is also the issue of government export restrictions that seems to always come up with crypto software.  AFAICT, as of a couple of years ago, there is no longer any restriction on shipping openssl binaries with any encryption algorithm from the US to any other country.  There are still a few well-known patent issue which seem easy to avoid.  But I am not a lawyer.
 
Unless someone objects, I'm going to treat this as a new feature for now and, once ready, we can re-examine backporting.

----------
priority: release blocker -> high
versions:  -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17128>
_______________________________________

From report at bugs.python.org  Fri Feb  8 09:56:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 08:56:04 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360313764.02.0.984963517465.issue17156@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28992/pygettext.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 10:20:10 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 09:20:10 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1360315210.97.0.9513374025.issue4331@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
versions: +Python 3.3, Python 3.4 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Fri Feb  8 10:34:07 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Feb 2013 09:34:07 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360316047.24.0.16770838679.issue17128@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

See also: issue 15740


A version of OpenSSL as included in some versions of OSX can be downloaded from <http://opensource.apple.com/tarballs/OpenSSL098/>, as mentioned in issue 15740 the versions as included in the most recent OS updates doesn't seem to be there.

I've downloaded OpenSSL098-35.1 and that includes files ./src/crypto/x509/x509_vfy_apple.h and ./src/crypto/x509/x509_vfy_apple.c which implement the behavior I mentioned earlier: first try to verify using the default OpenSSL mechanism, then verify using the TrustEvaluationAgent. 

Now that I look at that code again: we can't extract that code and use it to patch upstream OpenSSL, the TrustEvaluationAgent framework is a private framework and hence off limits.

It is probably possible to reimplement the same feature using public APIs, but that's new development and should be off-limits for a bugfix release (and isn't something that can be done very soon without risking to introduce new bugs in security-related code).

Direct link to the source code I mentioned: http://opensource.apple.com/source/OpenSSL098/OpenSSL098-32/src/crypto/x509/x509_vfy_apple.c, http://opensource.apple.com/source/OpenSSL098/OpenSSL098-32/src/crypto/x509/x509_vfy_apple.h


A blog about this feature by the one of the curl developers: http://daniel.haxx.se/blog/2011/11/05/apples-modified-ca-cert-handling-and-curl/


P.S. Apple doesn't exactly make it easy to find this information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17128>
_______________________________________

From report at bugs.python.org  Fri Feb  8 11:18:53 2013
From: report at bugs.python.org (Michael Stahn)
Date: Fri, 08 Feb 2013 10:18:53 +0000
Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1360318733.71.0.111066004951.issue11448@psf.upfronthosting.co.za>


Michael Stahn added the comment:

I thought the same as Ryan when reading the API. The best way would have been to call "set_tunnel" -> "set_proxy" and to implement the behaviour you expect on this: setting a proxy. There are some more places at this code which are not quite clear eg:

def putheader(self, header, *values):
  """Send a request header line to the server.

Here the methodname "putheader" is ok but the documentation is misleading: this just adds a new header-line to the buffer, it won't send it directly. But that's the problem with naming in APIs: once it's in the code you won't get it changed that fast..

----------
nosy: +m1kes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11448>
_______________________________________

From report at bugs.python.org  Fri Feb  8 11:19:47 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Fri, 08 Feb 2013 10:19:47 +0000
Subject: [issue17153] tarfile extract fails when Unicode in pathname
In-Reply-To: <1360255401.83.0.937643629633.issue17153@psf.upfronthosting.co.za>
Message-ID: <1360318787.4.0.42871378445.issue17153@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy: +hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17153>
_______________________________________

From report at bugs.python.org  Fri Feb  8 11:45:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 10:45:52 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360320352.56.0.110129630978.issue17156@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 12:37:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 11:37:12 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360323432.72.0.563989610494.issue17149@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, I was wrong. I missed that z is in range -1..1. Original report is invalid, random.vonmisesvariate() always returns a value on the full circle.

However there is some inconsistency. For small kappa (<= 1e-6) result range is 0 to 2pi, for other kappa it is (mu%2pi)-pi to (mu%2pi)+pi. For consistency we should either shift a range for small kappa:

        if kappa <= 1e-6:
            return (mu % TWOPI) - _pi + TWOPI * random()

or normalize a result in another case:

        if u3 > 0.5:
            theta = (mu + _acos(f)) % TWOPI
        else:
            theta = (mu - _acos(f)) % TWOPI

----------
title: random.vonmisesvariate() returns a value only on the half-circle -> random.vonmisesvariate() results range is inconsistent for small and not small kappa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Fri Feb  8 12:42:34 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 08 Feb 2013 11:42:34 +0000
Subject: [issue14516] test_tools assumes BUILDDIR=SRCDIR
In-Reply-To: <1333707730.38.0.628831175594.issue14516@psf.upfronthosting.co.za>
Message-ID: <1360323754.61.0.517397410152.issue14516@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I've closed the issue because I can no longer reproduce the issue, the changesets mentioned by Ned have fixed the problem.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14516>
_______________________________________

From report at bugs.python.org  Fri Feb  8 14:29:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 13:29:47 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360330187.9.0.279681007824.issue17156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 3.x, which correctly detects input file encoding and correctly escapes non-ascii output files if -E specified (and only if it specified).

For 2.7 we should just negate an argument for make_escapes.

----------
components: +Unicode
nosy: +ezio.melotti, loewis
stage:  -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29001/pygettext_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 14:44:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 13:44:55 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360331095.07.0.028869805938.issue17156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 2.7. pygettext doesn't try to detect input encoding and transparently works with bytes, but it no longer escapes non-ascii bytes if -E is not specified.

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file29002/pygettext_unicode-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:01:12 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Feb 2013 14:01:12 +0000
Subject: [issue17116] xml.parsers.expat.(errors|model) don't set the
	__loader__ attribute
In-Reply-To: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za>
Message-ID: <1360332072.89.0.825581671417.issue17116@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +__loader__ = None should be fine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17116>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:06:31 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:06:31 +0000
Subject: [issue17157] issubclass should accept iterables
Message-ID: <1360332391.97.0.255952166351.issue17157@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
nosy: kushou, ramchandra.apte
priority: normal
severity: normal
status: open
title: issubclass should accept iterables
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:06:55 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:06:55 +0000
Subject: [issue17157] issubclass should accept iterables
Message-ID: <1360332415.77.0.0277381671025.issue17157@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:07:33 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:07:33 +0000
Subject: [issue17157] issubclass should accept iterables
Message-ID: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

kushou pointed this out on #python-dev

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:08:02 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:08:02 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360332482.19.0.466231055345.issue17157@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: issubclass should accept iterables -> issubclass() should accept iterables in 2nd arg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:10:02 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:10:02 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360332602.22.0.361096855395.issue17157@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:12:24 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:12:24 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360332744.36.0.764979004659.issue17157@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
status: languishing -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:24:19 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:24:19 +0000
Subject: [issue17158] help() module searcher text improvement
Message-ID: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

help("modules spam") prints out "Here is a list of matching modules.  Enter any module name to get more help." before it has even found the modules. This gives the impression that it has found the modules yet it hasn't printed the modules yet. I would suggest that it prints "Searching for the matching modules..." without the newline and then once the matching modules have been found prints "done." (End result will have "Searching for the matchine modules... done." Then it should print "Here is a list of matching modules. Enter any ..."

----------
components: Interpreter Core
messages: 181671
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: help() module searcher text improvement
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:24:57 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 08 Feb 2013 14:24:57 +0000
Subject: [issue17158] help() module searcher text is misleading
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <1360333497.83.0.443856409152.issue17158@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: help() module searcher text improvement -> help() module searcher text is misleading

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Fri Feb  8 15:55:26 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Feb 2013 14:55:26 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360335326.41.0.642955053204.issue17157@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

What's the use case for this?  issubclass already accept tuples, just like isinstance:

>>> issubclass(bool, (int, float))
True

----------
nosy: +mark.dickinson
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Fri Feb  8 16:02:24 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Feb 2013 15:02:24 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360335744.86.0.727435670799.issue17149@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Agreed that this seems inconsistent.  The current normalization for non-small kappa is a little odd:  e.g, if mu is small and negative (-0.01, say), then we get a range that goes roughly from pi to 3*pi, when a range from -pi to pi would have made more sense.

Any of (1) returning values in the range [mu - pi, mu+pi], (2) returning values in the range [-pi, pi], or (3) returning values in the range [0, 2*pi] would seem reasonable.

Unassigning (the original problem is solved by not being there!)

----------
assignee: mark.dickinson -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Fri Feb  8 16:20:30 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Feb 2013 15:20:30 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
Message-ID: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

I can't see a reason why Signature.from_function() should explicitly check the type of the object being passed in. As long as the object has all required attributes, it should be accepted.

This is specifically an issue with Cython compiled functions, which are not Python functions but look the same.

----------
components: Library (Lib)
messages: 181674
nosy: scoder
priority: normal
severity: normal
status: open
title: Remove explicit type check from inspect.Signature.from_function()
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Fri Feb  8 16:49:07 2013
From: report at bugs.python.org (Zearin)
Date: Fri, 08 Feb 2013 15:49:07 +0000
Subject: [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1360338547.52.0.728721330274.issue15580@psf.upfronthosting.co.za>


Zearin added the comment:

I agree that globally linking all occurrences of True/False/None is overkill. 

Perhaps linking the first occurrence per webpage would be a good standard?

----

However, I *strongly* believe that:

1. The words be capitalized
2. The words should be marked up as ``True``, ``False``, or ``None``

Of course, these two items only apply when appropriate.  But after attempting this myself in #17074, I can say with certainty that this is the case *most of the time*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15580>
_______________________________________

From report at bugs.python.org  Fri Feb  8 16:50:07 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Feb 2013 15:50:07 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360338607.6.0.769395227225.issue17159@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

This patch removes the type check from Signature.from_function() and cleans up the type tests in signature() to use whatever the inspect module defines as isfunction() and isbuiltin(), so that it becomes properly monkey-patchable.

It also adds a test that makes sure the signature relies only on the four relevant special attributes, not on the type of the object being inspected.

----------
keywords: +patch
nosy: +benjamin.peterson, ncoghlan
Added file: http://bugs.python.org/file29003/inspect_sig.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Fri Feb  8 16:55:24 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 15:55:24 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360338924.48.0.966839235364.issue17159@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Patch looks good, but I?m worried about the change from TypeError to AttributeError in a stable version.

Could you also make clear that all function-like objects are accepted in the doc?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Fri Feb  8 17:02:55 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Feb 2013 16:02:55 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360339375.14.0.567457486881.issue17159@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

The method doesn't seem to be documented, and I'm not sure if the docstring really benefits from this lengthy addition. Anyway, here's a patch that includes the docstring update.

The exception could be kept the same if we catch an AttributeError and explicitly raise a TypeError instead.

----------
Added file: http://bugs.python.org/file29004/inspect_sig_with_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Fri Feb  8 17:04:34 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Fri, 08 Feb 2013 16:04:34 +0000
Subject: [issue4483] Error to build _dbm module during make
In-Reply-To: <1228170912.0.0.0953990219054.issue4483@psf.upfronthosting.co.za>
Message-ID: <1360339474.13.0.851120628267.issue4483@psf.upfronthosting.co.za>


ddvento at ucar.edu added the comment:

This is still an issue in Python 2.7.3 but there is a quick manual workaround. I know it's trivial and one can easily develop it from what is said in the thread or maybe looking at the patches, but for reference this is a nice recipe as oppose to digging through many messages

1) build as usual, but redirect the output/error stream in a file, for example if your shell is bash (I find this to always be a good idea):

make > make.log 2>&1

2) Towards the end of make.log there will be the following message. If you don't see this message, you don't have this problem, but possibly a different one:

Failed to build these modules:
dbm


3) execute
grep "\-o .*/dbmmodule.o" make.log

This will find a compiler line. Cut, paste and and execute that command

4) grep "\-o .*/dbm.so" make.log

This will find another compiler line. Cut, paste and and execute that command, ADDING (this is essential) -lgdbm_compat

5) (optional) you may want to remove dbm_failed.so (in the same directory where the previous bullet creates dbm.so)

----------
nosy: +ddvento at ucar.edu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4483>
_______________________________________

From report at bugs.python.org  Fri Feb  8 17:10:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Feb 2013 16:10:40 +0000
Subject: [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1360339840.37.0.904137088926.issue15580@psf.upfronthosting.co.za>


R. David Murray added the comment:

They should be capitalized and marked up as code if they refer to the objects.  If they refer only to (to use bad english) the truthiness or falsiness of the value in question, then they should be lower case and not marked up as code.  Quickly scanning the start of the patch in 17074, about half the changes to true/false markup were incorrect.

Ideally we should never have True unless it is marked up as ``True`` (same for False), but there are *many* cases in the docs where true or false is correct.  My guess would be that those cases outnumber the cases where ``True`` or ``False`` is correct, but I haven't tried to measure :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15580>
_______________________________________

From report at bugs.python.org  Fri Feb  8 17:15:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 16:15:23 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360340123.0.0.640963377275.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I cannot find python-gdb.py.

This is a copy of Tools/gdb/libpython.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Fri Feb  8 17:45:54 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Fri, 08 Feb 2013 16:45:54 +0000
Subject: [issue17160] test_urllib2net fails
Message-ID: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

test_urllib2net fails as follows. Looking at test_urllib2net.py" line 165 does not reveal anything interesting to me

./python Lib/test/regrtest.py -uall -v test_urllib2net
== CPython 2.7.3 (default, Feb 8 2013, 08:28:21) [GCC 4.7.2]
==   Linux-2.6.32-220.13.1.el6.x86_64-x86_64-with-redhat-6.2-Santiago little-endian
==   /glade/scratch/ddvento/build/Python-2.7.3-westmere/build/test_python_7544
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
test_urllib2net
test_custom_headers (test.test_urllib2net.OtherNetworkTests) ... ok
test_file (test.test_urllib2net.OtherNetworkTests) ... ok
test_fileno (test.test_urllib2net.OtherNetworkTests) ... ok
test_ftp (test.test_urllib2net.OtherNetworkTests) ... ok
test_sites_no_connection_close (test.test_urllib2net.OtherNetworkTests) ... ok
test_urlwithfrag (test.test_urllib2net.OtherNetworkTests) ... FAIL
test_close (test.test_urllib2net.CloseSocketTest) ... ok
test_ftp_basic (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_default_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_no_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_ftp_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_basic (test.test_urllib2net.TimeoutTest) ... ok
test_http_default_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_no_timeout (test.test_urllib2net.TimeoutTest) ... ok
test_http_timeout (test.test_urllib2net.TimeoutTest) ... ok

======================================================================
FAIL: test_urlwithfrag (test.test_urllib2net.OtherNetworkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere/Lib/test/test_urllib2net.py", line 165, in test_urlwithfrag
    "http://docs.python.org/glossary.html#glossary")
AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary'

----------------------------------------------------------------------
Ran 15 tests in 14.684s

FAILED (failures=1)
test test_urllib2net failed -- Traceback (most recent call last):
  File "/glade/scratch/ddvento/build/Python-2.7.3-westmere/Lib/test/test_urllib2net.py", line 165, in test_urlwithfrag
    "http://docs.python.org/glossary.html#glossary")
AssertionError: 'http://docs.python.org/2/glossary.html' != 'http://docs.python.org/glossary.html#glossary'

1 test failed:
    test_urllib2net

----------
components: Tests
messages: 181682
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: test_urllib2net fails
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17160>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:07:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Feb 2013 17:07:20 +0000
Subject: [issue17160] test_urllib2net fails
In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za>
Message-ID: <1360343240.82.0.00282777628457.issue17160@psf.upfronthosting.co.za>


R. David Murray added the comment:

It passes on all our buildbots, and for me locally.  Is it possible there is a proxy server between you and python.org that is changing the url returned?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17160>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:13:21 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Fri, 08 Feb 2013 17:13:21 +0000
Subject: [issue17161] make install misses the man and the static library
Message-ID: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>


New submission from ddvento at ucar.edu:

This is for python 2.7.3 built with 

0) ./configure --enable-shared --with-system-expat

1) I need both static and shared object, however libpython2.7.a is not copied in the installation target lib. Is this on purpose, or am I missing a flag in configure?

2) In share/man/man1/ there are two issues:
2a) the manual is for 2.7.1 instead of 2.7.3
2b) the man command looks for a python.1 file, therefore one must issue:
ln -s python2.7.1 python.1

----------
components: Installation
messages: 181684
nosy: ddvento at ucar.edu
priority: normal
severity: normal
status: open
title: make install misses the man and the static library
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:18:33 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 17:18:33 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360343913.28.0.26081921778.issue17161@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:21:56 2013
From: report at bugs.python.org (ddvento@ucar.edu)
Date: Fri, 08 Feb 2013 17:21:56 +0000
Subject: [issue17160] test_urllib2net fails
In-Reply-To: <1360343240.82.0.00282777628457.issue17160@psf.upfronthosting.co.za>
Message-ID: <5115343B.7010402@ucar.edu>


ddvento at ucar.edu added the comment:

Yes, it is possible, do you want me to investigate more with my network 
people?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17160>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:27:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Feb 2013 17:27:20 +0000
Subject: [issue17160] test_urllib2net fails
In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za>
Message-ID: <1360344440.97.0.394611273702.issue17160@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think only if you want to.  As far as we are concerned the test is correct and passing.  (And this kind of thing is the reason that that test set is only run when -uall is specified.)

I'm going to close the issue.  If you do investigate, and feel that you've found a real bug, please reopen it.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17160>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:40:34 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 17:40:34 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360345234.36.0.923601007047.issue17108@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I knew that a package would win over a module, but an initless package does not?  Yuck :(

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17108>
_______________________________________

From report at bugs.python.org  Fri Feb  8 18:44:16 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Feb 2013 17:44:16 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360345456.61.0.56454718533.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

It has to be that way to preserve backward compatibility, since IIUC before the PEP there was no such thing as "an initless package", it was just a directory that was ignored by import.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17108>
_______________________________________

From report at bugs.python.org  Fri Feb  8 19:27:15 2013
From: report at bugs.python.org (Bradley Froehle)
Date: Fri, 08 Feb 2013 18:27:15 +0000
Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc
Message-ID: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

I tried to implement a custom extension type using PyType_FromSpec and Py_LIMITED_API but couldn't implement tp_dealloc:

static void mytype_dealloc(mytypeobject *self)
{
    // free some fields in mytypeobject
    Py_TYPE(self)->tp_free((PyObject *) self); // XXX
}

The line marked XXX will not compile in Py_LIMITED_API because there is no access to the fields of PyTypeObject.  There doesn't seem to be any function in the API which just calls tp_free.

I suggest the addition of an API function (to be included in Py_LIMITED_API):

void
PyType_GenericDealloc(PyObject *self)
{
    Py_TYPE(self)->tp_free(self);
}

----------
messages: 181689
nosy: bfroehle
priority: normal
severity: normal
status: open
title: Py_LIMITED_API needs a PyType_GenericDealloc
type: enhancement
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17162>
_______________________________________

From report at bugs.python.org  Fri Feb  8 19:30:16 2013
From: report at bugs.python.org (Bradley Froehle)
Date: Fri, 08 Feb 2013 18:30:16 +0000
Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc
In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za>
Message-ID: <1360348216.75.0.220868702722.issue17162@psf.upfronthosting.co.za>


Bradley Froehle added the comment:

I should mention that essentially what I'm advocating is renaming and exposing `object_dealloc` in Objects/typeobject.c.

The proper name is not obvious to me... should it be PyObject_GenericDealloc since it acts on objects? Or PyType_GenericDealloc since it will be stuck into one of the PyTypeObject slots?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17162>
_______________________________________

From report at bugs.python.org  Fri Feb  8 19:46:47 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Feb 2013 18:46:47 +0000
Subject: [issue17160] test_urllib2net fails
In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za>
Message-ID: <1360349207.3.0.0910063264265.issue17160@psf.upfronthosting.co.za>


Ned Deily added the comment:

The test is failing because of a restructuring of the docs.python.org website.  The test was changed on 2012-10-28 to use the new URL (923ca6d73bad and friends).  That change will be in the next set of maintenance releases including 2.7.4 real soon now.

----------
nosy: +ned.deily
resolution: works for me -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17160>
_______________________________________

From report at bugs.python.org  Fri Feb  8 19:51:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Feb 2013 18:51:55 +0000
Subject: [issue17162] Py_LIMITED_API needs a PyType_GenericDealloc
In-Reply-To: <1360348035.19.0.130949262051.issue17162@psf.upfronthosting.co.za>
Message-ID: <1360349515.73.0.56400921733.issue17162@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17162>
_______________________________________

From report at bugs.python.org  Fri Feb  8 19:54:55 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Feb 2013 18:54:55 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360349695.73.0.644540366428.issue17108@psf.upfronthosting.co.za>


Eric Snow added the comment:

Deprecating pkg/__init__.py and having pkg.py coexist with pkg/ was on the table in an earlier proposal (PEP 402).  In that case pkg/__init__.py would have been tried first for backward compatbility (until eliminated in Python 4 or whenever).  PEP 420 (namespace packages) took a more conservative approach, leaving the question of pkg.py coexisting with pkg/ on the table.

I still find the idea appealing of replacing pkg/__init__.py with simply pkg.py + pkg/.  PEP 402 outlines the rationale pretty well.  Considering that PEP 420 made __init__.py-less packages legal, deprecating __init__.py isn't a huge leap.  The challenge of deciding if a directory is a package is tricky when there is not marker (like __init__.py is), but PEP 420 already tackled that for the most part.

Regardless, it would definitely require a new PEP (likely derived from 402) and some caution, especially since you could argue that people may be relying on the current precedence policy.  It would also take a little bit of work for the implementation, and a bunch of work to make sure the stdlib is happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17108>
_______________________________________

From report at bugs.python.org  Fri Feb  8 20:37:33 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 08 Feb 2013 19:37:33 +0000
Subject: [issue17163] Fix test discovery for test_file.py
Message-ID: <1360352253.75.0.044866485302.issue17163@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: Tests
files: test_file_discovery.diff
keywords: patch
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_file.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29005/test_file_discovery.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17163>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:04:05 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 08 Feb 2013 20:04: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: <1360353845.71.0.0898588719532.issue6972@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6972>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:16:01 2013
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 08 Feb 2013 20:16:01 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1360354561.43.0.644635584579.issue17032@psf.upfronthosting.co.za>


Ram Rachum added the comment:

I made a patch. Is it okay? (I don't normally use Mercurial nor work with patches.)

----------
keywords: +patch
Added file: http://bugs.python.org/file29006/cpython_patch1of1_8e9346e7ae87.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:17:22 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:17:22 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1360354642.18.0.0420153455348.issue17032@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Patch looks good.  Does the test suite still pass?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:18:56 2013
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 08 Feb 2013 20:18:56 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1360354736.91.0.544490821943.issue17032@psf.upfronthosting.co.za>


Ram Rachum added the comment:

I don't program C at all. I have no idea how to compile Python or run the test suite. It took me half an hour just to produce this patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:20:44 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:20:44 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1360354844.75.0.773688634583.issue17032@psf.upfronthosting.co.za>


?ric Araujo added the comment:

If you?re using a programmer-friendly OS compiling is not hard.  See http://docs.python.org/devguide for instructions.  Otherwise somebody else will test the patch.  Thanks for your contribution!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:26:42 2013
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 08 Feb 2013 20:26:42 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1360355202.6.0.374244775554.issue17032@psf.upfronthosting.co.za>


Ram Rachum added the comment:

I think I'll go for option 2, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:52:42 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:52:42 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360356762.58.0.788455758707.issue17130@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:55:25 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:55:25 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360356925.88.0.2798176844.issue17143@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Great patch with tests.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:57:00 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:57:00 +0000
Subject: [issue17147] BytesIO should be mentioned in SpooledTemporaryFile
	documentation
In-Reply-To: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>
Message-ID: <1360357020.8.0.418148833409.issue17147@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Typos: whenewer ? whether and has specified ? was specified

Otherwise good to commit.

----------
nosy: +eric.araujo
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17147>
_______________________________________

From report at bugs.python.org  Fri Feb  8 21:59:50 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:59:50 +0000
Subject: [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1360357190.79.0.585424757224.issue17155@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Hm the correct way to use exception is:

    except Something:
        logger.exception('problem while doing X')

i.e. this is a generic unicode-to-str-with-default-encoding problem, not something specific to logging.

Vinay, do you think logging should do something smarter than calling str when passed non-str objects?

----------
nosy: +eric.araujo, vinay.sajip
title: Logging throwing UnicodeEncodeError exception -> logging can raise UnicodeEncodeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17155>
_______________________________________

From report at bugs.python.org  Fri Feb  8 22:15:46 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Feb 2013 21:15:46 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360358146.49.0.760842091453.issue17161@psf.upfronthosting.co.za>


Ned Deily added the comment:

It would be helpful in the future if you would open separate issues for each problem you report.  To address your points:

1) For unix-y builds, the static library along with other files needed for embedding Python are installed in the standard Python library directory in the config subdirectory (e.g. /usr/lib/python2.7/config).

2a) I don't see any indication of point version number in the currently generated man page: it simply refers to "2.7".  The file name ".1" in the file name refers to what man section the man page belongs in, e.g. "man 1 python2.7".

2b) The Python makefile was changed (c208f5c1e4fe) between the 2.6 and 2.7 releases to install the versioned man page.  I am guessing that it was an oversight that the unversioned man page install was dropped.  Perhaps Matthias can shed some light on this.  The man page installs should likely follow the "alt" scheme, meaning there should be both "altmaninstall" and "maninstall" targets called respectively from "altinstall" and "install", with the latter installing the unversioned link.

----------
nosy: +doko, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Fri Feb  8 22:20:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 21:20:10 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360358410.51.0.196545243727.issue17159@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My first concern is whether this is a behavior issue that can be fixed in the next 3.3 release or an enhancement request that should wait for 3.4.

If Signature.from_function were documented in the manual with the current limitation, this issue would definitely be an enhancement request. But it is not even mentioned in the manual. I presume this is intentional as it is pretty clearly not meant to be called directly but only from signature(). Perhaps its should have been given a leading underscore to mark it as private.

The docstring does say 'python function'. However, its type check is redundant with the guard in signature before its call. So in normal usage, it can never fail. Moreover, the limitation is completely unnecessary even for pure Python code, as shown the the ease of creating a funclike class for the test. It is contrary to Python policy and stdlib practice. So in a sense, it is a bug.

My conclusion: the proposed change is an enhancement bugfix (or bugfix enhancement?) for an undocumented private function. So I think it ok for 3.3, but would not blame anyone who disagreed.

---
I agree with ?ric that the exception should not be changed, not just because it would be a change, but because is would be a wrong change. Signature.from_function(42) *is* a type error. The fact that the type error is detected by attribute rather than by class is not relevant to external callers. So please wrap the
   # Parameter information.
section of the code with try: except AttributeError, as a substitute for the current too-narrow type check. Leave the message as it, except possibly add the object that fails:
 "{} is not a function".format(func)

---
The change to signature has no effect on .from_function but makes it consistent with the rest of the module.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Fri Feb  8 22:23:23 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Fri, 08 Feb 2013 21:23:23 +0000
Subject: [issue17164] MozillaCookieJar does not handle session cookies
Message-ID: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za>


New submission from Piotr Dobrogost:

It seems there's no information on how should session cookies be stored in the Netscape/Mozilla's cookies.txt file with regard to expiry time - see http://www.cookiecentral.com/faq/#3.5 Maybe Netscape has not been saving such cookies at all thus this lack of specification? Nevertheless, both wget and curl use 0 as expiry time to denote session cookies; it works both when reading cookies from file and writing to file. However Python's MozillaCookieJar's class uses empty string for the same purpose which makes it incompatible both with wget and curl - see http://hg.python.org/cpython/file/bd8afb90ebf2/Lib/http/cookiejar.py#l2027

I propose to make a change in implementation of MozillaCookieJar class and treat cookies with 0 set as expiry time as session cookies both when reading from a file and writing to a file.

Motivation for this bug report comes from the following question on Stack Overflow - http://stackoverflow.com/q/14742899/95735

----------
components: Library (Lib)
messages: 181703
nosy: piotr.dobrogost
priority: normal
severity: normal
status: open
title: MozillaCookieJar does not handle session cookies
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17164>
_______________________________________

From report at bugs.python.org  Fri Feb  8 22:44:12 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Feb 2013 21:44:12 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360359852.12.0.232131550721.issue17159@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Fine with me. Updated patch attached.

----------
Added file: http://bugs.python.org/file29007/inspect_sig_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Sat Feb  9 00:07:22 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 08 Feb 2013 23:07:22 +0000
Subject: [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1360364842.04.0.471800306433.issue17155@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

It is by design that logging accepts arbitrary objects, rather than just strings, see

docs.python.org/howto/logging.html#arbitrary-object-messages

and, as documented, the instance's __str__ will be called by logging calling str() on the instance. If people are being lazy and doing logging.exception(exc) where exc is an exception instance, then they need to change their code. Recall that on Python 2.x, just doing a + b can trigger a UnicodeError because of implicit bytes->Unicode conversions which use ASCII as a default (this is just how Python 2.x works - nothing to do with logging). An arbitrary exception's str() method may or may not be smart with respect to this sort of behaviour. I think the answer is for people to be more aware of Unicode issues and how Python 2.x deals with mixed Unicode and byte data. If the _fmt string you are referring to is the Formatter instance attribute, you can control that by passing whatever you want to the Formatter - a Unicode string, if you wish.

The normal logging exception handling is as per ?ric's example (though of course you can have placeholders and arguments passed to the exception call, as in

    logger.exception('Problem with %r', 'specific data')

I'm closing as invalid, because the example you quoted as working is how people are supposed to use it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17155>
_______________________________________

From report at bugs.python.org  Sat Feb  9 00:13:53 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Feb 2013 23:13:53 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360365233.83.0.457330759065.issue17161@psf.upfronthosting.co.za>


Ned Deily added the comment:

Here's a patch for 2.7 that separates the "maninstall" target into a "altmaninstall" target (which installs just the python2.7 man page as before) and a "maninstall" target (which adds symlinks from "python2" and "python").  Patches for 3x to follow.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29008/issue17161_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 01:16:18 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Feb 2013 00:16:18 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360368978.08.0.916375749369.issue17130@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

While we're on profile convenience features, how about adding two context managers:

- one that just profiles a block and prints the profile (or dumps the data to a file)

- one that takes a Profile instance and enables profiling to that instance

E.g. (1)

with cProfile.runblock([file]):
    <your code here>

or (2)

p = cProfile.Profile()
with p:
    <your code here>

Also a decorator corresponding to (1):

@cProfile.runfunc([filename])
def myfunc(args):
    <stuff>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Sat Feb  9 01:19:27 2013
From: report at bugs.python.org (umedoblock)
Date: Sat, 09 Feb 2013 00:19:27 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360369167.52.0.08159472411.issue17156@psf.upfronthosting.co.za>


umedoblock added the comment:

thanks serhiy.storchaka.
I try to use Shift_JIS, UTF-8, ISO-2022-JP and EUC-JP.

your patch detects UTF-8.

However it doesn't detect Shift_JIS, ISO-2022-JP and EUC-JP.
it misunderstand ISO-2022-JP charset is UTF-8.
it raised UnicodeDecodeError when Shift_JIS, EUC-JP.

Please check my test to use konnichiha.sh.

----------
Added file: http://bugs.python.org/file29009/konnichiha.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Sat Feb  9 01:21:10 2013
From: report at bugs.python.org (umedoblock)
Date: Sat, 09 Feb 2013 00:21:10 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360369270.08.0.910249197892.issue17156@psf.upfronthosting.co.za>


umedoblock added the comment:

I use just a pygettext_unicode.patch.
don't use a pygettext_unicode-2.7.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Sat Feb  9 01:46:57 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Feb 2013 00:46:57 +0000
Subject: [issue17108] import silently prefers package over module when both
	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360370817.76.0.959546927013.issue17108@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I looked through both the old 2.7 import statement doc and the new 3.3 import statement doc and import system chapter (5. The import system) and could not find anything about what a Path Based Finder path entry finder does when a particular path entry has multiple candidates (a directory, a file.pyx, and __pycache__/*.pyc entries are all possible).

I also notices that there is no (longer a) description of the simple default search for default installations: sys.modules, builtin modules, and sys.path directories. Up to here, first found rules. If there were such a simplified description, it could be followed by a description of resolution of conflicts within a sys.path directory.

----------
nosy: +terry.reedy
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17108>
_______________________________________

From report at bugs.python.org  Sat Feb  9 02:06:16 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Feb 2013 01:06:16 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360371976.88.0.704963859147.issue17161@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file29010/issue17161_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 02:06:39 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Feb 2013 01:06:39 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360371999.46.0.360199239083.issue17161@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file29011/issue17161_33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 02:45:15 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Feb 2013 01:45:15 +0000
Subject: [issue6478] time.tzset does not reset _strptime's locale time cache
In-Reply-To: <1247506425.36.0.284798334504.issue6478@psf.upfronthosting.co.za>
Message-ID: <1360374315.27.0.872590820179.issue6478@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> There is a long line in _strptime.py which I will fix before
> committing.

Ops, fixed.

Also, I've found a better place for the test in Lib/test/test_strptime.py
and moved it to the test_strptime.CacheTests.

When I applied the patch, test_bad_timezone test failed because of
this code in Lib/_strptime.py:

    @staticmethod
    def _get_timezone():
        try:
            time.tzset()
        except AttributeError:
            pass
        # ...

time.tzset() always resets time.tzname[1], so this part of the code
in test_bad_timezone[2] didn't work.

    tzname = time.tzname[0]
    time.tzname = (tzname, tzname)

I've fixed test_bad_timezone test by mocking the new
_strptime._TimeRE_cache.locale_time._get_timezone method.

[1] http://hg.python.org/cpython/file/default/Modules/timemodule.c#l827
[2] http://hg.python.org/cpython/file/default/Lib/test/test_strptime.py#l320

----------
Added file: http://bugs.python.org/file29012/issue6478_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6478>
_______________________________________

From report at bugs.python.org  Sat Feb  9 02:55:26 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Feb 2013 01:55:26 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360374926.78.0.77335138117.issue17161@psf.upfronthosting.co.za>


?ric Araujo added the comment:

3.3 patch looks fine.

For 2.7, I notice python2.7.1 is linked to python.1 and python2.1; do we install python as python2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 02:58:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Feb 2013 01:58:18 +0000
Subject: [issue17152] Array module should support "boolean" natively
In-Reply-To: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>
Message-ID: <1360375098.97.0.437781149387.issue17152@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You are proposing a bit array. Whether the bits are interpreted or displayed as 0/1 or f/t or False/True is secondary. The problem is that bit arrays do not fit the array model, with its minimum byte size per element of 1. There are other aspects of arrays that do not fit either. What would .itemsize() return? fractions. Fraction(1,8)? In any case, the internal implementation will be substantially different.

So I suggest that the proposal be to add an array.bitarray class. The bit representation strings '0'/'1', 'f'/'t', 'False'/'True' could be parameters. Omit typecode, typecodes, amd itemsize attributes and byteswap and (to or from)string methods. The buffer_info method would need redefinition. Should (to/from)(bytes/file) use 1 byte per bit (is so, which ones) or pack 8 bits per byte? It would be sensible to add bitwise operators (~, &, |, ^) on bit arrays of the same length. An implementation decision is the granularity of the internal storage (1, 2, 4, or possibly 8 bytes on 64 bit systems -- or just use 3.x ints).  The insert/delete methods might be omitted, but implementation of such should be similar to the shift methods for integers, which have the same problem of moving bits between internal implementation chunks.

I suspect that many have implemented versions of this in Python (as well as other languages) using bytes or ints with masks. I suggest you present the idea on python-ideas list to garner more support -- and be prepred to write a PEP for a new class.

I suspect that the relative ease of using ints as bit arrays will be an argument against such an addition. That is why they have the bit operations. On the other hand, one might argue that the inclusion of bit operations acknowledges the need for bit arrays.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17152>
_______________________________________

From report at bugs.python.org  Sat Feb  9 03:59:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Feb 2013 02:59:24 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360378764.82.0.729302107401.issue17157@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Given isxxx(src, target_s), the proposal would seem to be to change the internal test "type(target_s) is tuple" to "hasattr(type(target_s), '__iter__'). This depends on metaclasses not having .__iter__ methods, just as type does not. However, a subclass of type that added .__iter__, for instance to iterate through all its instances (classes defined with that metaclass), would break that test. So the proposal needs a better test, that cannot become ambiguous, to be practical.

A virtue of the 'class or tuple of classes' interface is that a tuple instance is clearly not a class in itself, so there is no possible ambiguity.

It is a positive feature that isinstance and issubclass have the same signature: both or neither should be changed. The use of tuple for multiple items in 'item or items' interfaces is historical and also used elsewhere, as in exception clauses.

The meaning of
  except target_exception_s [as name]: body
is 
  if issubclass(raised_exception, target_exception_s)
      or isinstance(raised_exception, target_exception_s):
    [name = raised_exception]
    body

So to remain consistent, I think changing exception statements to allow iterables of exceptions should also be part of the proposal.

There might be something else that I am forgetting about at the moment.

While iterables might be used if Python were being written fresh today and the ambiguity problem were solved, I agree that more than esthetic satisfaction is needed to make a change.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Sat Feb  9 04:28:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Feb 2013 03:28:12 +0000
Subject: [issue17158] help() module searcher text is misleading
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <1360380492.52.0.161661355117.issue17158@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You are asking that help("modules spam") act more like help("modules"), which sensibly prints "Enter ..." after the list. A minor but reasonable request, but since the current behavior is not a bug and some code might possible depend on it, only for 3.4. Here is a simple but untested patch.

----------
components: +Library (Lib) -Interpreter Core
keywords: +patch
nosy: +terry.reedy
stage:  -> patch review
versions:  -Python 3.3
Added file: http://bugs.python.org/file29013/Issue17158.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Sat Feb  9 04:37:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Feb 2013 03:37:34 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1360381054.48.0.200648532225.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

moijes,

Yes, it's open. You can examine the comments for the previous patch by clicking on the "review" link near the patch. You need to be logged in to the issue tracker to see that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Sat Feb  9 05:11:48 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Feb 2013 04:11:48 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360383108.35.0.476406220078.issue17161@psf.upfronthosting.co.za>


Ned Deily added the comment:

"do we install python as python2?"

Yes, PEP 394 support was added in 2.7.3 (issue12627).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 08:05:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 07:05:57 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <3Z346X1XCRzNBG@mail.python.org>


Roundup Robot added the comment:

New changeset 29826cb3f12e by Ned Deily in branch '2.7':
Issue #17161: make install now also installs a python2 and python man page.
http://hg.python.org/cpython/rev/29826cb3f12e

New changeset b0d9b273c029 by Ned Deily in branch '3.2':
Issue #17161: make install now also installs a python3 man page.
http://hg.python.org/cpython/rev/b0d9b273c029

New changeset 9828c4ffb401 by Ned Deily in branch '3.3':
Issue #17161: make install now also installs a python3 man page.
http://hg.python.org/cpython/rev/9828c4ffb401

New changeset 5e874b2a0469 by Ned Deily in branch 'default':
Issue #17161: merge from 3.3
http://hg.python.org/cpython/rev/5e874b2a0469

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 08:12:25 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Feb 2013 07:12:25 +0000
Subject: [issue17161] make install misses the man and the static library
In-Reply-To: <1360343601.69.0.324623766198.issue17161@psf.upfronthosting.co.za>
Message-ID: <1360393945.86.0.927722783863.issue17161@psf.upfronthosting.co.za>


Ned Deily added the comment:

As of 2.7.4, 3.2.4, 3.3.1 and 3.4.0, make install will now install the missing symlinks for the missing man pages, python/python2 or python3.

----------
assignee:  -> ned.deily
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17161>
_______________________________________

From report at bugs.python.org  Sat Feb  9 08:54:38 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Feb 2013 07:54:38 +0000
Subject: [issue17165] Use "except ImportError" instead of bare except in
	_strptime.py
Message-ID: <1360396478.11.0.456906472362.issue17165@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the source: http://hg.python.org/cpython/file/default/Lib/_strptime.py#l24

and for the reference: http://docs.python.org/dev/library/_dummy_thread.html#module-_dummy_thread

----------
components: Library (Lib)
files: _strptime_importerror.diff
keywords: patch
messages: 181720
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: Use "except ImportError" instead of bare except in _strptime.py
versions: Python 3.4
Added file: http://bugs.python.org/file29014/_strptime_importerror.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17165>
_______________________________________

From report at bugs.python.org  Sat Feb  9 09:03:18 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Feb 2013 08:03:18 +0000
Subject: [issue17166] Fix the suggested usage of _dummy_thread module
Message-ID: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The "dummy_thread" module has been renamed to "_dummy_thread" in Python 3:

    >>> import dummy_thread
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: No module named 'dummy_thread'

----------
assignee: docs at python
components: Documentation
files: _dummy_thread-usage.diff
keywords: patch
messages: 181721
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix the suggested usage of _dummy_thread module
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29015/_dummy_thread-usage.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17166>
_______________________________________

From report at bugs.python.org  Sat Feb  9 10:03:55 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Feb 2013 09:03:55 +0000
Subject: [issue17167] python man page contains $Date$ in page footer
Message-ID: <1360400635.24.0.00924107320182.issue17167@psf.upfronthosting.co.za>


New submission from Ned Deily:

The center footer in the source for the python man page, specifically the .th macro in Misc/python.man, contains an unexpanded $Date$ left over from the days of svn keyword expansions.  Since hg does not support such expansions, either the source should be edited to remove the keyword or the date should be expanded during builds.  One possibility would be to add sed edit steps to the altmaninstall makefile target and to "release.py --export".

----------
components: Build
messages: 181722
nosy: benjamin.peterson, georg.brandl, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: python man page contains $Date$ in page footer
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17167>
_______________________________________

From report at bugs.python.org  Sat Feb  9 10:17:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 09:17:44 +0000
Subject: [issue16686] audioop overflow issues
In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>
Message-ID: <3Z372b2YDfzRXP@mail.python.org>


Roundup Robot added the comment:

New changeset 6add6ac6a802 by Serhiy Storchaka in branch '2.7':
Issue #16686: Fixed a lot of bugs in audioop module.
http://hg.python.org/cpython/rev/6add6ac6a802

New changeset 104b17f8316b by Serhiy Storchaka in branch '3.2':
Issue #16686: Fixed a lot of bugs in audioop module.
http://hg.python.org/cpython/rev/104b17f8316b

New changeset 63b164708e60 by Serhiy Storchaka in branch '3.3':
Issue #16686: Fixed a lot of bugs in audioop module.
http://hg.python.org/cpython/rev/63b164708e60

New changeset 48747ef5f65b by Serhiy Storchaka in branch 'default':
Issue #16686: Fixed a lot of bugs in audioop module.
http://hg.python.org/cpython/rev/48747ef5f65b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16686>
_______________________________________

From report at bugs.python.org  Sat Feb  9 10:25:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 09:25:26 +0000
Subject: [issue16686] audioop overflow issues
In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>
Message-ID: <1360401926.55.0.766825418673.issue16686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I fixed yet one bug in avgpp() and remove my XXX comment. *All* audioop functions are unsafe regarding unaligned access. I'll open a new issue for this.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16686>
_______________________________________

From report at bugs.python.org  Sat Feb  9 10:35:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 09:35:31 +0000
Subject: [issue16686] audioop overflow issues
In-Reply-To: <1355508907.39.0.527029919241.issue16686@psf.upfronthosting.co.za>
Message-ID: <1360402531.73.0.895915900501.issue16686@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> *All* audioop functions are unsafe regarding unaligned access.

Actually this is not true because currently audioop functions work only with bytes (and str, see issue16685) and not with arbitrary memoryview.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16686>
_______________________________________

From report at bugs.python.org  Sat Feb  9 10:55:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 09:55:53 +0000
Subject: [issue17147] BytesIO should be mentioned in SpooledTemporaryFile
	documentation
In-Reply-To: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>
Message-ID: <3Z37tc1pkZzSYb@mail.python.org>


Roundup Robot added the comment:

New changeset fb4ed16f35bd by Serhiy Storchaka in branch '3.2':
Issue #17147. Mention BytesIO in SpooledTemporaryFile documentation.
http://hg.python.org/cpython/rev/fb4ed16f35bd

New changeset 8f772825029f by Serhiy Storchaka in branch '3.3':
Issue #17147. Mention BytesIO in SpooledTemporaryFile documentation.
http://hg.python.org/cpython/rev/8f772825029f

New changeset c75d065a6bc2 by Serhiy Storchaka in branch 'default':
Issue #17147. Mention BytesIO in SpooledTemporaryFile documentation.
http://hg.python.org/cpython/rev/c75d065a6bc2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17147>
_______________________________________

From report at bugs.python.org  Sat Feb  9 10:59:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 09:59:00 +0000
Subject: [issue17147] BytesIO should be mentioned in SpooledTemporaryFile
	documentation
In-Reply-To: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>
Message-ID: <1360403940.41.0.602019331094.issue17147@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for corrections ?ric.

----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17147>
_______________________________________

From report at bugs.python.org  Sat Feb  9 11:26:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 10:26:55 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <3Z38ZQ6VrQzRRn@mail.python.org>


Roundup Robot added the comment:

New changeset 5c2ff6e64c47 by Serhiy Storchaka in branch '2.7':
Issue #10355: SpooledTemporaryFile properties and xreadline method now work for unrolled files.
http://hg.python.org/cpython/rev/5c2ff6e64c47

New changeset dfc6902b63d7 by Serhiy Storchaka in branch '3.2':
Issue #10355: SpooledTemporaryFile properties now work for unrolled files.
http://hg.python.org/cpython/rev/dfc6902b63d7

New changeset f36d8ba4eeef by Serhiy Storchaka in branch '3.3':
Issue #10355: SpooledTemporaryFile properties now work for unrolled files.
http://hg.python.org/cpython/rev/f36d8ba4eeef

New changeset f1a13191f0c8 by Serhiy Storchaka in branch 'default':
Issue #10355: SpooledTemporaryFile properties now work for unrolled files.
http://hg.python.org/cpython/rev/f1a13191f0c8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Sat Feb  9 11:33:53 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 10:33:53 +0000
Subject: [issue17168] test.support 3.x docs mentions stringio.stringio
Message-ID: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

StringIO.StringIO has been renamed to io.StringIO in 3.x.
Attached is a patch with the corrected version which mentions io.StringIO.

----------
assignee: docs at python
components: Documentation
files: issue.patch
keywords: patch
messages: 181729
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: test.support 3.x docs mentions stringio.stringio
Added file: http://bugs.python.org/file29016/issue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17168>
_______________________________________

From report at bugs.python.org  Sat Feb  9 11:35:05 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 10:35:05 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360406105.4.0.259024699715.issue17157@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Just so you know, I'm neutral on this idea. I think it should at least accept sequences though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Sat Feb  9 11:35:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 10:35:43 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360406143.6.0.208238695607.issue17156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Default encoding on Python 3 is UTF-8. You should declare your encoding at the top of file if it differs from UTF-8 or ASCII (i.e. "# -*- coding: euc-jp -*-"). Otherwise Python will reject your file (for Shift_JIS and EUC-JP) or produce incorrect result (for ISO-2022-JP).

$ python3 konnichiha.Shift_JIS.py
  File "konnichiha.Shift_JIS.py", line 5
SyntaxError: Non-UTF-8 code starting with '\x82' in file konnichiha.Shift_JIS.py on line 5, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
$ python3 konnichiha.ISO-2022-JP.py
konnichiha
B$3$s$K$A$O

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Sat Feb  9 11:36:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 10:36:50 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1360406210.8.0.168264447209.issue10355@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Sat Feb  9 12:12:19 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Feb 2013 11:12:19 +0000
Subject: [issue17152] Array module should support "boolean" natively
In-Reply-To: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>
Message-ID: <1360408339.64.0.650600727436.issue17152@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

There's already a fairly well known 3rd-party library for this:

http://pypi.python.org/pypi/bitarray/

I'd be -1 on putting something like this in the standard library:  the array module doesn't get enough maintenance as it is, and a packed bit array sounds like a specialist need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17152>
_______________________________________

From report at bugs.python.org  Sat Feb  9 12:48:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 11:48:37 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <3Z3BNh2nGzzSYP@mail.python.org>


Roundup Robot added the comment:

New changeset a025b04332fe by Serhiy Storchaka in branch '2.7':
Issue #7358: cStringIO.StringIO now supports writing to and reading from
http://hg.python.org/cpython/rev/a025b04332fe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Sat Feb  9 13:52:33 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Sat, 09 Feb 2013 12:52:33 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360414353.84.0.760683178274.issue17136@psf.upfronthosting.co.za>


Dirkjan Ochtman added the comment:

libffi now has this fix:

https://github.com/atgreen/libffi/commit/6a790129427121f7db2d876e7218a3104e6d2741

Can someone test with that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17136>
_______________________________________

From report at bugs.python.org  Sat Feb  9 14:02:48 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 13:02:48 +0000
Subject: [issue17168] test.support 3.x docs mentions stringio.stringio
In-Reply-To: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>
Message-ID: <1360414968.87.0.771694827359.issue17168@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Please commit or review. This is *very* trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17168>
_______________________________________

From report at bugs.python.org  Sat Feb  9 14:08:39 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 13:08:39 +0000
Subject: [issue17166] Fix the suggested usage of _dummy_thread module
In-Reply-To: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>
Message-ID: <1360415319.16.0.914899533019.issue17166@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

LGTM.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17166>
_______________________________________

From report at bugs.python.org  Sat Feb  9 14:49:44 2013
From: report at bugs.python.org (Franck Michea)
Date: Sat, 09 Feb 2013 13:49:44 +0000
Subject: [issue17157] issubclass() should accept iterables in 2nd arg
In-Reply-To: <1360332453.27.0.284450731035.issue17157@psf.upfronthosting.co.za>
Message-ID: <1360417784.06.0.325413761261.issue17157@psf.upfronthosting.co.za>


Franck Michea added the comment:

I am neutral on this too, it just felt odd and this is why the question raised.

Yesterday I tried to add sequences and iterables (only to issubclass but indeed it would need better testing and all) and came to a problem with sequences. The current implementation authorizes (A, (B, (C, D))) (why?) so issubclass is recursive, but if we add sequences, they could create infinite recursions if seq[0] == seq (it's the case for strings for example, where 'a' is still a sequence and 'a'[0] == 'a').

So I don't know if it's really interesting. Anyone can use tuple() on an iterable to build its tuple value, though the value is built in memory. It basically just felt odd to take only tuples but I don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17157>
_______________________________________

From report at bugs.python.org  Sat Feb  9 14:58:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 13:58:01 +0000
Subject: [issue17168] test.support 3.x docs mentions stringio.stringio
In-Reply-To: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>
Message-ID: <3Z3FG00fLlzMRY@mail.python.org>


Roundup Robot added the comment:

New changeset 474296d6d4a1 by Benjamin Peterson in branch '3.3':
StringIO.StringIO -> io.StringIO (closes #17168)
http://hg.python.org/cpython/rev/474296d6d4a1

New changeset 87e95b853be2 by Benjamin Peterson in branch 'default':
merge 3.3 (#17168)
http://hg.python.org/cpython/rev/87e95b853be2

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17168>
_______________________________________

From report at bugs.python.org  Sat Feb  9 15:45:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 14:45:19 +0000
Subject: [issue17169] Restore errno in tempfile exceptions
Message-ID: <1360421119.33.0.506683731542.issue17169@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Before 3.3 if not able to create the name of the temporary file then an OSError with meaninful errno (ENOENT or EEXIST) was raised. Now subclass of OSError raised with errno=None. This is an incompatible change because old user code can catch OSError exception and then test its errno.

Here is a patch which restores errno attribute in these exceptions.

----------
components: Library (Lib)
files: tempfile_errno.patch
keywords: 3.3regression, patch
messages: 181739
nosy: flox, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Restore errno in tempfile exceptions
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29017/tempfile_errno.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17169>
_______________________________________

From report at bugs.python.org  Sat Feb  9 16:04:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 15:04:06 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1360422246.9.0.666137476056.issue7358@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7358>
_______________________________________

From report at bugs.python.org  Sat Feb  9 16:06:52 2013
From: report at bugs.python.org (umedoblock)
Date: Sat, 09 Feb 2013 15:06:52 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360422412.13.0.25115589732.issue17156@psf.upfronthosting.co.za>


umedoblock added the comment:

python3 output translate Japanese with pygettext.install().

EVERYTHING IS OK!

please check to use a konnichiha.2.tar.gz.
==============================================
please do below shell command.

$ for f in `find . -name 'konnichiha.*.py'` ; do echo f=$f ; python3 $f ; echo -- ; done
f=./konnichiha.Shift_JIS.py
HELLO ????????
????????????????
--
f=./konnichiha.UTF-8.py
HELLO ????????
????????????????
--
f=./konnichiha.ISO-2022-JP.py
HELLO ????????
????????????????
--
f=./konnichiha.EUC-JP.py
HELLO ????????
????????????????
--

==============================================
konnichiha script encoding is OK!

$ nkf -g ./konnichiha.*.py                   
./konnichiha.EUC-JP.py: EUC-JP
./konnichiha.ISO-2022-JP.py: ISO-2022-JP
./konnichiha.Shift_JIS.py: Shift_JIS
./konnichiha.UTF-8.py: UTF-8

==============================================
also coding: is OK!
$ head -2 konnichiha.*.py             
==> konnichiha.EUC-JP.py <==
# coding: euc-jp
import gettext

==> konnichiha.ISO-2022-JP.py <==
# coding: iso-2022-jp
import gettext

==> konnichiha.Shift_JIS.py <==
# coding: shift-jis
import gettext

==> konnichiha.UTF-8.py <==
# coding: utf-8
import gettext

==============================================
THANK YOU serhiy.storchaka !

----------
Added file: http://bugs.python.org/file29018/konnichiha.2.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Sat Feb  9 16:59:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Feb 2013 15:59:31 +0000
Subject: [issue17170] string replace is too slow
Message-ID: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I'm trying to speed up a web template engine and I find that the code needs to do a lot of string replacements of this form:

  name = name.replace('_', '-')

Characteristics of the data: the names are relatively short (1-10 characters usually), and the majority don't contain a '_' at all.

For this combination I've found that the following idiom is significantly faster:

  if '_' in name:
      name = name.replace('_', '-')

I'd hate for that idiom to become popular.  I looked at the code (in the default branch) briefly, but it is already optimized for this case.  So I am at a bit of a loss to explain the speed difference...

Some timeit experiments:

bash-3.2$ ./python.exe -m timeit -s "a = 'hundred'" "'x' in a"
./python.exe -m timeit -s "a = 'hundred'" "'x' in a"

bash-3.2$ ./python.exe -m timeit -s "a = 'hundred'" "a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hundred'" "a.replace('x', 'y')"

bash-3.2$ ./python.exe -m timeit -s "a = 'hundred'" "if 'x' in a: a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hundred'" "if 'x' in a: a.replace('x', 'y')"

bash-3.2$ ./python.exe -m timeit -s "a = 'hunxred'" "a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hunxred'" "a.replace('x', 'y')"

bash-3.2$ ./python.exe -m timeit -s "a = 'hunxred'" "if 'x' in a: a.replace('x', 'y')"
./python.exe -m timeit -s "a = 'hunxred'" "if 'x' in a: a.replace('x', 'y')"

----------
components: Interpreter Core
messages: 181741
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: string replace is too slow
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 17:07:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 16:07:30 +0000
Subject: [issue17170] string replace is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360426050.88.0.977206147009.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Characteristics of the data: the names are relatively short (1-10
> characters usually)

$ ./python -m timeit -s "a = 'hundred'" "'x' in a"
10000000 loops, best of 3: 0.0431 usec per loop
$ ./python -m timeit -s "a = 'hundred'" "a.find('x')"
1000000 loops, best of 3: 0.206 usec per loop
$ ./python -m timeit -s "a = 'hundred'" "a.replace('x', 'y')"
10000000 loops, best of 3: 0.198 usec per loop

Basically, it's simply the overhead of method calls over operator calls. You only see it because the strings are very short, and therefore the cost of finding / replacing is tiny.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 17:18:55 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Feb 2013 16:18:55 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360426735.71.0.83429366739.issue17170@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Hm, you seem to be right. Changing the bug title.

So, can we speed up method lookup? It's a shame that I have to start promoting this ugly idiom. There's a similar issue where s[:5]=='abcde' is faster than s.startswith('abcde'):

./python.exe -m timeit -s "a = 'hundred'" "a.startswith('foo')"
1000000 loops, best of 3: 0.281 usec per loop

./python.exe -m timeit -s "a = 'hundred'" "a[:3] == 'foo'"
10000000 loops, best of 3: 0.158 usec per loop

----------
title: string replace is too slow -> string method lookup is too slow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 17:23:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 09 Feb 2013 16:23:51 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360427031.78.0.648047124555.issue17170@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, serhiy.storchaka
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 17:51:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 16:51:54 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360428714.47.0.598748605636.issue17170@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are two overheads: an attribute lookup and a function call.

$ ./python -m timeit -s "a = 'hundred'"  "'x' in a"
10000000 loops, best of 3: 0.0943 usec per loop
$ ./python -m timeit -s "a = 'hundred'"  "a.__contains__('x')"
1000000 loops, best of 3: 0.271 usec per loop
$ ./python -m timeit -s "a = 'hundred'"  "a.__contains__"
10000000 loops, best of 3: 0.135 usec per loop

Time of "a.__contains__('x')"  is greater than the sum of times of "a.__contains__" and "'x' in a".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 17:52:49 2013
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=)
Date: Sat, 09 Feb 2013 16:52:49 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360428769.58.0.949076672517.issue16038@psf.upfronthosting.co.za>


Micha? Jastrz?bski added the comment:

Hello,

I've set up maxline limit to 8192. Also I've add some changes Antoine suggested earlier.

----------
Added file: http://bugs.python.org/file29019/ftplib_maxline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sat Feb  9 18:33:02 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 09 Feb 2013 17:33:02 +0000
Subject: [issue17169] Restore errno in tempfile exceptions
In-Reply-To: <1360421119.33.0.506683731542.issue17169@psf.upfronthosting.co.za>
Message-ID: <1360431182.08.0.430588199312.issue17169@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The patch looks good and it is correct thing to do IMO. thanks.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17169>
_______________________________________

From report at bugs.python.org  Sat Feb  9 19:17:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 18:17:06 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <3Z3M0x2V4qzRSH@mail.python.org>


Roundup Robot added the comment:

New changeset 30f92600df9d by R David Murray in branch '2.7':
#16564: test to confirm behavior that regressed in python3.
http://hg.python.org/cpython/rev/30f92600df9d

New changeset a1a04f76d08c by R David Murray in branch '3.2':
#16564: Fix regression in use of encoders.encode_noop with binary data.
http://hg.python.org/cpython/rev/a1a04f76d08c

New changeset 2b1edefc1e99 by R David Murray in branch '3.3':
Merge: #16564: Fix regression in use of encoders.encode_noop with binary data.
http://hg.python.org/cpython/rev/2b1edefc1e99

New changeset 5a0478bd5f11 by R David Murray in branch 'default':
Merge: #16564: Fix regression in use of encoders.encode_noop with binary data.
http://hg.python.org/cpython/rev/5a0478bd5f11

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16564>
_______________________________________

From report at bugs.python.org  Sat Feb  9 19:19:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Feb 2013 18:19:45 +0000
Subject: [issue17171] email.encoders.encode7or8bit does not work with binary
	data
Message-ID: <1360433985.11.0.320523625616.issue17171@psf.upfronthosting.co.za>


New submission from R. David Murray:

Reported by Serhiy in issue 16564:


>>> import io, email
>>> bytesdata = b'\xfa\xfb\xfc\xfd\xfe\xff'
>>> msg = email.mime.application.MIMEApplication(bytesdata, _encoder=encoders.encode_7or8bit)
>>> s = io.BytesIO()
>>> g = email.generator.BytesGenerator(s)
>>> g.flatten(msg)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 91, in flatten
    self._write(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 137, in _write
    self._dispatch(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 163, in _dispatch
    meth(msg)
  File "/home/serhiy/py/cpython3.2/Lib/email/generator.py", line 393, in _handle_text
    if _has_surrogates(msg._payload):
TypeError: can't use a string pattern on a bytes-like object

----------
components: email
messages: 181748
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.encoders.encode7or8bit does not work with binary data
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17171>
_______________________________________

From report at bugs.python.org  Sat Feb  9 19:20:54 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Feb 2013 18:20:54 +0000
Subject: [issue16564] email.generator.BytesGenerator fails with bytes payload
In-Reply-To: <1354027130.07.0.897738205773.issue16564@psf.upfronthosting.co.za>
Message-ID: <1360434054.4.0.063121632968.issue16564@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've opened issue 17171 for the similar encode7or8bit problem.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16564>
_______________________________________

From report at bugs.python.org  Sat Feb  9 19:21:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 18:21:40 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1360434100.43.0.547358272357.issue13555@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. Fixed two bugs found by Antoine (an inappropriate format and a memory error in bigmemtest), fixed resizing of marks array and one possible integer overflow in write_other(). Used workaround to bypass limitations of cStringIO API.

----------
assignee:  -> serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file29020/pickle_overflow-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Sat Feb  9 19:25:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 18:25:29 +0000
Subject: [issue17166] Fix the suggested usage of _dummy_thread module
In-Reply-To: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>
Message-ID: <3Z3MBc52QYzSXj@mail.python.org>


Roundup Robot added the comment:

New changeset 6af3afbc7211 by R David Murray in branch '3.2':
#17166: fix _dummy_thread import example.
http://hg.python.org/cpython/rev/6af3afbc7211

New changeset dfefae8df4f7 by R David Murray in branch '3.3':
Merge: #17166: fix _dummy_thread import example.
http://hg.python.org/cpython/rev/dfefae8df4f7

New changeset c4512797b879 by R David Murray in branch 'default':
Merge: #17166: fix _dummy_thread import example.
http://hg.python.org/cpython/rev/c4512797b879

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17166>
_______________________________________

From report at bugs.python.org  Sat Feb  9 19:26:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Feb 2013 18:26:19 +0000
Subject: [issue17166] Fix the suggested usage of _dummy_thread module
In-Reply-To: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>
Message-ID: <1360434379.62.0.796430835269.issue17166@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Berker.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17166>
_______________________________________

From report at bugs.python.org  Sat Feb  9 20:43:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 19:43:53 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360439033.43.0.496471662015.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed the function call cost actually dominates:

$ ./python -m timeit -s "a = 'hundred'" "a.find('x')"
1000000 loops, best of 3: 0.206 usec per loop
$ ./python -m timeit -s "a = 'hundred'; f=a.find" "f('x')"
10000000 loops, best of 3: 0.176 usec per loop
$ ./python -m timeit -s "a = 'hundred'" "'x' in a"
10000000 loops, best of 3: 0.0431 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 20:58:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 19:58:53 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360439933.66.0.882068038126.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Some crude C benchmarking on this computer:
- calling PyUnicode_Replace is 35 ns (per call)
- calling "hundred".replace is 125 ns
- calling PyArg_ParseTuple with the same signature as "hundred".replace is 80 ns

Therefore, most of the overhead (125 - 35 = 90 ns) is in calling PyArg_ParseTuple() to unpack the method arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:07:14 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 09 Feb 2013 20:07:14 +0000
Subject: [issue16956] Allow signed line number deltas in the code object's
	line number table
In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za>
Message-ID: <1360440434.22.0.503540965889.issue16956@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16956>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:22:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 20:22:48 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360441368.33.0.623815786225.issue17170@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And PyArg_ParseTupleAndKeywords() is even more slow.

$ ./python -m timeit "str(b'', 'utf-8', 'strict')"
1000000 loops, best of 3: 0.554 usec per loop
$ ./python -m timeit "str(object=b'', encoding='utf-8', errors='strict')"
1000000 loops, best of 3: 1.74 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:28:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 20:28:19 +0000
Subject: [issue17169] Restore errno in tempfile exceptions
In-Reply-To: <1360421119.33.0.506683731542.issue17169@psf.upfronthosting.co.za>
Message-ID: <3Z3PwL4B2BzQ2D@mail.python.org>


Roundup Robot added the comment:

New changeset 11eaa61124c2 by Serhiy Storchaka in branch '3.3':
Issue #17169: Restore errno in tempfile exceptions.
http://hg.python.org/cpython/rev/11eaa61124c2

New changeset fd3e3059381a by Serhiy Storchaka in branch 'default':
Issue #17169: Restore errno in tempfile exceptions.
http://hg.python.org/cpython/rev/fd3e3059381a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17169>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:32:46 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Feb 2013 20:32:46 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
Message-ID: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The turtledemo is an on-ramp for younger programmers and we should make it easy to launch.

----------
components: IDLE
keywords: easy
messages: 181757
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add turtledemo to IDLE menu
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:41:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 20:41:23 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <3Z3QCQ3ZdtzMYT@mail.python.org>


Roundup Robot added the comment:

New changeset 49b1fde510a6 by Serhiy Storchaka in branch '2.7':
Issue #17156: pygettext.py now correctly escapes non-ascii characters.
http://hg.python.org/cpython/rev/49b1fde510a6

New changeset cd59b398907d by Serhiy Storchaka in branch '3.2':
Issue #17156: pygettext.py now uses an encoding of source file and correctly
http://hg.python.org/cpython/rev/cd59b398907d

New changeset 062406c06cc1 by Serhiy Storchaka in branch '3.3':
Issue #17156: pygettext.py now uses an encoding of source file and correctly
http://hg.python.org/cpython/rev/062406c06cc1

New changeset 99795d711a40 by Serhiy Storchaka in branch 'default':
Issue #17156: pygettext.py now uses an encoding of source file and correctly
http://hg.python.org/cpython/rev/99795d711a40

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:42:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 20:42:16 +0000
Subject: [issue17156] Tools/i18n/pygettext.py doesn't parse unicode string.
In-Reply-To: <1360287078.84.0.489107561293.issue17156@psf.upfronthosting.co.za>
Message-ID: <1360442536.84.0.203492721689.issue17156@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17156>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:43:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 20:43:00 +0000
Subject: [issue17169] Restore errno in tempfile exceptions
In-Reply-To: <1360421119.33.0.506683731542.issue17169@psf.upfronthosting.co.za>
Message-ID: <1360442580.55.0.259609082022.issue17169@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17169>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:45:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 20:45:31 +0000
Subject: [issue17043] Invalid read in test_codecs
In-Reply-To: <1359232875.45.0.401299451794.issue17043@psf.upfronthosting.co.za>
Message-ID: <1360442731.72.0.538364224674.issue17043@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17043>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:49:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 20:49:59 +0000
Subject: [issue17173] uses of locale-dependent ctype functions
Message-ID: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Grepping through the code reveals we are still using a number of locale-dependent C library functions:

Python/mystrtoul.c:102:    while (*str && isspace(Py_CHARMASK(*str)))
Python/mystrtoul.c:141:                while (isspace(Py_CHARMASK(*str)))
Python/mystrtoul.c:269:    while (*str && isspace(Py_CHARMASK(*str)))
Python/formatter_unicode.c:404:    while (pos<end && isdigit(PyUnicode_READ_CHAR(s, pos)))
Python/ast.c:3764:    if (isalpha(quote)) {
Python/dynload_aix.c:144:        while (isdigit(Py_CHARMASK(*message[i]))) message[i]++ ;
Objects/longobject.c:2011:    while (*str != '\0' && isspace(Py_CHARMASK(*str)))
Objects/longobject.c:2255:    while (*str && isspace(Py_CHARMASK(*str)))
Modules/getaddrinfo.c:228:        if (! isdigit(*q))
Modules/_sre.c:153:#define SRE_LOC_IS_DIGIT(ch) (!((ch) & ~255) ? isdigit((ch)) : 0)
Modules/_sre.c:154:#define SRE_LOC_IS_SPACE(ch) (!((ch) & ~255) ? isspace((ch)) : 0)
Modules/_sre.c:156:#define SRE_LOC_IS_ALNUM(ch) (!((ch) & ~255) ? isalnum((ch)) : 0)
Modules/binascii.c:1138:    if (isdigit(c))
Modules/_decimal/libmpdec/io.c:153:            if (!isdigit((uchar)*s))
Modules/_decimal/libmpdec/io.c:157:                    if (!isdigit((uchar)*(s+1)))
Modules/_decimal/libmpdec/io.c:159:                              isdigit((uchar)*(s+2))))
Modules/_decimal/libmpdec/io.c:185:    while (isdigit((uchar)*s))
Modules/_decimal/libmpdec/io.c:825:    if (isdigit((uchar)*cp)) {
Modules/_decimal/libmpdec/io.c:847:        if (!isdigit((uchar)*cp)) {
Modules/_decimal/libmpdec/io.c:1087:    assert(isdigit((uchar)*dp));
Modules/_decimal/libmpdec/io.c:1089:    while (isdigit((uchar)*dp)) {
Modules/_decimal/libmpdec/io.c:1244:    if (isupper((uchar)type)) {
Modules/_struct.c:1273:        if (isspace(Py_CHARMASK(c)))
Modules/_struct.c:1338:        if (isspace(Py_CHARMASK(c)))


Include/pyctype.h has locale-agnostic counterpart (a bit faster probably, too).

----------
components: Extension Modules, Interpreter Core
messages: 181759
nosy: mark.dickinson, pitrou, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: uses of locale-dependent ctype functions
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17173>
_______________________________________

From report at bugs.python.org  Sat Feb  9 21:57:28 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Feb 2013 20:57:28 +0000
Subject: [issue17173] uses of locale-dependent ctype functions
In-Reply-To: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>
Message-ID: <1360443448.97.0.407495722641.issue17173@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for fixing this everywhere.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17173>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:00:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 21:00:54 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360443654.27.0.387493008107.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch yielding a decent speedup (~ 40%) on PyArg_ParseTuple itself.
More generally though, this would be improved by precompiling some of the information (like Argument Clinic does, perhaps).

(note: PyArg_ParseTupleAndKeywords is a completely separate implementation...)

----------
keywords: +patch
Added file: http://bugs.python.org/file29021/getargs_freelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:04:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 21:04:31 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360443871.48.0.310253980848.issue17170@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:08:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 21:08:26 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <1360444106.7.0.656739318521.issue12983@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12983>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:12:37 2013
From: report at bugs.python.org (Thomas Scrace)
Date: Sat, 09 Feb 2013 21:12:37 +0000
Subject: [issue17174] Posix os.path.join should raise TypeError when passed
	unusable type
Message-ID: <1360444357.09.0.528759954869.issue17174@psf.upfronthosting.co.za>


New submission from Thomas Scrace:

Currently os.path.join will raise an AttributeError if passed an argument that does not have an endswith() method.

A try/except around the offending line would let us raise a more helpful TypeError:

    except AttributeError as e:
        bad = e.args[0].split()[0]
        raise TypeError("object of type {} is not valid as a path"
        "component".format(type(bad)))

----------
components: Library (Lib)
messages: 181762
nosy: terry.reedy, thomas.scrace
priority: normal
severity: normal
status: open
title: Posix os.path.join should raise TypeError when passed unusable type
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17174>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:39:32 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 09 Feb 2013 21:39:32 +0000
Subject: [issue9067] Use macros from pyctype.h
In-Reply-To: <1277376401.69.0.151009302074.issue9067@psf.upfronthosting.co.za>
Message-ID: <1360445972.01.0.367246899425.issue9067@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> uses of locale-dependent ctype functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9067>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:41:44 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 09 Feb 2013 21:41:44 +0000
Subject: [issue17173] uses of locale-dependent ctype functions
In-Reply-To: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>
Message-ID: <20130209214146.GA23261@sleipnir.bytereef.org>


Stefan Krah added the comment:

I'm not sure if I'll use pyctype.h in libmpdec: It's still going to be an
external project that should be completely identical to the version in the
Python tree.

libmpdec/io.c is specified to be ASCII only (while handling the Turkish 'I')
and is used accordingly in _decimal.c.

I think it is impossible to trigger any misbehavior just by using the
decimal module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17173>
_______________________________________

From report at bugs.python.org  Sat Feb  9 22:43:23 2013
From: report at bugs.python.org (Janzert)
Date: Sat, 09 Feb 2013 21:43:23 +0000
Subject: [issue17174] Posix os.path.join should raise TypeError when passed
	unusable type
In-Reply-To: <1360444357.09.0.528759954869.issue17174@psf.upfronthosting.co.za>
Message-ID: <1360446203.46.0.132320370728.issue17174@psf.upfronthosting.co.za>


Janzert added the comment:

While the current error message is a bit generic, I rather like that it tells you exactly why the type/object passed couldn't be used.

----------
nosy: +Janzert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17174>
_______________________________________

From report at bugs.python.org  Sat Feb  9 23:28:06 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 09 Feb 2013 22:28:06 +0000
Subject: [issue16692] Support TLS 1.1 and TLS 1.2
In-Reply-To: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za>
Message-ID: <1360448886.22.0.721525404039.issue16692@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
keywords: +patch
nosy: +maker
Added file: http://bugs.python.org/file29022/issue16692.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16692>
_______________________________________

From report at bugs.python.org  Sat Feb  9 23:29:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 22:29:06 +0000
Subject: [issue17173] uses of locale-dependent ctype functions
In-Reply-To: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>
Message-ID: <3Z3Sbj6mNSzSD9@mail.python.org>


Roundup Robot added the comment:

New changeset 38830281d43b by Antoine Pitrou in branch '3.2':
Issue #17173: Remove uses of locale-dependent C functions (isalpha() etc.) in the interpreter.
http://hg.python.org/cpython/rev/38830281d43b

New changeset c08bcf5302ec by Antoine Pitrou in branch '3.3':
Issue #17173: Remove uses of locale-dependent C functions (isalpha() etc.) in the interpreter.
http://hg.python.org/cpython/rev/c08bcf5302ec

New changeset 10e59553a8de by Antoine Pitrou in branch 'default':
Issue #17173: Remove uses of locale-dependent C functions (isalpha() etc.) in the interpreter.
http://hg.python.org/cpython/rev/10e59553a8de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17173>
_______________________________________

From report at bugs.python.org  Sat Feb  9 23:31:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 22:31:21 +0000
Subject: [issue17173] uses of locale-dependent ctype functions
In-Reply-To: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>
Message-ID: <1360449081.72.0.633386257147.issue17173@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Done. I haven't touched _decimal, sre, getaddrinfo.c and zlib.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17173>
_______________________________________

From report at bugs.python.org  Sat Feb  9 23:35:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 22:35:29 +0000
Subject: [issue17173] uses of locale-dependent ctype functions
In-Reply-To: <1360442999.41.0.373385180849.issue17173@psf.upfronthosting.co.za>
Message-ID: <1360449329.81.0.542422126645.issue17173@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/issue17173>
_______________________________________

From report at bugs.python.org  Sat Feb  9 23:57:19 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 09 Feb 2013 22:57:19 +0000
Subject: [issue16956] Allow signed line number deltas in the code object's
	line number table
In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za>
Message-ID: <1360450639.5.0.593675913658.issue16956@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> How does this interact with pdb?

Also, the findlinestarts() function from the dis module computes line
numbers from lnotab. This function is used by pdb when displaying the
lines of a traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16956>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:01:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 23:01:07 +0000
Subject: [issue16956] Allow signed line number deltas in the code object's
	line number table
In-Reply-To: <1358102554.86.0.0981281614451.issue16956@psf.upfronthosting.co.za>
Message-ID: <1360450867.22.0.638273491786.issue16956@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your patch doesn't seem to work properly: a "while" loop doesn't generate negative line offsets. The reason seems to be that compiler_set_lineno() prevents it.
(also, if I re-add the `assert(d_lineno >= 0);` in assemble_lnotab(), I don't get any crash)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16956>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:02:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 23:02:34 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360450954.11.0.09698034022.issue16038@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +larry
stage: needs patch -> patch review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:06:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 23:06:56 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <3Z3TRM3pGTzRNm@mail.python.org>


Roundup Robot added the comment:

New changeset f13bb1e40fbc by Antoine Pitrou in branch 'default':
Issue #13773: sqlite3.connect() gets a new `uri` parameter to pass the filename as a URI, allowing to pass custom options.
http://hg.python.org/cpython/rev/f13bb1e40fbc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13773>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:07:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 23:07:47 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1360451267.41.0.306973775334.issue13773@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've committed the patch, closing.

----------
assignee: ghaering -> 
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13773>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:09:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 23:09:11 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360451351.95.0.084198756577.issue16038@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Not sure how I nosied Larry by updating this issue, sorry for the mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:09:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 23:09:49 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360451389.81.0.197194683763.issue16038@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, but that's because I added 3.4 in the versions field and the issue is a release blocker :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:10:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Feb 2013 23:10:32 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360451432.92.0.120483405478.issue17172@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Sun Feb 10 00:14:21 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 09 Feb 2013 23:14:21 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <3dxtvied9vqxl88lguf944xq.1360451649360@email.android.com>


Larry Hastings added the comment:

My spies are everywhere!  You cannot hide your black heart, Pitrou.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sun Feb 10 01:02:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 00:02:32 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360454552.51.0.881115310461.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch to also handle PyArg_ParseTupleAndKeywords.

----------
Added file: http://bugs.python.org/file29023/getargs_freelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 10 01:05:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 00:05:24 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360454724.11.0.529173399717.issue17170@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file29023/getargs_freelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 10 01:05:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 00:05:28 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360454728.48.0.149243722216.issue17170@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file29021/getargs_freelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 10 01:05:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 00:05:34 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360454734.38.0.463209628243.issue17170@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file29024/getargs_freelist.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 10 01:16:33 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Feb 2013 00:16:33 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360455393.33.0.46547289241.issue17170@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Great to see some action. Would there be a problem in backporting this? It's not a new feature after all...

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 10 01:20:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 00:20:36 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360455636.97.0.166159658642.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That would be left to the discretion of release managers.
In all honesty the real-world benefit should be small (around 2% on the benchmark suite, apparently).
Also, the principle of this patch doesn't apply to 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 10 02:07:48 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 10 Feb 2013 01:07:48 +0000
Subject: [issue17174] Posix os.path.join should raise TypeError when passed
	unusable type
In-Reply-To: <1360444357.09.0.528759954869.issue17174@psf.upfronthosting.co.za>
Message-ID: <1360458468.38.0.556243511244.issue17174@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think this change should not be made: it's a slippery slope, because there are thousands of places in the stdlib where a similar change could be made.

It's the nature of duck typing that you're not going to get a great error message everywhere you pass in the wrong type. Python programmers just have to learn this and understand it's a source of sometimes unobvious error messages.

If, despite my concerns, this change is still made, I think it is important that any new error message not mention "str", or any list of accepted types. The proposal in msg181762 is good enough: just say that whatever type was used isn't acceptable. For example: there are a number of "path object" proposals floating around, and it's possible one of those could be used with os.path.join despite it not being a str.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17174>
_______________________________________

From report at bugs.python.org  Sun Feb 10 08:44:35 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Feb 2013 07:44:35 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360482275.76.0.415979299773.issue17172@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Sun Feb 10 09:24:44 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 10 Feb 2013 08:24:44 +0000
Subject: [issue8040] documentation pages should link to other versions of the
	same page
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1360484684.0.0.770300391869.issue8040@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Sun Feb 10 09:38:41 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 10 Feb 2013 08:38:41 +0000
Subject: [issue17175] update PEP 430
Message-ID: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

The issue referred to has since been resolved.

----------
assignee: docs at python
components: Documentation
files: update.diff
keywords: patch
messages: 181778
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: update PEP 430
Added file: http://bugs.python.org/file29025/update.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17175>
_______________________________________

From report at bugs.python.org  Sun Feb 10 10:08:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 09:08:11 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1360487291.11.0.21808110773.issue13773@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You can use "p" format in PyArg_ParseTuple* for boolean parameters.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13773>
_______________________________________

From report at bugs.python.org  Sun Feb 10 11:04:18 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 10 Feb 2013 10:04:18 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360490658.62.0.00526235284477.issue17172@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Will attach patch. Coincidentally I'm am a younger programmer.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Sun Feb 10 11:07:21 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 10 Feb 2013 10:07:21 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360490841.29.0.402844205918.issue17172@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Should be "... I'm a younger..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Sun Feb 10 11:27:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 10:27:46 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <3Z3mXx2SSGzPwk@mail.python.org>


Roundup Robot added the comment:

New changeset 6ec6dbf787f4 by Serhiy Storchaka in branch '2.7':
Issue #6975: os.path.realpath() now correctly resolves multiple nested symlinks on POSIX platforms.
http://hg.python.org/cpython/rev/6ec6dbf787f4

New changeset c5f4fa02fc86 by Serhiy Storchaka in branch '3.2':
Issue #6975: os.path.realpath() now correctly resolves multiple nested symlinks on POSIX platforms.
http://hg.python.org/cpython/rev/c5f4fa02fc86

New changeset bfe9526606e2 by Serhiy Storchaka in branch '3.3':
Issue #6975: os.path.realpath() now correctly resolves multiple nested symlinks on POSIX platforms.
http://hg.python.org/cpython/rev/bfe9526606e2

New changeset f42cabe6ccb5 by Serhiy Storchaka in branch 'default':
Issue #6975: os.path.realpath() now correctly resolves multiple nested symlinks on POSIX platforms.
http://hg.python.org/cpython/rev/f42cabe6ccb5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sun Feb 10 11:29:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Feb 2013 10:29:40 +0000
Subject: [issue16967] Keyword only argument default values are evaluated
	before other defaults
In-Reply-To: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za>
Message-ID: <1360492180.83.0.482535262662.issue16967@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Agreed on it being a bug that we do it the wrong way around, but "Yikes!" at the idea of code where it makes a significant difference.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16967>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:00:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 11:00:34 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1326313998.63.0.583537561643.issue13773@psf.upfronthosting.co.za>
Message-ID: <1360494034.71.0.83035976198.issue13773@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> You can use "p" format in PyArg_ParseTuple* for boolean parameters.

That's what I used, indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13773>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:17:27 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 11:17:27 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360495047.64.0.0666107841654.issue17141@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Looks good to me.  I can confirm that the new formulas are equivalent to the old, at least for positive kappa.  (They're not the same for negative kappa, but that shouldn't matter in this context.)

Serhiy: do you know how the original formulas arose?  I don't have access to the "circular data" book, or to the original Best & Fisher paper, but that use of b in the original code is just plain peculiar;  I wonder why on earth anyone would want to go about computing  `a / (2 kappa)` that way.

I'd suggest leaving off the `u3 > 0.5` to `u3 >= 0.5` change for this particular issue;  I understand the motivation for the change, but it's unrelated to this issue, and seems like unnecessary code churn to me.

A test would be good!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:24:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 11:24:26 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360495466.72.0.203051808949.issue16997@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Any other comments on this? If not, I would like to commit soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:26:45 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 11:26:45 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360495605.88.0.971111076027.issue16997@psf.upfronthosting.co.za>


Michael Foord added the comment:

Please don't commit I think we still need a discussion as to whether subtests or paramaterized tests are a better approach. I certainly don't think we need both and there are a lot of people asking for parameterized tests. I also haven't had a chance to look at how this affects existing tools that extend unittest by implementing the TestResult api (how they will cope with test suites using subtests).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:41:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 11:41:37 +0000
Subject: [issue16997] subtests
In-Reply-To: <1360495605.88.0.971111076027.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360496309.3470.6.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Please don't commit I think we still need a discussion as to whether
> subtests or paramaterized tests are a better approach. I certainly
> don't think we need both and there are a lot of people asking for
> parameterized tests.

I think they don't cater to the same crowd. I see parameterized tests as
primarily used by people who like adding formal complexity to their
tests in the name of architectural elegance (decorators, non-intuitive
constructs and other additional boilerplate). Subtests are meant to not
get in the way. IMHO, this makes them more suitable for stdlib
inclusion, while the testing-in-python people can still rely on their
additional frameworks.

Also, subtests would be immediately and trivially usable in our own test
suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:43:19 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Feb 2013 11:43:19 +0000
Subject: [issue16997] subtests
In-Reply-To: <1360495605.88.0.971111076027.issue16997@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fA50FMACQrHUPm2U-vgz0jmUmMgEhfeg9byo_mj7Y4nA@mail.gmail.com>


Nick Coghlan added the comment:

You can use subtests to build parameterized tests, you can't use
parameterized tests to build subtests. The standard library can also
be converted to using subtests *far* more readily than it could be
converted to parameterized tests. There's also the fact that creating
a decent parameterized tests without subtests support requires PEP
422.

If you're telling us we can only have one, then I choose subtests, and
third party test frameworks can layer parameterized tests on top.
However, I think you're making a mistaking by seeing them as
*competing* APIs, rather than seeing subtests as a superior
implementation strategy for the possible later introduction of a
higher level parameterized tests API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:46:25 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 11:46:25 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360496785.47.0.848210222048.issue16997@psf.upfronthosting.co.za>


Michael Foord added the comment:

Subtests break the current unittest api of suite.countTests() and I fear they will also break tools that use the existing test result api to generate junit xml for continuous integration.

I would like to add a "parameterized test" mechanism to unittest - but preferably in a way that doesn't break all the existing tools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:50:11 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 11:50:11 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360497011.97.0.61394716114.issue16997@psf.upfronthosting.co.za>


Michael Foord added the comment:

"However, I think you're making a mistaking by seeing them as
*competing* APIs, rather than seeing subtests as a superior
implementation strategy for the possible later introduction of a
higher level parameterized tests API."

Parameterized tests are done at test collection time and sub-tests at run time. You can't layer parameterization on top of subtests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 12:57:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 11:57:54 +0000
Subject: [issue16997] subtests
In-Reply-To: <1360496785.47.0.848210222048.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360497287.3470.8.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Subtests break the current unittest api of suite.countTests() and I
> fear they will also break tools that use the existing test result api
> to generate junit xml for continuous integration.

It depends how you define countTests(). sub-tests, as the name implies,
are not independent test cases. As for breaking tools, I don't really
understand what's special about junit xml. Why would a subtest failure
be different from a test failure in that regard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:19:23 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 12:19:23 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360498763.41.0.309503113821.issue17149@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I suspect that this is simply an error in the original code:  the docstring says that mu should be in the range [0, 2*pi), so reducing mu modulo 2*pi makes little sense.  I guess the lines at the end of the method were intended to be written:

        if u3 >= 0.5:
            theta = (mu + _acos(f)) % TWOPI
        else:
            theta = (mu - _acos(f)) % TWOPI

instead of:

        if u3 >= 0.5:
            theta = (mu % TWOPI) + _acos(f)
        else:
            theta = (mu % TWOPI) - _acos(f)

That would then give consistent results, at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:21:14 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 12:21:14 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360498874.89.0.774445459656.issue16997@psf.upfronthosting.co.za>


Michael Foord added the comment:

A comment from lifeless on IRC (Robert Collins):

[12:15:46] <lifeless>	 please consider automated analysis. How can someone tell which test actually failed ?
[12:15:55] <lifeless>	 How can they run just that test in future ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:21:59 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Feb 2013 12:21:59 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1360498919.7.0.0195454267694.issue17044@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've belatedly applied the PEP update Daniel sent me, and added a reference to this issue from the PEP.

The latest version of the patch looks very good to me, just one very minor nit with the phrasing in the docs. Specifically, it is better to replace "like" with "as" in the phrase "like in the following example" to get "as in the following example".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:33:44 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 12:33:44 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360499624.67.0.296532657575.issue17149@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file29026/issue17149.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:33:55 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 12:33:55 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360499635.96.0.893796010127.issue17149@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:38:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 12:38:00 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <3Z3qRC3wkxzRn5@mail.python.org>


Roundup Robot added the comment:

New changeset 010b455de0e0 by Serhiy Storchaka in branch '2.7':
Issue #1470548: XMLGenerator now works with UTF-16 and UTF-32 encodings.
http://hg.python.org/cpython/rev/010b455de0e0

New changeset 66f92f76b2ce by Serhiy Storchaka in branch '3.2':
Issue #1470548: XMLGenerator now works with binary output streams.
http://hg.python.org/cpython/rev/66f92f76b2ce

New changeset 03b878d636cf by Serhiy Storchaka in branch '3.3':
Issue #1470548: XMLGenerator now works with binary output streams.
http://hg.python.org/cpython/rev/03b878d636cf

New changeset 12d75ca12ae7 by Serhiy Storchaka in branch 'default':
Issue #1470548: XMLGenerator now works with binary output streams.
http://hg.python.org/cpython/rev/12d75ca12ae7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:46:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 12:46:00 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <3Z3qcR3cMTzPWM@mail.python.org>


Roundup Robot added the comment:

New changeset 6e9210a092cf by Serhiy Storchaka in branch '3.2':
Fix a test for SpooledTemporaryFile (added in issue #10355).
http://hg.python.org/cpython/rev/6e9210a092cf

New changeset b5074ed74ec3 by Serhiy Storchaka in branch '3.3':
Fix a test for SpooledTemporaryFile (added in issue #10355).
http://hg.python.org/cpython/rev/b5074ed74ec3

New changeset 029011429f80 by Serhiy Storchaka in branch 'default':
Fix a test for SpooledTemporaryFile (added in issue #10355).
http://hg.python.org/cpython/rev/029011429f80

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:51:00 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 12:51:00 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360500660.17.0.881943792728.issue17149@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The message for changeset r6370f1593c72 (which introduced the incorrect code) confirms the intentions.  I'll apply this patch shortly.


iwasawa:cpython mdickinson$ hg log -v -r6370f1593c72
changeset:   7881:6370f1593c72
branch:      legacy-trunk
user:        Guido van Rossum <guido at python.org>
date:        Mon Apr 06 14:12:13 1998 +0000
files:       Lib/random.py
description:
Correction to vonmisesvariate() by Magnus Kessler: it should take and
return something between 0 and 2*pi.  Also added a reference to the
literature.

----------
assignee:  -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 13:57:59 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 12:57:59 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360501079.74.0.393852890088.issue16997@psf.upfronthosting.co.za>


Michael Foord added the comment:

My concern is that this re-uses the existing TestResult.add* methods in a different way (including calling addError multiple times). This can break existing tools.

Fix suggested by lifeless on IRC. A sub test failure / success / exception calls the following TestResult method:

   addSubTest(test, sub_id, err_or_None)


If we're using a TestResult object that doesn't have these methods (an "old" result objects) then the test can *stop* (i.e. revert to the old behaviour before sub tests existed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:13:52 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 10 Feb 2013 13:13:52 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360502032.19.0.0150078863912.issue16997@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:23:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 13:23:53 +0000
Subject: [issue13773] Support sqlite3 uri filenames
In-Reply-To: <1360494034.71.0.83035976198.issue13773@psf.upfronthosting.co.za>
Message-ID: <201302101523.31855.storchaka@gmail.com>


Serhiy Storchaka added the comment:

Oh, I were blind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13773>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:23:54 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 13:23:54 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360502634.03.0.848605227351.issue17149@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Updated patch (thanks Serhiy for reviewing).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:24:03 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 13:24:03 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360502643.28.0.985055683667.issue17149@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Added file: http://bugs.python.org/file29027/issue17149_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:32:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 13:32:38 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360503158.72.0.928118547538.issue17149@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:51:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 13:51:27 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1360504287.22.0.106696849977.issue10852@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm getting a test failure in test_ftplib:

======================================================================
ERROR: test_data_connection (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_ftplib.py", line 834, in test_data_connection
    with self.client.transfercmd('list') as sock:
  File "/home/antoine/cpython/default/Lib/ftplib.py", line 386, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "/home/antoine/cpython/default/Lib/ftplib.py", line 756, in ntransfercmd
    self.context.load_cert_chain(self.certfile, self.keyfile)
TypeError: certfile should be a valid filesystem path


Also, since we now have SNI server support, perhaps it's easier to test the change :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:53:07 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 10 Feb 2013 13:53:07 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360504387.39.0.328894483257.issue17159@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Any more comments? Any objections to applying the last patch? Anyone ready to do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Sun Feb 10 14:56:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 13:56:13 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360504573.85.0.598915344513.issue17159@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I certainly think the patch is ok on the principle. I'll let someone else pronounce on the details :-)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Sun Feb 10 15:17:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 14:17:41 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <3Z3sfF06G7zQDQ@mail.python.org>


Roundup Robot added the comment:

New changeset 6a3d18cede49 by Mark Dickinson in branch '2.7':
Issue #17149: Fix random.vonmisesvariate to always return results in [0, 2*math.pi].
http://hg.python.org/cpython/rev/6a3d18cede49

New changeset 41e97652a9f9 by Mark Dickinson in branch '3.2':
Issue #17149: Fix random.vonmisesvariate to always return results in [0, 2*math.pi].
http://hg.python.org/cpython/rev/41e97652a9f9

New changeset e9b4f2927412 by Mark Dickinson in branch '3.3':
Issue #17149: merge fix from 3.2.
http://hg.python.org/cpython/rev/e9b4f2927412

New changeset 2704e11da558 by Mark Dickinson in branch 'default':
Issue #17149: merge fix from 3.3.
http://hg.python.org/cpython/rev/2704e11da558

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 15:18:18 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 14:18:18 +0000
Subject: [issue17149] random.vonmisesvariate() results range is inconsistent
	for small and not small kappa
In-Reply-To: <1360230668.06.0.640300101338.issue17149@psf.upfronthosting.co.za>
Message-ID: <1360505898.14.0.298857374252.issue17149@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17149>
_______________________________________

From report at bugs.python.org  Sun Feb 10 15:21:31 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Feb 2013 14:21:31 +0000
Subject: [issue16967] Keyword only argument default values are evaluated
	before other defaults
In-Reply-To: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za>
Message-ID: <1360506091.02.0.594473327425.issue16967@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/issue16967>
_______________________________________

From report at bugs.python.org  Sun Feb 10 15:32:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 14:32:36 +0000
Subject: [issue16967] Keyword only argument default values are evaluated
	before other defaults
In-Reply-To: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za>
Message-ID: <3Z3szS03t3zSVc@mail.python.org>


Roundup Robot added the comment:

New changeset d296cf1600a8 by Benjamin Peterson in branch 'default':
evaluate positional defaults before keyword-only defaults (closes #16967)
http://hg.python.org/cpython/rev/d296cf1600a8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16967>
_______________________________________

From report at bugs.python.org  Sun Feb 10 15:48:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 14:48:29 +0000
Subject: [issue16967] Keyword only argument default values are evaluated
	before other defaults
In-Reply-To: <1358192234.34.0.230545519043.issue16967@psf.upfronthosting.co.za>
Message-ID: <3Z3tKm4f07zQ28@mail.python.org>


Roundup Robot added the comment:

New changeset 6917402c6191 by Benjamin Peterson in branch 'default':
evaluate lambda keyword-only defaults after positional defaults (#16967 again)
http://hg.python.org/cpython/rev/6917402c6191

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16967>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:01:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 15:01:55 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360495047.64.0.0666107841654.issue17141@psf.upfronthosting.co.za>
Message-ID: <201302101701.33678.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Serhiy: do you know how the original formulas arose? 

No. I have not found any articles or books in the open access.

> A test would be good!

I was waiting for issue13355 and issue17149. Here is an updated patch with 
tests.

----------
Added file: http://bugs.python.org/file29028/random_vonmisesvariate_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________
-------------- next part --------------
diff -r 2704e11da558 Lib/random.py
--- a/Lib/random.py	Sun Feb 10 14:17:20 2013 +0000
+++ b/Lib/random.py	Sun Feb 10 16:44:50 2013 +0200
@@ -432,22 +432,20 @@
         if kappa <= 1e-6:
             return TWOPI * random()
 
-        a = 1.0 + _sqrt(1.0 + 4.0 * kappa * kappa)
-        b = (a - _sqrt(2.0 * a))/(2.0 * kappa)
-        r = (1.0 + b * b)/(2.0 * b)
+        s = 0.5 / kappa
+        r = s + _sqrt(1.0 + s * s)
 
         while 1:
             u1 = random()
+            z = _cos(_pi * u1)
 
-            z = _cos(_pi * u1)
-            f = (1.0 + r * z)/(r + z)
-            c = kappa * (r - f)
-
+            d = z / (r + z)
             u2 = random()
-
-            if u2 < c * (2.0 - c) or u2 <= c * _exp(1.0 - c):
+            if u2 < 1.0 - d * d or u2 <= (1.0 - d) * _exp(d):
                 break
 
+        q = 1.0 / r
+        f = (q + z) / (1.0 + q * z)
         u3 = random()
         if u3 > 0.5:
             theta = (mu + _acos(f)) % TWOPI
diff -r 2704e11da558 Lib/test/test_random.py
--- a/Lib/test/test_random.py	Sun Feb 10 14:17:20 2013 +0000
+++ b/Lib/test/test_random.py	Sun Feb 10 16:44:50 2013 +0200
@@ -5,7 +5,7 @@
 import time
 import pickle
 import warnings
-from math import log, exp, pi, fsum, sin
+from math import log, exp, pi, fsum, sin, sqrt
 from test import support
 
 class TestBasicOps(unittest.TestCase):
@@ -473,6 +473,7 @@
         g.random = x[:].pop; g.paretovariate(1.0)
         g.random = x[:].pop; g.expovariate(1.0)
         g.random = x[:].pop; g.weibullvariate(1.0, 1.0)
+        g.random = x[:].pop; g.vonmisesvariate(1.0, 1.0)
         g.random = x[:].pop; g.normalvariate(0.0, 1.0)
         g.random = x[:].pop; g.gauss(0.0, 1.0)
         g.random = x[:].pop; g.lognormvariate(0.0, 1.0)
@@ -493,6 +494,8 @@
                 (g.uniform, (1.0,10.0), (10.0+1.0)/2, (10.0-1.0)**2/12),
                 (g.triangular, (0.0, 1.0, 1.0/3.0), 4.0/9.0, 7.0/9.0/18.0),
                 (g.expovariate, (1.5,), 1/1.5, 1/1.5**2),
+                (g.vonmisesvariate, (1.23, 0), pi, pi**2/3),
+                (g.vonmisesvariate, (1.23, 100), 1.23, 1/sqrt(2)/100),
                 (g.paretovariate, (5.0,), 5.0/(5.0-1),
                                   5.0/((5.0-1)**2*(5.0-2))),
                 (g.weibullvariate, (1.0, 3.0), gamma(1+1/3.0),
@@ -509,8 +512,30 @@
                 s1 += e
                 s2 += (e - mu) ** 2
             N = len(y)
-            self.assertAlmostEqual(s1/N, mu, places=2)
-            self.assertAlmostEqual(s2/(N-1), sigmasqrd, places=2)
+            self.assertAlmostEqual(s1/N, mu, places=2,
+                                   msg='%s%r' % (variate.__name__, args))
+            self.assertAlmostEqual(s2/(N-1), sigmasqrd, places=2,
+                                   msg='%s%r' % (variate.__name__, args))
+
+    def test_constant(self):
+        g = random.Random()
+        N = 100
+        for variate, args, expected in [
+                (g.uniform, (10.0, 10.0), 10.0),
+                (g.triangular, (10.0, 10.0), 10.0),
+                #(g.triangular, (10.0, 10.0, 10.0), 10.0),
+                (g.expovariate, (float('inf'),), 0.0),
+                (g.vonmisesvariate, (3.0, float('inf')), 3.0),
+                (g.gauss, (10.0, 0.0), 10.0),
+                (g.lognormvariate, (0.0, 0.0), 1.0),
+                (g.lognormvariate, (-float('inf'), 0.0), 0.0),
+                (g.normalvariate, (10.0, 0.0), 10.0),
+                (g.paretovariate, (float('inf'),), 1.0),
+                (g.weibullvariate, (10.0, float('inf')), 10.0),
+                (g.weibullvariate, (0.0, 10.0), 0.0),
+            ]:
+            for i in range(N):
+                self.assertEqual(variate(*args), expected)
 
     def test_von_mises_range(self):
         # Issue 17149: von mises variates were not consistently in the
@@ -526,6 +551,12 @@
                         msg=("vonmisesvariate({}, {}) produced a result {} out"
                              " of range [0, 2*pi]").format(mu, kappa, sample))
 
+    def test_von_mises_large_kappa(self):
+        # Issue #17141: vonmisesvariate() was hang for large kappas
+        random.vonmisesvariate(0, 1e15)
+        random.vonmisesvariate(0, 1e100)
+
+
 class TestModule(unittest.TestCase):
     def testMagicConstants(self):
         self.assertAlmostEqual(random.NV_MAGICCONST, 1.71552776992141)

From report at bugs.python.org  Sun Feb 10 16:01:57 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 15:01:57 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360508517.57.0.0912067934766.issue16997@psf.upfronthosting.co.za>


Michael Foord added the comment:

And on the "superior implementation strategy", both nose and py.test used to have runtime test generation and both have deprecated them and moved to collection time parameterization. (But I guess we know better.)

You don't need PEP 422 for parameterization. The TestLoader creates multiple test cases for the parameter sets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:18:40 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Feb 2013 15:18:40 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <1360509520.69.0.627036705775.issue12983@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12983>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:19:36 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 10 Feb 2013 15:19:36 +0000
Subject: [issue16880] Importing "imp" will fail if dynamic loading not
	supported
In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za>
Message-ID: <1360509576.16.0.820648736422.issue16880@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

Is Christian's patch going to be sufficient for the time being?  Just curious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16880>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:21:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 15:21:10 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1360509670.76.0.0422237973227.issue6975@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:23:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 15:23:06 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1360509786.95.0.746649874434.issue1470548@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:28:10 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Feb 2013 15:28:10 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360510090.34.0.519730702679.issue16997@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't really have strong feelings about this, but I will just note as a data point that I implemented parameterized tests for the email package, and have no interest myself in subtests.  This is for exactly the collection time vs runtime reason that Michael is talking about (I always want to be able to run single tests by name).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 16:45:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 15:45:32 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <3Z3vbb6mK5zPfT@mail.python.org>


Roundup Robot added the comment:

New changeset 305210a08fc9 by Serhiy Storchaka in branch '3.2':
Issue #12983: Bytes literals with invalid \x escape now raise a SyntaxError
http://hg.python.org/cpython/rev/305210a08fc9

New changeset d5b731446a91 by Serhiy Storchaka in branch '3.3':
Issue #12983: Bytes literals with invalid \x escape now raise a SyntaxError
http://hg.python.org/cpython/rev/d5b731446a91

New changeset fe410292cba6 by Serhiy Storchaka in branch 'default':
Issue #12983: Bytes literals with invalid \x escape now raise a SyntaxError
http://hg.python.org/cpython/rev/fe410292cba6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12983>
_______________________________________

From report at bugs.python.org  Sun Feb 10 17:06:20 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 16:06:20 +0000
Subject: [issue9815] assertRaises as a context manager keeps tracebacks and
	frames alive
In-Reply-To: <1284103100.0.0.404704166803.issue9815@psf.upfronthosting.co.za>
Message-ID: <1360512380.85.0.781250660436.issue9815@psf.upfronthosting.co.za>


Michael Foord added the comment:

The patch py3k_fix__AssertRaisesContext.patch looks good. A test would be nice. The code already attempts to sanitize the traceback, so sanitizing __cause__ and __context__ seems reasonable.

----------
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9815>
_______________________________________

From report at bugs.python.org  Sun Feb 10 17:13:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 16:13:17 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360512797.69.0.259596122105.issue16997@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch implementing Michael's and lifeless' proposed strategy.

----------
Added file: http://bugs.python.org/file29029/subtests5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Sun Feb 10 17:35:29 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 16:35:29 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360514129.71.0.233732057653.issue17141@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I don't think the second added test_avg_std test makes sense, given that the number of random samples used by vonmisesvariate is unpredictable.  The variance in the second case should be close to 1/100.0 rather than 1/sqrt(2)/100.0, right?  If this code stays, there should at least be a comment explaining where the extra sqrt(2) comes from.

Apart from that, this patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:19:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 17:19:11 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <1360516751.14.0.413158888854.issue12983@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12983>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:19:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 17:19:37 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360516777.35.0.768879723059.issue17141@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The variance in the second case should be close to 1/100.0 rather than 1/sqrt(2)/100.0, right?

Yes, but experiments exposed precisely 1/sqrt(2)/100.0 and I were confused by this fact. But now I noticed a comment at the top of the test: "Only works for distributions which do not consume variates in pairs". This test is not applicable to vonmisesvariate() which consumes more than one variate. u1, u2 and u3 are not independent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:32:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 17:32:44 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <3Z3xzJ2mNyzRJp@mail.python.org>


Roundup Robot added the comment:

New changeset 0f9113e1b541 by Serhiy Storchaka in branch '2.7':
Issue #17141: random.vonmisesvariate() no more hangs for large kappas.
http://hg.python.org/cpython/rev/0f9113e1b541

New changeset d94b73c95646 by Serhiy Storchaka in branch '3.2':
Issue #17141: random.vonmisesvariate() no more hangs for large kappas.
http://hg.python.org/cpython/rev/d94b73c95646

New changeset bdd993847ad0 by Serhiy Storchaka in branch '3.3':
Issue #17141: random.vonmisesvariate() no more hangs for large kappas.
http://hg.python.org/cpython/rev/bdd993847ad0

New changeset 407625051c45 by Serhiy Storchaka in branch 'default':
Issue #17141: random.vonmisesvariate() no more hangs for large kappas.
http://hg.python.org/cpython/rev/407625051c45

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:34:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 17:34:17 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360517657.49.0.0871088589592.issue17141@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:34:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 17:34:36 +0000
Subject: [issue17141] random.vonmisesvariate() hangs for large kappa
In-Reply-To: <1360154281.17.0.94704348847.issue17141@psf.upfronthosting.co.za>
Message-ID: <1360517676.26.0.870430916148.issue17141@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks for review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17141>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:37:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 17:37:40 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1360517860.29.0.508700798827.issue8865@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Sun Feb 10 18:44:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 17:44:54 +0000
Subject: [issue8865] select.poll is not thread safe
In-Reply-To: <1275344415.87.0.130024541357.issue8865@psf.upfronthosting.co.za>
Message-ID: <1360518294.48.0.808051516243.issue8865@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Patches look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8865>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:12:02 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:12:02 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1360519922.65.0.785365162877.issue10557@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:14:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:14:20 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360520060.7.0.216409877413.issue17130@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

+1 for runcall() and the context manager.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:14:29 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:14:29 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360520069.45.0.541570933559.issue4591@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

No objections here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:16:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:16:31 +0000
Subject: [issue14914] pysetup installed distribute despite dry run option
	being specified
In-Reply-To: <1337957545.29.0.422035789743.issue14914@psf.upfronthosting.co.za>
Message-ID: <1360520191.86.0.607463569673.issue14914@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Should this remain open?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14914>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:18:07 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:18:07 +0000
Subject: [issue4945] json checks True/False by identity, not boolean value
In-Reply-To: <1231911098.49.0.621266929609.issue4945@psf.upfronthosting.co.za>
Message-ID: <1360520287.7.0.845729898579.issue4945@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

According to the experts index, Bob is no longer actively maintaining the module.

----------
assignee: bob.ippolito -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:19:12 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:19:12 +0000
Subject: [issue17073] Integer overflow in sqlite module
In-Reply-To: <1359478908.69.0.671503350697.issue17073@psf.upfronthosting.co.za>
Message-ID: <1360520352.61.0.817275688049.issue17073@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/issue17073>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:26:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:26:00 +0000
Subject: [issue6331] Add unicode script info to the unicode database
In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za>
Message-ID: <1360520760.93.0.732534049971.issue6331@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson, haypo, lemburg, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6331>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:26:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:26:47 +0000
Subject: [issue17072] Decimal, quantize, round and negative value
In-Reply-To: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za>
Message-ID: <1360520807.73.0.899415735532.issue17072@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

It's not obvious to me how the documentation could be made clearer:  all the rounding modes are described at

http://docs.python.org/2/library/decimal.html#decimal.Context

for the Python 2 docs, and in a separate section entitled 'Rounding modes' for the Python 3 docs:

http://docs.python.org/3/library/decimal.html#rounding-modes

Did you have a particular documentation enhancement in mind?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17072>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:27:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:27:42 +0000
Subject: [issue16245] Update html.entities.html5 dictionary and
	parseentities.py
In-Reply-To: <1350380511.49.0.860998010837.issue16245@psf.upfronthosting.co.za>
Message-ID: <1360520862.99.0.636977855233.issue16245@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16245>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:27:55 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 10 Feb 2013 18:27:55 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1360520875.67.0.872376966385.issue12641@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

In scope of this issue I would like to propose following patch set.
First step is remove checks for versions used in past millenium, i.e. to avoid checks for 15 year old binaries.

----------
Added file: http://bugs.python.org/file29030/issue12641-modernize_cygwin&mingw_compilers.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:30:02 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 10 Feb 2013 18:30:02 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1360521002.07.0.126007577372.issue12641@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Next step is to propose customization for cygwin&mingw compilers.

----------
keywords: +patch
Added file: http://bugs.python.org/file29031/0001-MINGW-issue12641-customize-mingw-cygwin-compilers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:30:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:30:11 +0000
Subject: [issue17175] update PEP 430
In-Reply-To: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>
Message-ID: <1360521011.85.0.906130702581.issue17175@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17175>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:32:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 18:32:32 +0000
Subject: [issue17165] Use "except ImportError" instead of bare except in
	_strptime.py
In-Reply-To: <1360396478.11.0.456906472362.issue17165@psf.upfronthosting.co.za>
Message-ID: <3Z3zJH4yTFzRJp@mail.python.org>


Roundup Robot added the comment:

New changeset 1557d25b0f6e by Antoine Pitrou in branch 'default':
Issue #17165: fix a bare import in _strptime.py.
http://hg.python.org/cpython/rev/1557d25b0f6e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17165>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:32:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:32:58 +0000
Subject: [issue17165] Use "except ImportError" instead of bare except in
	_strptime.py
In-Reply-To: <1360396478.11.0.456906472362.issue17165@psf.upfronthosting.co.za>
Message-ID: <1360521178.91.0.568556754974.issue17165@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed, thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17165>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:34:16 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 10 Feb 2013 18:34:16 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1360521256.9.0.87753953002.issue12641@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

And optionally If someone disagree options m{no-}cygwin  to be removed I would like to propose a patch '..check if cygwin/mingw... -m{no-}cygwin' to restore it for GCC before 4.6x.

----------
Added file: http://bugs.python.org/file29032/0001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:35:29 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:35:29 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1360521329.47.0.670252295877.issue15438@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Updated patch.  Thanks Ezio and David for reviewing.

----------
assignee:  -> mark.dickinson
priority: low -> normal
Added file: http://bugs.python.org/file29033/issue15438_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:36:42 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:36:42 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1360521402.35.0.599703788217.issue15438@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Whoops.  Removing a bonus non-grammatical 'function'.

----------
Added file: http://bugs.python.org/file29034/issue15438_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:40:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:40:17 +0000
Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames
In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za>
Message-ID: <1360521617.89.0.466858009307.issue17094@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +neologix, pitrou
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17094>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:45:24 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 10 Feb 2013 18:45:24 +0000
Subject: [issue832159] Bad value for Mingw32Compiler.compiler_cxx
Message-ID: <1360521924.73.0.237280941279.issue832159@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

In scope of issue12641 (Remove -mno-cygwin from distutils) I just publish a set of patches to modernize support for cygwin&mingw compilers.

My tests show that swig could be used successfully with patched mingw compiler. Test is based on patched official release 3.3.0 and my custom build of current master source with GNU windows compiler.
For protocol tested swig version is 2.0.9 and may be due syntax change swig module has to be described as :
-----
/* hello.i */
%module hello
%{
extern void hello(void);
%}

extern void hello(void);
-----

Distutils complain for --swig-cpp so command now is "python setup.py build_ext -cmingw32 --swig-cpp -f"

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue832159>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:46:06 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 10 Feb 2013 18:46:06 +0000
Subject: [issue832159] Bad value for Mingw32Compiler.compiler_cxx
Message-ID: <1360521966.06.0.968272811383.issue832159@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Uhh "python setup.py build_ext -cmingw32 --swig-opts=-c++ -f"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue832159>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:51:25 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:51:25 +0000
Subject: [issue16447] SEGFAULT when setting type.__name__
In-Reply-To: <1352419760.39.0.728241030951.issue16447@psf.upfronthosting.co.za>
Message-ID: <1360522285.76.0.403771374561.issue16447@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/issue16447>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:52:50 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:52:50 +0000
Subject: [issue16445] SEGFAULT when deleting Exception.message
In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za>
Message-ID: <1360522370.17.0.977168467307.issue16445@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Can I suggest fixing this particular issue with a dedicated patch, and opening another issue to consider the large automated replacements that Victor's proposing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16445>
_______________________________________

From report at bugs.python.org  Sun Feb 10 19:56:51 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2013 18:56:51 +0000
Subject: [issue16445] SEGFAULT when deleting Exception.message
In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za>
Message-ID: <1360522611.33.0.079797751045.issue16445@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's a simple patch (against 2.7) for this particular issue.

----------
Added file: http://bugs.python.org/file29035/issue16445.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16445>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:07:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Feb 2013 19:07:33 +0000
Subject: [issue16445] SEGFAULT when deleting Exception.message
In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za>
Message-ID: <1360523253.28.0.463365835406.issue16445@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Here's a simple patch (against 2.7) for this particular issue.

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16445>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:07:58 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Feb 2013 19:07:58 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1360523278.28.0.686854241672.issue10852@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:23:28 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Feb 2013 19:23:28 +0000
Subject: [issue17167] python man page contains $Date$ in page footer
In-Reply-To: <1360400635.24.0.00924107320182.issue17167@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOR90r=Yp+ts4Z77gdCF7hRXSLDO2scsed-+oafEPPJLwg@mail.gmail.com>


Senthil Kumaran added the comment:

There is another option. To have the same behavior like svn keywords
through hg. Having this setting at server hgrc can help.
This will be useful if we have more than one instance of keyword expansion.

[extensions]
keyword=

[keyword]
**/*.man =

[keywordmaps]
date = {date|rfc822date}

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17167>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:26:35 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Feb 2013 19:26:35 +0000
Subject: [issue17164] MozillaCookieJar does not handle session cookies
In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za>
Message-ID: <1360524395.35.0.379415661863.issue17164@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17164>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:32:13 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Feb 2013 19:32:13 +0000
Subject: [issue17167] python man page contains $Date$ in page footer
In-Reply-To: <1360400635.24.0.00924107320182.issue17167@psf.upfronthosting.co.za>
Message-ID: <1360524733.93.0.573658295343.issue17167@psf.upfronthosting.co.za>


Ned Deily added the comment:

The keyword extension would have to be added by everyone to their existing .hgrc files and the Mercurial developers discourage its use ("This is considered a feature of last resort.").  Better to eliminate the keyword in the source.  There were others that have already been taken care of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17167>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:43:32 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Feb 2013 19:43:32 +0000
Subject: [issue17158] help() module searcher text improvement
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT0jCEHG9FYom3OH5Tf2oQ-p7txYK2khUToWh6cSYc_2A@mail.gmail.com>


Senthil Kumaran added the comment:

You will stumble on that message, only if you give help("module
<somename>") and note that <somename> could be any module in the
PYTHONPATH.
We can change to show the text only if the module is a valid module,
but I think, it is costly do that computation for help text. A better
approach would be:
Modules matching the keyword: <somemodule>

The output can be a list or None.

If you will like to work on a patch, the changes will be in listmodule
function in Lib/pydoc.py

----------
nosy: +orsenthil
title: help() module searcher text is misleading -> help() module searcher text improvement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:47:59 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Feb 2013 19:47:59 +0000
Subject: [issue16880] Importing "imp" will fail if dynamic loading not
	supported
In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za>
Message-ID: <1360525679.86.0.633783372814.issue16880@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Yes, Christian's patch should do the trick for fixing the problem you reported, Jeffrey.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16880>
_______________________________________

From report at bugs.python.org  Sun Feb 10 20:50:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Feb 2013 19:50:27 +0000
Subject: [issue17176] Document imp.NullImporter is NOT used anymore by import
Message-ID: <1360525827.54.0.547409827798.issue17176@psf.upfronthosting.co.za>


New submission from Brett Cannon:

imp.NullImporter should not be claiming that it is still used to fill sys.path_importer_cache on misses.

----------
assignee: brett.cannon
components: Documentation
messages: 181846
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Document imp.NullImporter is NOT used anymore by import
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17176>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:04:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 20:04:07 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <3Z41Ky4PhjzScf@mail.python.org>


Roundup Robot added the comment:

New changeset b322655a4a88 by Serhiy Storchaka in branch '3.3':
Issue #4591: Uid and gid values larger than 2**31 are supported now.
http://hg.python.org/cpython/rev/b322655a4a88

New changeset 94256de0aff0 by Serhiy Storchaka in branch 'default':
Issue #4591: Uid and gid values larger than 2**31 are supported now.
http://hg.python.org/cpython/rev/94256de0aff0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:06:38 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 10 Feb 2013 20:06:38 +0000
Subject: [issue17086] backport cross-build patches to the 2.7 branch
In-Reply-To: <1359587420.86.0.11365762234.issue17086@psf.upfronthosting.co.za>
Message-ID: <1360526798.84.0.686010375755.issue17086@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

http://hg.python.org/cpython/rev/8ee6d96a1019#l5.150

You changed PYTHONPATH, but all other branches (e.g. 3.3 and default) set previous value (PYTHONPATH="`pwd`/Lib"). Was it an accidental change?

----------
nosy: +Arfrever
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17086>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:08:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Feb 2013 20:08:31 +0000
Subject: [issue17177] Document/deprecate imp
Message-ID: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I need a make a decision as to what (if anything) belongs in imp and then document what stays and deprecate everything else.

Everything in imp falls into one of the following categories:

* From importlib
  - get_magic()
  - source_from_cache()
  - cache_from_source()
* From sys
  - get_tag()
* Platform-implemented
  - lock_held()
  - acquire_lock()
  - release_lock()
  - Undocumented stuff related to builtins, frozen, and load_dynamic()
* Helper
  - reload()

The question is what to keep/expose in imp and what to deprecate. Basically I need to figure out what imp's role is supposed to be in the face of importlib. My gut says either expose platform-dependent stuff and reload() and move the rest to importlib/deprecate, or to completely do away with the module and force people to use the APIs in importlib for consistency (and to stop people from mucking around with import from outside of importlib).

----------
assignee: brett.cannon
components: Library (Lib)
messages: 181849
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Document/deprecate imp
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:26:04 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Feb 2013 20:26:04 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360527964.81.0.129786859567.issue17128@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

It should be noted that latest OSX Mountain Lion has caused problems for other language libraries too (specifically ruby, which I use at work). Ease the support of correct openssl in OSX may help a long way in all versions of python.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17128>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:31:27 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 10 Feb 2013 20:31:27 +0000
Subject: [issue16880] Importing "imp" will fail if dynamic loading not
	supported
In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za>
Message-ID: <1360528287.14.0.765761985154.issue16880@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

Sorry, I think my question was a bit vague.  Christian's patch does, in fact, work fine for fixing the problem as reported.  I was wondering if the patch was sufficient to close the bug with a commit.  I didn't know if other work was ongoing to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16880>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:34:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 20:34:23 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360528463.59.0.906110008772.issue4591@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks like this broke some buildbots:


======================================================================
ERROR: test_chown (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/test/test_shutil.py", line 1209, in test_chown
    shutil.chown(filename, 3.14)
  File "/usr/home/buildbot/buildarea/3.3.krah-freebsd/build/Lib/shutil.py", line 1024, in chown
    os.chown(path, _user, _group)
PermissionError: [Errno 1] Operation not permitted: '/tmp/tmp3f82m0/tmp_ttyx5'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:39:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 10 Feb 2013 20:39:54 +0000
Subject: [issue16880] Importing "imp" will fail if dynamic loading not
	supported
In-Reply-To: <1357485625.89.0.912311839023.issue16880@psf.upfronthosting.co.za>
Message-ID: <1360528794.43.0.489239205411.issue16880@psf.upfronthosting.co.za>


Brett Cannon added the comment:

A commit to Python 3.3 and 3.4 would be enough to close this bug. Just a matter of Christian or someone else finding the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16880>
_______________________________________

From report at bugs.python.org  Sun Feb 10 21:40:05 2013
From: report at bugs.python.org (Hakim Taklanti)
Date: Sun, 10 Feb 2013 20:40:05 +0000
Subject: [issue17072] Decimal, quantize, round and negative value
In-Reply-To: <1359476056.94.0.303954404669.issue17072@psf.upfronthosting.co.za>
Message-ID: <1360528805.82.0.604434846823.issue17072@psf.upfronthosting.co.za>


Hakim Taklanti added the comment:

You is right. I had just see the beginning of documentation ("Rounding options include..."). Sorry for the bother and thanks for the answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17072>
_______________________________________

From report at bugs.python.org  Sun Feb 10 22:09:48 2013
From: report at bugs.python.org (mike bayer)
Date: Sun, 10 Feb 2013 21:09:48 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1360530588.59.0.528035165571.issue9253@psf.upfronthosting.co.za>


mike bayer added the comment:

um, this seems like a regression/bug?   I now have users complaining that my apps are broken because of this change as of Python 3.3.    My application is supposed to return the "help" screen when no command is given.  Now I get a None error because argparse is not trapping this condition:

from argparse import ArgumentParser
parser = ArgumentParser(prog='test')
subparsers = parser.add_subparsers()
subparser = subparsers.add_parser("foo", help="run foo")
parser.parse_args()

$ python3.2 test.py
usage: test [-h] {foo} ...
test: error: too few arguments

$ python3.3 test.py
$

This seems very much like a major feature has been yanked away from argparse, now I have to check for this condition explicitly.

am I on the right issue here or do I need to open something new ?

----------
nosy: +zzzeek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Sun Feb 10 22:29:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Feb 2013 21:29:28 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <3Z43DR5NDbzPmX@mail.python.org>


Roundup Robot added the comment:

New changeset 4ef048f4834e by Serhiy Storchaka in branch '3.3':
Reject float as uid or gid.
http://hg.python.org/cpython/rev/4ef048f4834e

New changeset 3fdcffdfd3e6 by Serhiy Storchaka in branch 'default':
Reject float as uid or gid.
http://hg.python.org/cpython/rev/3fdcffdfd3e6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Feb 10 22:41:34 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 21:41:34 +0000
Subject: [issue1778410] removeTest() method patch for unittest.TestSuite
Message-ID: <1360532494.01.0.281662004677.issue1778410@psf.upfronthosting.co.za>


Michael Foord added the comment:

I'm pretty sure the proposed patch doesn't work - but there's no test for it so I can't be sure. I can't think of a better basic strategy, but the strategy here is horrible. This means I'm sympathetic to the desire for a removeTest method but not very enthusiastic about implementing it (and certainly not this implementation I'm afraid).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778410>
_______________________________________

From report at bugs.python.org  Sun Feb 10 22:42:09 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 21:42:09 +0000
Subject: [issue1778410] removeTest() method patch for unittest.TestSuite
Message-ID: <1360532529.78.0.163312828625.issue1778410@psf.upfronthosting.co.za>


Michael Foord added the comment:

I think better filtering at the collection phase - collecting tests by name or filtering out tests by name - could obviate the need for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1778410>
_______________________________________

From report at bugs.python.org  Sun Feb 10 22:48:01 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 10 Feb 2013 21:48:01 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1360532881.72.0.896652526966.issue7897@psf.upfronthosting.co.za>


Michael Foord added the comment:

Looks like we're going to get subtests ( issue #16997 ) instead of parameterized tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7897>
_______________________________________

From report at bugs.python.org  Sun Feb 10 23:38:47 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 10 Feb 2013 22:38:47 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360535927.92.0.426164776496.issue4591@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Not technically the topic of this issue, but should we just lock
down _Py_Uid_Converter() to ints?

This is still accepted:

os.setuid(Decimal("1000.2"))

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Sun Feb 10 23:46:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 22:46:55 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1360535927.92.0.426164776496.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360536226.3470.11.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Not technically the topic of this issue, but should we just lock
> down _Py_Uid_Converter() to ints?

The right way to do it should be to use PyNumber_Index().

(perhaps we need as PyNumber_AsLongIndex() to do the direct conversion
to a C long, it would make things easier in many cases)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 00:35:15 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Sun, 10 Feb 2013 23:35:15 +0000
Subject: [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360539315.19.0.702866628617.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Draft of new updates based on Eric's feedback. I haven't done a final proof-reading over this patch as I wanted to upload it and see if I'm heading in the right direction first.

----------
Added file: http://bugs.python.org/file29036/patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6696>
_______________________________________

From report at bugs.python.org  Mon Feb 11 01:28:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Feb 2013 00:28:23 +0000
Subject: [issue17052] unittest discovery should use self.testLoader
In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>
Message-ID: <3Z47Bt4RFhzSjD@mail.python.org>


Roundup Robot added the comment:

New changeset b53b029895df by Michael Foord in branch 'default':
Merge. Closes issue 17052.
http://hg.python.org/cpython/rev/b53b029895df

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17052>
_______________________________________

From report at bugs.python.org  Mon Feb 11 01:32:48 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Feb 2013 00:32:48 +0000
Subject: [issue16935] unittest should understand SkipTest at import time
	during test discovery
In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za>
Message-ID: <1360542768.77.0.204154346554.issue16935@psf.upfronthosting.co.za>


Michael Foord added the comment:

The patch looks good - can you add a test and documentation for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16935>
_______________________________________

From report at bugs.python.org  Mon Feb 11 01:36:54 2013
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 11 Feb 2013 00:36:54 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1360543014.16.0.904463145321.issue12641@psf.upfronthosting.co.za>


Matthias Klose added the comment:

2.7, 3.3 and 3.4 now have AC_CANONICAL_HOST. So the correct compiler should be picked up.  please could somebody validate this? or are explicit --host and --build options required for configure?

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Mon Feb 11 02:12:57 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 11 Feb 2013 01:12:57 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360545177.78.0.296424769498.issue16997@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I'm still opposed to exposing these features only together.  Annotating the failure message with parametrization data is useful in its own right, but what if there are 500 subtests in a loop and you don't want 500 failures to be registered for that test case?  This is related to Ezio's comment near the top about adding too much noise.

addMessage was just one suggestion.  A different, functionally equivalent suggestion would be to add a "failFast" (default: False) keyword parameter to subTest() or alternatively a "maxFailures" (default: None) keyword parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 02:26:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 11 Feb 2013 01:26:51 +0000
Subject: [issue17052] unittest discovery should use self.testLoader
In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>
Message-ID: <1360546011.61.0.543013510935.issue17052@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Michael, was this implemented correctly?  Loader should be a callable (e.g. a class), but self.testLoader is an instance (it defaults to loader.defaultTestLoader, which equals loader.TestLoader()):

http://hg.python.org/cpython/file/b53b029895df/Lib/unittest/loader.py#l302

----------
stage: committed/rejected -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17052>
_______________________________________

From report at bugs.python.org  Mon Feb 11 02:46:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Feb 2013 01:46:25 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360547185.12.0.107768114753.issue17159@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am puzzled by this part of the patch:

- with self.assertRaisesRegex(TypeError, 'is not a callable object'):
+ with self.assertRaisesRegex(TypeError, '42.*is not a callable object'):

With 3.3, I get "TypeError: 42 is not a callable object", which I consider correct, and which should not be changed by the two changes to signature().  So both the old test, missing '42' (how does it pass?) and the new version, with extraneous '.*' look wrong.

I am also puzzled by the 'from None' part in
+ raise TypeError("'{!r}' is not a Python function".format(func)) from None

While I remember that being in the pydev discussion and while "raise XyzError from None" executes, it does not seems to be documented for 3.3 in 7.8. The raise statement. (Should this be another issue?) In fact, that section says " if given, the second expression must be another exception class or instance", which excludes None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Mon Feb 11 04:13:17 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Feb 2013 03:13:17 +0000
Subject: [issue17158] help() module searcher text improvement
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <1360552397.17.0.190055993287.issue17158@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking further at the pydoc code, I see that "Here is a list. Enter any listed item to get more help", with both sentences printed before the list, is normal. Having a post-list prompt for the list of all modules is the exception. So I would no longer make the change proposed in my first patch and would instead look to rewording along the line Senthil suggested.

listmodules(key) calls apropos(key) after printing the header. That function in turn creates a ModuleScanner and calls .run with a callback. So making the prompt conditional on whether or not anything is found would require modification of ModuleScanner.run(), apropos(), and listscanner(). As indicated by my first patch, I agree with Senthil that it is not worth the effort when a better prompt should do.

A deeper problem is this: the prompt "Enter any listed item to get more help." is only valid if one asks for the list in help mode, at the "help> " prompt. If one asks for the list at the normal interpreter ">>> " prompt with "help('xxx')", as described in the original post, then entering the name of the listed item at the next ">>> " prompt is wrong. One should instead wrap the text with "help('" and "')", or enter help() mode first. However, I have not yet discovered a way to detect the context of the list request so that the prompt could be modified.

The Welcome text could also use a couple of changes.
1. It does not mention the new symbol help.
"To get a list of available modules, keywords, or topics, type "modules", "keywords", or "topics".
should include symbols and "symbols".
2. This: '''to list the modules whose summaries contain a given word
such as "spam",'''
is more accurately written as this:
'''to list the modules whose name or summary contain a
given string such as "spam",'''

Attached is a second patch with the easy fixes, without touching the context-prompt issue.

A possible commit message: Add 'symbols' to help welcome message; clarify 'modules spam' messages.

----------
Added file: http://bugs.python.org/file29037/Issue17158-b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Mon Feb 11 04:21:17 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 11 Feb 2013 03:21:17 +0000
Subject: [issue17111] test_surrogates of test_fileio fails sometimes on OS X
	10.4
In-Reply-To: <1359881195.85.0.467111019736.issue17111@psf.upfronthosting.co.za>
Message-ID: <1360552877.67.0.201859117921.issue17111@psf.upfronthosting.co.za>


Ned Deily added the comment:

After writing the simplest possible test of open(2) in C to eliminate anything in Python, I finally established that the seemingly random behavior of the test is in fact caused by a rather odd bug in OS X 10.4.  The filename being used in the test is intended to be invalidly encoded.  On 10.4, open(2) of that filename returns errno 2 (ENOENT) as expected *if* the containing directory is empty.  But if there is at least one existing file in the directory, the open returns errno 22 (EINVAL) instead.  Go figure!  Knowing that, it's easy to reproduce the test failure by running the test directly.  So, the buildbot failures are intermittent depending on what files previous tests have left behind in the working directory. (I haven't checked intermediate versions but current OS X 10.8 does not have this odd behavior: ENOENT is always returned.)  The original proposed solution still seems to me to be the right one: simply change the test to pass if either EINVAL or ENOENT is returned.

----------
assignee:  -> ned.deily
stage: patch review -> commit review
Added file: http://bugs.python.org/file29038/issue17111.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17111>
_______________________________________

From report at bugs.python.org  Mon Feb 11 04:23:12 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 11 Feb 2013 03:23:12 +0000
Subject: [issue17111] test_surrogates of test_fileio fails sometimes on OS X
	10.4
In-Reply-To: <1359881195.85.0.467111019736.issue17111@psf.upfronthosting.co.za>
Message-ID: <1360552992.38.0.42096863951.issue17111@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file28937/issue_XXXXX_test_fileio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17111>
_______________________________________

From report at bugs.python.org  Mon Feb 11 04:37:34 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 11 Feb 2013 03:37:34 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360553854.64.0.243689160097.issue16997@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

It seems like the last patch (subtests5.patch) dropped the parameter data from the failure output as described in the docs.  For example, the example in the docs yields the following:

    FAIL: test_even (__main__.NumbersTest)

instead of the documented:

    FAIL: test_even (__main__.NumbersTest) (i=1)

subtests4.patch is okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 04:53:18 2013
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 11 Feb 2013 03:53:18 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360554798.3.0.840080193169.issue16997@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 05:15:34 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 11 Feb 2013 04:15:34 +0000
Subject: [issue17052] unittest discovery should use self.testLoader
In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>
Message-ID: <1360556134.36.0.899413386839.issue17052@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

+- Issue #17502: unittest discovery should use self.testLoader.

Also, this should read Issue #17052.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17052>
_______________________________________

From report at bugs.python.org  Mon Feb 11 06:47:24 2013
From: report at bugs.python.org (py.user)
Date: Mon, 11 Feb 2013 05:47:24 +0000
Subject: [issue17178] In all.__doc__ and any.__doc__ need to clarify the
	behaviour with an empty iterable like in documentation
Message-ID: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>


New submission from py.user:

>>> help(all)

"
all(...)
    all(iterable) -> bool
    
    Return True if bool(x) is True for all values x in the iterable.
"

>>> all([])
True
>>> bool()
False
>>>

----------
assignee: docs at python
components: Documentation
messages: 181873
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In all.__doc__ and any.__doc__ need to clarify the behaviour with an empty iterable like in documentation
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Mon Feb 11 07:46:49 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 11 Feb 2013 06:46:49 +0000
Subject: [issue17158] help() module searcher text improvement
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <1360565209.76.0.693658782059.issue17158@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The patch looks good to me. This change is helpful and definitely an improvement over the existing text. Please go ahead with committing it, Terry. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:06:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 07:06:45 +0000
Subject: [issue16997] subtests
In-Reply-To: <1360553854.64.0.243689160097.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360566216.3442.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> It seems like the last patch (subtests5.patch) dropped the parameter
> data from the failure output as described in the docs.  For example,
> the example in the docs yields the following:
> 
>     FAIL: test_even (__main__.NumbersTest)

Weird, since there are unit tests for that. I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:23:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Feb 2013 07:23:46 +0000
Subject: [issue17158] help() module searcher text improvement
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <3Z4JQ92YLHzSgF@mail.python.org>


Roundup Robot added the comment:

New changeset 4f84fe5a997b by Terry Jan Reedy in branch 'default':
Closes #17158: Add 'symbols' to help() welcome message; clarify 'modules spam'
http://hg.python.org/cpython/rev/4f84fe5a997b

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:26:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Feb 2013 07:26:31 +0000
Subject: [issue17158] help() module searcher text improvement
In-Reply-To: <1360333459.38.0.949998343154.issue17158@psf.upfronthosting.co.za>
Message-ID: <1360567591.26.0.102547196422.issue17158@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17158>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:29:58 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Feb 2013 07:29:58 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360567798.06.0.912333545003.issue4591@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> (perhaps we need as PyNumber_AsLongIndex() to do the direct conversion
> to a C long, it would make things easier in many cases)

+1, but drop the 'Index' part of the name, to match the existing PyNumber_AsSsize_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:33:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 07:33:44 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1360567798.06.0.912333545003.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360567835.3442.2.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > (perhaps we need as PyNumber_AsLongIndex() to do the direct conversion
> > to a C long, it would make things easier in many cases)
> 
> +1, but drop the 'Index' part of the name, to match the existing
> PyNumber_AsSsize_t.

There's already PyNumber_Long() (which doesn't use __index__), hence the
possible confusion.
Note there is also PyIndex_Check(), so we could call it
PyIndex_AsLong().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:44:27 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 11 Feb 2013 07:44:27 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360568667.34.0.949401095112.issue17159@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

1) that's a regex test, so it just looks for the text. I only extended it to include the object it's supposed to test for. It's not actually related to my changes, but I considered it the right thing to do. I used "42.*is not" in order to allow for alternative spellings like "'42' is not...".

2) "raise ... from None" is the official way to explicitly drop the exception context from a newly raised exception. Otherwise, you'd get two exceptions in this case: a TypeError (as main exception) and an AttributeError (as its context), which I do not consider helpful here as it bloats the output for an otherwise simple error. For 99% of the use cases, it won't matter which attribute was missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Mon Feb 11 08:59:47 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 11 Feb 2013 07:59:47 +0000
Subject: [issue17128] OS X system openssl deprecated - installer should build
	local libssl
In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za>
Message-ID: <1360569587.45.0.627693614853.issue17128@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

What other problems? Do you have more information on that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17128>
_______________________________________

From report at bugs.python.org  Mon Feb 11 09:01:12 2013
From: report at bugs.python.org (holger krekel)
Date: Mon, 11 Feb 2013 08:01:12 +0000
Subject: [issue16997] subtests
In-Reply-To: <1360496309.3470.6.camel@localhost.localdomain>
Message-ID: <CAPJJ-pLh_TDBX7LAJS1o4afi6oTy_EJ93oSpz83usOZtCQrovQ@mail.gmail.com>


holger krekel added the comment:

On Sun, Feb 10, 2013 at 12:41 PM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou added the comment:
>
> > Please don't commit I think we still need a discussion as to whether
> > subtests or paramaterized tests are a better approach. I certainly
> > don't think we need both and there are a lot of people asking for
> > parameterized tests.
>
> I think they don't cater to the same crowd. I see parameterized tests as
> primarily used by people who like adding formal complexity to their
> tests in the name of architectural elegance (decorators, non-intuitive
> constructs and other additional boilerplate). Subtests are meant to not
> get in the way. IMHO, this makes them more suitable for stdlib
> inclusion, while the testing-in-python people can still rely on their
> additional frameworks.
>

Parametrized testing wasn't introduced because I or others like formal
complexity.  I invented the "yield" syntax that both pytest and nose still
support and it was enhanced for several years until it was deemed not fit
for a general purpose testing approach.  More specifically, if you have
functional parametrized tests, they each run relatively slow.   People
often want to re-run a single failing test or otherwise select tests which
use a certain fixture, or send tests to different CPUs to speed up
execution.   That's all not possible with subtests or am i missing
something?

That being said, I have plans to support some form of "subtests" for pytest
as well, as there are indeed cases where a more lightweight approach fits
well, especially for unit- or integration tests where one doesn't care if a
group of tests need to be re-run when working on fixing a failure to a
single subtest.  And where it's usually more about reporting, getting nice
debuggable output on failures.  I suspect the cases which Antoine refers
satisfy this pattern.

best,
holger

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 09:09:05 2013
From: report at bugs.python.org (holger krekel)
Date: Mon, 11 Feb 2013 08:09:05 +0000
Subject: [issue16997] subtests
In-Reply-To: <CADiSq7fA50FMACQrHUPm2U-vgz0jmUmMgEhfeg9byo_mj7Y4nA@mail.gmail.com>
Message-ID: <CAPJJ-pJCyiwxsvOzOi7=aWV=hgmv4rvkvwydvUErG0wHev_aqA@mail.gmail.com>


holger krekel added the comment:

On Sun, Feb 10, 2013 at 12:43 PM, Nick Coghlan <report at bugs.python.org>wrote:

>
> Nick Coghlan added the comment:
>
> You can use subtests to build parameterized tests, you can't use
> parameterized tests to build subtests.

I doubt you can implement parametrized tests via subtests especially for
functional testing and its fixture needs.

The standard library can also
> be converted to using subtests *far* more readily than it could be
> converted to parameterized tests.

I can see that and for this reason and the stdlib's use cases it might make
sense to support it.  The unittest module is also used in many other
contexts so it shouldn't be the only verification criterium.

best,
holger

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 09:21:36 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Feb 2013 08:21:36 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360570896.16.0.0300721694956.issue4591@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Hmm;  good point.  Well, +1 to the functionality, anyway;  I'll leave the discussion about the name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 09:26:41 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Feb 2013 08:26:41 +0000
Subject: [issue17179] TypeError: type() takes 1 or 3 arguments
Message-ID: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>


New submission from Chris Withers:

>>> from types import new_class
>>> from datetime import datetime
>>> new_class('tdatetime', (datetime, ), kwds={'foo':'bar'})
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/src/Python-3.3.0/Lib/types.py", line 52, in new_class
    return meta(name, bases, ns, **kwds)
TypeError: type() takes 1 or 3 arguments

I'm guessing ns and kwds should be combined before being passed through to meta? (meta is 'type' in this case)

----------
components: Library (Lib)
messages: 181884
nosy: cjw296
priority: normal
severity: normal
status: open
title: TypeError: type() takes 1 or 3 arguments
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Mon Feb 11 10:10:56 2013
From: report at bugs.python.org (Milko Krachounov)
Date: Mon, 11 Feb 2013 09:10:56 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
Message-ID: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>


New submission from Milko Krachounov:

When copying the mode of a file with copy, copy2, copymode, copystat or copytree, all permission bits are copied (including setuid and setgit), but the owner of the file is not. This can be used for privilege escalation.

An example:

-rwSr--r--  1 milko milko    0 ??? 11 10:53 test1

shutil.copy("test1", "test2")

-rwSr--r--  1 root  root     0 ??? 11 10:53 test2

If test1 contained anything malicious, now the user milko can execute his malicious payload as root.

Potential fixes:
- Strip setuid/setgid bits.
- Copy the owner on POSIX.
- Perform a safety check on the owner.
- Document the security risk.


The behaviour of copymode/copystat in this case is the same as `chmod --reference', and there can be some expectation of unsafety, but copy/copy2/copytree's behaviour differs from that of `cp -p', and this is a non-obvious difference.

----------
components: Library (Lib)
messages: 181885
nosy: milko.krachounov
priority: normal
severity: normal
status: open
title: shutil copy* unsafe on POSIX - they preserve setuid/setgit bits
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Mon Feb 11 10:21:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 09:21:10 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360574470.43.0.756414978612.issue4591@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a problem with test_pwd on 64-bit platform. It expects KeyError on pwd.getpwuid(sys.maxsize). Actually the test is not looks robust. On 32-bit platform sys.maxsize = 2**31-1 < 2**32 and this value only by chance was not in the user database. On 64-bit platform sys.maxsize > 2**32 and in old code it was wrapped to 2**31-1 C unsigned int value and this value only by chance was not in the user database. New code doesn't wrap the value to C unsigned int and raises an overflow exception.

What should I change, a test or a raised exception?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 10:46:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Feb 2013 09:46:44 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360547185.12.0.107768114753.issue17159@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fYL8zZRyQaPA-cV6EUiZ41_X0U6HxQLHSRVUDgTbUbnQ@mail.gmail.com>


Nick Coghlan added the comment:

On Mon, Feb 11, 2013 at 11:46 AM, Terry J. Reedy <report at bugs.python.org> wrote:
> I am also puzzled by the 'from None' part in
> + raise TypeError("'{!r}' is not a Python function".format(func)) from None
>
> While I remember that being in the pydev discussion and while "raise XyzError from None" executes, it does not seems to be documented for 3.3 in 7.8. The raise statement. (Should this be another issue?) In fact, that section says " if given, the second expression must be another exception class or instance", which excludes None.

That's a separate docs bug - it seems we missed the necessary language
reference updates when implementing PEP 309. The relevant docs are
here: http://docs.python.org/3/library/exceptions.html#built-in-exceptions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Mon Feb 11 10:55:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 09:55:10 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360576510.16.0.816966924784.issue16997@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> what if there are 500 subtests in a loop and you don't want 500 failures to be
> registered for that test case?

Parametered tests have the same issue. In this case you simply don't use subtests
or test cases. On the other hand, the issue doesn't exist in most cases where you
iterate over three or four different cases.

> addMessage was just one suggestion.

It is quite orthogonal, actually, and could be added independently. Also, it is not clear how you would limit the addMessage to a subtest, rather than the whole test case.
We could re-use testtools' addDetail idea, although their content-type thing
is a bit heavyweight: I'd rather duck-type the API.

http://testtools.readthedocs.org/en/latest/for-test-authors.html#details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 11:07:39 2013
From: report at bugs.python.org (Daniel Black)
Date: Mon, 11 Feb 2013 10:07:39 +0000
Subject: [issue17181] SSLContext.set_servername_callback should be able to set
	argument
Message-ID: <1360577259.03.0.413727229481.issue17181@psf.upfronthosting.co.za>


New submission from Daniel Black:

I think my original implementation of the SNI callback to see a original sslcontext was wrong. It would be much more useful for the SSLContext.set_servername_callback to take a callable and an object as an argument.

This would allow constructs like the following where self can be used within the callback. Example:

        def cb_sni(ssl_sock, server_name, self):
            self.sniname = server_name

        self.context.set_servername_callback(cb_sni, self)

The original functionality can still occur with:

        self.context.set_servername_callback(cb_sni, self.context)

Agree?

----------
components: Library (Lib)
messages: 181889
nosy: grooverdan, pitrou
priority: normal
severity: normal
status: open
title: SSLContext.set_servername_callback should be able to set argument
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17181>
_______________________________________

From report at bugs.python.org  Mon Feb 11 11:20:41 2013
From: report at bugs.python.org (Daniel Black)
Date: Mon, 11 Feb 2013 10:20:41 +0000
Subject: [issue10852] SSL/TLS sni use in smtp, pop, imap, nntp,
	ftp client libs by default
In-Reply-To: <1294375380.08.0.187691378511.issue10852@psf.upfronthosting.co.za>
Message-ID: <1360578041.16.0.71162455157.issue10852@psf.upfronthosting.co.za>


Daniel Black added the comment:

Ack. Have fix. Simple if self.certfile or self.keyfile: test added before load_cert_chain.

part way through developing test. Thinking #17181 would help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10852>
_______________________________________

From report at bugs.python.org  Mon Feb 11 11:26:26 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Feb 2013 10:26:26 +0000
Subject: [issue17052] unittest discovery should use self.testLoader
In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>
Message-ID: <1360578386.87.0.220112299413.issue17052@psf.upfronthosting.co.za>


Michael Foord added the comment:

I think you're right! Thanks.

----------
assignee:  -> michael.foord
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17052>
_______________________________________

From report at bugs.python.org  Mon Feb 11 11:55:17 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Feb 2013 10:55:17 +0000
Subject: [issue17152] Array module should support "boolean" natively
In-Reply-To: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>
Message-ID: <1360580117.13.0.85983993475.issue17152@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

we have a -1, so I close this as "rejected".

I still think it is a valuable idea to pursuit.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17152>
_______________________________________

From report at bugs.python.org  Mon Feb 11 11:55:30 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 11 Feb 2013 10:55:30 +0000
Subject: [issue17152] Array module should support "boolean" natively
In-Reply-To: <1360252420.36.0.0246801123884.issue17152@psf.upfronthosting.co.za>
Message-ID: <1360580130.89.0.462204124989.issue17152@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17152>
_______________________________________

From report at bugs.python.org  Mon Feb 11 12:37:11 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Feb 2013 11:37:11 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1360582631.07.0.23776597157.issue17044@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Mon Feb 11 14:39:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Feb 2013 13:39:58 +0000
Subject: [issue17052] unittest discovery should use self.testLoader
In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>
Message-ID: <3Z4SmF4c4DzSj9@mail.python.org>


Roundup Robot added the comment:

New changeset ece0a2e6b08e by Michael Foord in branch '2.7':
Correction to issue 17052 fix
http://hg.python.org/cpython/rev/ece0a2e6b08e

New changeset 867763eb6985 by Michael Foord in branch '3.2':
Correction to issue 17052 fix
http://hg.python.org/cpython/rev/867763eb6985

New changeset a79650aacb43 by Michael Foord in branch 'default':
Merge. Closes issue 17052.
http://hg.python.org/cpython/rev/a79650aacb43

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17052>
_______________________________________

From report at bugs.python.org  Mon Feb 11 14:59:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 13:59:50 +0000
Subject: [issue17182] signal.default_int_handler should set signal number on
	the raised exception
Message-ID: <1360591190.95.0.210480467275.issue17182@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Having a dedicated optional attribute on KeyboardInterrupt receiving the signal number would be useful in certain circumstances, for example if you want to propagate the signal to a child process.

----------
components: Extension Modules
messages: 181894
nosy: pitrou
priority: normal
severity: normal
status: open
title: signal.default_int_handler should set signal number on the raised exception
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17182>
_______________________________________

From report at bugs.python.org  Mon Feb 11 15:03:01 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Feb 2013 14:03:01 +0000
Subject: [issue17063] assert_called_with could be more powerful if it allowed
	placeholders
In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za>
Message-ID: <1360591381.45.0.220577890028.issue17063@psf.upfronthosting.co.za>


Michael Foord added the comment:

I still don't particularly like the idea of the assert_* methods returning something.

If the call args tuples had args and kwargs attributes, for which there are outstanding feature requests, then you could simply do:

my_mock(1, someobj(), bar=someotherobj())

foo = my_mock.call_args.args[1]
bar = my_mock.call_args.kwargs['bar']

By avoiding the extra step of tuple unpacking this is still nice and readable (IMO).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17063>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:14:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Feb 2013 15:14:49 +0000
Subject: [issue17064] Fix sporadic buildbot failures for test_mailbox
In-Reply-To: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za>
Message-ID: <3Z4Vsj2k8NzSX1@mail.python.org>


Roundup Robot added the comment:

New changeset bbeff2958cc5 by R David Murray in branch '3.2':
#17064: fix sporadic permission errors in test_mailbox on windows.
http://hg.python.org/cpython/rev/bbeff2958cc5

New changeset 3e3915cbfde3 by R David Murray in branch '3.3':
Merge: #17064: fix sporadic permission errors in test_mailbox on windows.
http://hg.python.org/cpython/rev/3e3915cbfde3

New changeset aa15df77e58f by R David Murray in branch 'default':
Merge: #17064: fix sporadic permission errors in test_mailbox on windows.
http://hg.python.org/cpython/rev/aa15df77e58f

New changeset 1c2dbed859ca by R David Murray in branch '2.7':
#17064: fix sporadic permission errors in test_mailbox on windows.
http://hg.python.org/cpython/rev/1c2dbed859ca

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17064>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:15:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Feb 2013 15:15:46 +0000
Subject: [issue17064] Fix sporadic buildbot failures for test_mailbox
In-Reply-To: <1359393259.56.0.519558675211.issue17064@psf.upfronthosting.co.za>
Message-ID: <1360595746.16.0.859970552285.issue17064@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Jeremy.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 2.7, Python 3.2 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17064>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:19:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 15:19:25 +0000
Subject: [issue17181] SSLContext.set_servername_callback should be able to
	set	argument
In-Reply-To: <1360577259.03.0.413727229481.issue17181@psf.upfronthosting.co.za>
Message-ID: <1655752375.26768845.1360595958885.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> This would allow constructs like the following where self can be used
> within the callback. Example:
> 
>         def cb_sni(ssl_sock, server_name, self):
>             self.sniname = server_name
> 
>         self.context.set_servername_callback(cb_sni, self)
> 
> The original functionality can still occur with:
> 
>         self.context.set_servername_callback(cb_sni, self.context)

But you could simply use a closure:

        def cb_sni(ssl_sock, server_name):
            self.sniname = server_name

        self.context.set_servername_callback(cb_sni)

----------
title: SSLContext.set_servername_callback should be able to set argument -> SSLContext.set_servername_callback should be able to set	argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17181>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:21:25 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 11 Feb 2013 15:21:25 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360596085.55.0.48589869583.issue4591@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

+1 for PyIndex_AsLong()

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:28:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Feb 2013 15:28:35 +0000
Subject: [issue9874] Message.attach() loses empty attachments
In-Reply-To: <1284645198.43.0.725761534678.issue9874@psf.upfronthosting.co.za>
Message-ID: <1360596515.03.0.581405225822.issue9874@psf.upfronthosting.co.za>


R. David Murray added the comment:

Lacking a reproducer, there's not much we can do here, so closing.

----------
resolution:  -> works for me
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9874>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:36:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Feb 2013 15:36:04 +0000
Subject: [issue17171] email.encoders.encode7or8bit does not work with binary
	data
In-Reply-To: <1360433985.11.0.320523625616.issue17171@psf.upfronthosting.co.za>
Message-ID: <1360596964.52.0.972304319788.issue17171@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17171>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:37:52 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Feb 2013 15:37:52 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1360597072.19.0.085781505459.issue15767@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:40:40 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Feb 2013 15:40:40 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1360597240.54.0.959928685756.issue15767@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

For me, it mostly comes down to whether end-users are expected to see such errors generally or not.  We see ImportErrors all the time, and they are clearly errors.  If we're expected to see and deal with MNF, and if in such cases it's generally considered an error, then MNFError is better.  If it's mostly an internal/hidden thing, then MNF doesn't bother me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 11 16:53:45 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 11 Feb 2013 15:53:45 +0000
Subject: [issue16935] unittest should understand SkipTest at import time
	during test discovery
In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za>
Message-ID: <1360598025.31.0.530755207603.issue16935@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Sure can.  With a little luck, I'll have the patch ready later today; with less luck it'll be sometime later this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16935>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:11:08 2013
From: report at bugs.python.org (Guido Reina)
Date: Mon, 11 Feb 2013 16:11:08 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
Message-ID: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>


New submission from Guido Reina:

In the file: Lib/_markupbase.py, function: "_parse_doctype_element" there is:

if '>' in rawdata[j:]:
    return rawdata.find(">", j) + 1

rawdata[j:] is being scanned twice.

It would be better to do:
pos = rawdata.find(">", j)
if pos != -1:
    return pos + 1


Same thing in the function: "_parse_doctype_attlist":

if ")" in rawdata[j:]:
    j = rawdata.find(")", j) + 1
else:
    return -1

It would be better to do:
pos = rawdata.find(")", j)
if pos != -1:
    j = pos + 1
else:
    return -1

----------
messages: 181903
nosy: guido
priority: normal
severity: normal
status: open
title: Small enhancements to Lib/_markupbase.py
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:12:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Feb 2013 16:12:27 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1360599147.57.0.155354718681.issue17183@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
components: +Library (Lib)
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:18:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 16:18:46 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1360599526.95.0.775503931266.issue17183@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> if '>' in rawdata[j:]:
>     return rawdata.find(">", j) + 1

See issue17170 for this idiom.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:19:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Feb 2013 16:19:59 +0000
Subject: [issue17171] email.encoders.encode7or8bit does not work with binary
	data
In-Reply-To: <1360433985.11.0.320523625616.issue17171@psf.upfronthosting.co.za>
Message-ID: <3Z4XJt3G8jzNN8@mail.python.org>


Roundup Robot added the comment:

New changeset f83581135ec4 by R David Murray in branch '3.2':
#17171: fix email.encoders.encode_7or8bit when applied to binary data.
http://hg.python.org/cpython/rev/f83581135ec4

New changeset cabcddbed377 by R David Murray in branch '3.3':
Merge: #17171: fix email.encoders.encode_7or8bit when applied to binary data.
http://hg.python.org/cpython/rev/cabcddbed377

New changeset a80b67611c6d by R David Murray in branch 'default':
Merge: #17171: fix email.encoders.encode_7or8bit when applied to binary data.
http://hg.python.org/cpython/rev/a80b67611c6d

New changeset e44fa71d76fe by R David Murray in branch '2.7':
#17171: backport behavior-confirming test from python3.
http://hg.python.org/cpython/rev/e44fa71d76fe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17171>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:21:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Feb 2013 16:21:57 +0000
Subject: [issue17171] email.encoders.encode7or8bit does not work with binary
	data
In-Reply-To: <1360433985.11.0.320523625616.issue17171@psf.upfronthosting.co.za>
Message-ID: <1360599717.01.0.0933139455209.issue17171@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since this was straightforwardly similar to the issue 16564 fix I didn't bother with a review.  The 2.7 commit is backporting the behavior-confirming test, just for thoroughness.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17171>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:24:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 16:24:47 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360599887.78.0.410385754387.issue4591@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> (perhaps we need as PyNumber_AsLongIndex() to do the direct conversion
to a C long, it would make things easier in many cases)

In this case we need PyNumber_AsLongAndOverflowIndex() and PyNumber_AsUnsignedLongIndex(). And a lot of other parallel functions for other cases. This can exponentially increase a number of functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:33:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 16:33:40 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360600420.01.0.497773923753.issue4591@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Not technically the topic of this issue, but should we just lock
> down _Py_Uid_Converter() to ints?

I just copied this code from PyArg_ParseTuple*() for 'l' format.

> This is still accepted:
>
> os.setuid(Decimal("1000.2"))

Any C implemented function which parses an integer argument with PyArg_ParseTuple*() accepts decimals.

>>> chr(65.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: integer argument expected, got float
>>> chr(Decimal('65.2'))
'A'

I think this is an offtopic for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:54:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 11 Feb 2013 16:54:08 +0000
Subject: [issue16935] unittest should understand SkipTest at import time
	during test discovery
In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za>
Message-ID: <1360601648.04.0.325716342873.issue16935@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I think this patch should cover the test and Doc changes necessary.  Of course, let me know if it doesn't :)

----------
Added file: http://bugs.python.org/file29039/issue16935.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16935>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:58:12 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 11 Feb 2013 16:58:12 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1360600420.01.0.497773923753.issue4591@psf.upfronthosting.co.za>
Message-ID: <20130211165813.GA2629@sleipnir.bytereef.org>


Stefan Krah added the comment:

Serhiy Storchaka <report at bugs.python.org> wrote:
> > Not technically the topic of this issue, but should we just lock
> > down _Py_Uid_Converter() to ints?
> 
> I just copied this code from PyArg_ParseTuple*() for 'l' format.

> > os.setuid(Decimal("1000.2"))

I know that this behavior wasn't introduced by you. It's perfectly fine
to use PyArg_ParseTuple() for guidance or to try to preserve the existing
behavior.

> >>> chr(Decimal('65.2'))
> 'A'

I just happen to think that PyArg_ParseTuple() is wrong here and we shouldn't
enable this "feature" in new code. Fixing these issues one by one is probably
the best way forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 17:59:06 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Feb 2013 16:59:06 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360520060.7.0.216409877413.issue17130@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+QXCFfDhEf4AuOQVHq-mP8SbrMfQuP=3=Aai2qEGPDxQ@mail.gmail.com>


Guido van Rossum added the comment:

Antoine, what about the decorator? I've come across a few use cases.

--Guido van Rossum (sent from Android phone)
On Feb 10, 2013 10:14 AM, "Antoine Pitrou" <report at bugs.python.org> wrote:

>
> Antoine Pitrou added the comment:
>
> +1 for runcall() and the context manager.
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17130>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:11:52 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 11 Feb 2013 17:11:52 +0000
Subject: [issue17052] unittest discovery should use self.testLoader
In-Reply-To: <1359281511.22.0.555240068262.issue17052@psf.upfronthosting.co.za>
Message-ID: <1360602712.33.0.620955677124.issue17052@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks a lot for taking care of this issue, Michael.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17052>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:29:00 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Feb 2013 17:29:00 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360603740.51.0.226094237408.issue17130@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

See issue 9285 in which I wrote a decorator for profile/cProfile.
That can be modified to work both as a decorator or a context manager by using contextlib.contextmanager.
Shall I continue in issue 9285 and rewrite that patch?

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:31:00 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Feb 2013 17:31:00 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1360603860.74.0.637338870761.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Right, so what's typical? =) I mean do most people see ImportError for optional modules (e.g. not on support platforms), or do most people see ImportError because they messed up and tried to import something that they expected but actually isn't there for some reason.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:37:59 2013
From: report at bugs.python.org (Franck Michea)
Date: Mon, 11 Feb 2013 17:37:59 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1360604279.14.0.963012671651.issue12077@psf.upfronthosting.co.za>


Franck Michea added the comment:

Here is at least a correction of Descriptors' HowTo. There are two versions since some stuff differs (object inheritance, ...).

Here are some of my interrogations though:
 - RevealAccess is not using instance parameter, so value is shared. Is this intended?
 - Don't really know what to do with "Function and Methods" part. First I don't really understand the relevance of this in a descriptor how-to. Also it is know outdated in python3 version (unbound thing, ...), so what do?
 - In __getattribute__ function, I don't really understand the paramters given to __get__, why None and the instance? But this is probably my fault.

This also doesn't answer the question about the real source that should be kept. What to do?

I also need a proof-read, since english is not my first language... Anyway it's clearly not enough to be published like that

Have a nice day!

----------
keywords: +patch
nosy: +kushou
versions: +Python 3.5
Added file: http://bugs.python.org/file29040/12077_descriptor_howto_python3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:38:18 2013
From: report at bugs.python.org (Franck Michea)
Date: Mon, 11 Feb 2013 17:38:18 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1360604298.15.0.521205559743.issue12077@psf.upfronthosting.co.za>


Changes by Franck Michea <franck.michea at gmail.com>:


Added file: http://bugs.python.org/file29041/12077_descriptor_howto_python2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:49:19 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Feb 2013 17:49:19 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360604959.71.0.950475949001.issue17130@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sure, I will comment on that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:54:11 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Feb 2013 17:54:11 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1360605251.69.0.923230354828.issue9285@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Brief comments:

- Please don't call it profile -- we already have a module by that name.

- Please make it so that both the decorator and context manager can specify a file where to dump the raw data -- basically it needs to have the same functionality as the functions run()/runctx()/runcall() (the latter TBD, see issue 17130).

- Please also make Profile object itself the context manager -- all you have to do is add __enter__() and __exit__() that call enable() and disable().  (But this doesn't completely replace the global function, which has more functionality -- it prints the profile or dumps the data).

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Mon Feb 11 18:55:25 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Feb 2013 17:55:25 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1360605325.29.0.0397421253557.issue9285@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Ok, will look into this soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Mon Feb 11 19:33:40 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Feb 2013 18:33:40 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1360603860.74.0.637338870761.issue15767@psf.upfronthosting.co.za>
Message-ID: <20130211133345.04388432@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On Feb 11, 2013, at 05:31 PM, Brett Cannon wrote:

>Right, so what's typical? =) I mean do most people see ImportError for
>optional modules (e.g. not on support platforms), or do most people see
>ImportError because they messed up and tried to import something that they
>expected but actually isn't there for some reason.

There are a few common use cases (or perhaps anti-use cases) where you see
ImportErrors.  I might be missing some, but I'd put these in roughly
descending order of commonness.

* Trying alternative imports for compatibility reasons.  You always expect
  ImportErrors in these cases, and you'll always catch them in try/excepts.

* Missing modules, submodules, or attributes in from-imports.  These can be
  unexpected if you think you've got the right version of a package, or
  expected for compatibility reasons.

* Trying to conditionally import optional modules.  Again, expected, and
  they'll be wrapped in try/except.

I guess the case you're trying to differentiate with MNF is, the from-import
case, i.e. did the error occur because the module was missing or because the
attribute was missing?

It's hard to say which is more likely, which I guess is why you're having a
hard time deciding. :) If I had to vote, I'd go with MNFError 1) because it's
a subclass of ImportError; 2) it'll be more informative in the case where it
really *is* an error; 3) isn't that big of a deal in cases where it's
expected; 4) we're used to seeing ImportError anyway, and probably most code
won't care and will just use ImportError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 11 19:37:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 18:37:40 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360607860.93.0.107772246563.issue4591@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> There is a problem with test_pwd on 64-bit platform.

Fixed in changesets a0983e46feb1 and 1e9fa629756c: Raise KeyError instead of OverflowError when getpwuid's argument is out of uid_t range.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:09:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 19:09:43 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <CAP7+vJ+QXCFfDhEf4AuOQVHq-mP8SbrMfQuP=3=Aai2qEGPDxQ@mail.gmail.com>
Message-ID: <1360609594.3569.1.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Antoine, what about the decorator? I've come across a few use cases.

I don't know, I'm thinking that "there should be one obvious way to do
it" :-)
By that I mean that the context manager is more generic than the
decorator. Or do you want to decorate functions from an external
library?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:11:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 19:11:39 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360609899.53.0.996855126834.issue4591@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> In this case we need PyNumber_AsLongAndOverflowIndex() and
> PyNumber_AsUnsignedLongIndex(). And a lot of other parallel functions
> for other cases. This can exponentially increase a number of functions.

I don't think it will be exponential :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:16:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 19:16:11 +0000
Subject: [issue17181] SSLContext.set_servername_callback should be able to
	set	argument
In-Reply-To: <1360577259.03.0.413727229481.issue17181@psf.upfronthosting.co.za>
Message-ID: <1360610171.3.0.406483194456.issue17181@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(functools.partial is another solution to the problem)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17181>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:17:00 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Feb 2013 19:17:00 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360609594.3569.1.camel@localhost.localdomain>
Message-ID: <CAP7+vJ+=quZ6HjgccxPjzjy64gFf4dxSCs-31wkUV1tspSdKbg@mail.gmail.com>


Guido van Rossum added the comment:

If I quickly want to profile one function, with the decorator I have to
insert a with-statement in its body and mess with the indentation of the
entire body. With a decorator it's just a one-line insertion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:17:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2013 19:17:41 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360610261.14.0.131629093006.issue17130@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, fair enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:18:32 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Feb 2013 19:18:32 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1360610312.99.0.899337105374.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Screw it, I'll go with ModuleNotFoundError since it is a subclass of ImportError and so it might come off as weird as saying the superclass is an "Error" but the subclass is not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:39:08 2013
From: report at bugs.python.org (Roy Smith)
Date: Mon, 11 Feb 2013 19:39:08 +0000
Subject: [issue17184] re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
Message-ID: <1360611548.83.0.365452859403.issue17184@psf.upfronthosting.co.za>


New submission from Roy Smith:

# Python 2.7.3
# Ubuntu 12.04

import re
pattern = r"( ?P<phrase>.*)"
regex = re.compile(pattern, re.VERBOSE)

The above raises an exception in re.compile():

Traceback (most recent call last):
  File "./try.py", line 6, in <module>
    regex = re.compile(pattern, re.VERBOSE)
  File "/home/roy/env/python/lib/python2.7/re.py", line 190, in compile
    return _compile(pattern, flags)
  File "/home/roy/env/python/lib/python2.7/re.py", line 242, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

The problem appears to be that re.VERBOSE isn't ignoring the space after the "(".

Maybe this is a duplicate of issue15606 ?

----------
components: Library (Lib)
messages: 181927
nosy: roysmith
priority: normal
severity: normal
status: open
title: re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17184>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:42:49 2013
From: report at bugs.python.org (Roy Smith)
Date: Mon, 11 Feb 2013 19:42:49 +0000
Subject: [issue15606] re.VERBOSE whitespace behavior not completely documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1360611769.26.0.568007234031.issue15606@psf.upfronthosting.co.za>


Changes by Roy Smith <roy at panix.com>:


----------
nosy: +roysmith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15606>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:43:51 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 11 Feb 2013 19:43:51 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360611831.06.0.152183970094.issue17170@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:52:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Feb 2013 19:52:35 +0000
Subject: [issue17184] re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
In-Reply-To: <1360611548.83.0.365452859403.issue17184@psf.upfronthosting.co.za>
Message-ID: <1360612355.96.0.165618521427.issue17184@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17184>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:53:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 19:53:17 +0000
Subject: [issue15606] re.VERBOSE whitespace behavior not completely documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1360612397.14.0.901652742525.issue15606@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also related issue11204.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15606>
_______________________________________

From report at bugs.python.org  Mon Feb 11 20:57:16 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Feb 2013 19:57:16 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360612636.72.0.397387964438.issue17130@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

As for runcall() we haven't the ability to freely support kwargs *and* filename.
I see two possibilities.
Kill kwargs, as such:

+def runcall(func, *args, filename=None, sort=-1):
+    """Run func(*args) under profiler, optionally saving results in
+    filename.
+    """

...or make 'filename_' and 'sort_' two special name kwargs to be used as in:

>>> runcall(fun, foo=1, bar=2, filename_='...')

Also, there might be some value in adding 'strip_dirs' argument to those functions (run/runctx/runcall).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 11 21:02:21 2013
From: report at bugs.python.org (Roy Smith)
Date: Mon, 11 Feb 2013 20:02:21 +0000
Subject: [issue11204] re module: strange behaviour of space inside {m, n}
In-Reply-To: <1297552798.48.0.889043344562.issue11204@psf.upfronthosting.co.za>
Message-ID: <1360612941.82.0.315878151445.issue11204@psf.upfronthosting.co.za>


Changes by Roy Smith <roy at panix.com>:


----------
nosy: +roysmith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11204>
_______________________________________

From report at bugs.python.org  Mon Feb 11 21:04:57 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 11 Feb 2013 20:04:57 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360613097.87.0.687106328187.issue16997@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

>> what if there are 500 subtests in a loop and you don't want 500 failures to be
>> registered for that test case?
>
> Parametered tests have the same issue. In this case you simply don't use subtests
> or test cases.

Right, but then you lose out on both of the benefits documented for subtests:

+Without using a subtest, execution would stop after the first failure,
+and the error would be less easy to diagnose because the value of ``i``
+wouldn't be displayed::

Why tie these together?  I'm suggesting that we expose a way to benefit from the "easy to diagnose" portion without the "suspend stoppage" portion.  (The way we do this doesn't have to be one of the ways I'm suggesting, though I've suggested a few.)

>> addMessage was just one suggestion.
>
> It is quite orthogonal, actually, and could be added independently. Also, it is not clear how you would limit the addMessage to a subtest, rather than the whole test case.

It's not orthogonal because the way I suggested it, subTest() would be the composition of addMessage() and continueTest() context managers.  (addMessage limits itself by being a context manager just like subTest.)  So if we added addMessage() later, we would want to refactor subTest() to be using it.  The equivalence would be something like the following:

    with self.subTest(msg=msg, i=i):
        self.assertEqual(i % 2, 0)

    with self.continueTest():
        with self.addMessage(msg, i=i):
            self.assertEqual(i % 2, 0)

However, since it looks like we're going with changing the test case ID instead of putting the extra data only in the exception message (TestCase.longMessage) like I was suggesting before, I think adding a failFast=True or maxFailures=n parameter to subTest() has higher importance, e.g.

    with self.subTest(msg=msg, maxFailures=1, i=i):
        self.assertEqual(i % 2, 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 21:10:48 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 11 Feb 2013 20:10:48 +0000
Subject: [issue17184] re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
In-Reply-To: <1360611548.83.0.365452859403.issue17184@psf.upfronthosting.co.za>
Message-ID: <1360613448.68.0.0866153513887.issue17184@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

It does look like a duplicate to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17184>
_______________________________________

From report at bugs.python.org  Mon Feb 11 21:34:17 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Feb 2013 20:34:17 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360614857.81.0.711035428404.issue16997@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/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 21:40:19 2013
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Mon, 11 Feb 2013 20:40:19 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360615219.86.0.125639255175.issue16997@psf.upfronthosting.co.za>


Changes by Yaroslav Halchenko <yarikoptic at gmail.com>:


----------
nosy:  -Yaroslav.Halchenko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 11 22:04:28 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Feb 2013 21:04:28 +0000
Subject: [issue15351] Add to unittest.TestCase support for using context
	managers
In-Reply-To: <1342280032.27.0.345733068822.issue15351@psf.upfronthosting.co.za>
Message-ID: <1360616668.92.0.704276833093.issue15351@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15351>
_______________________________________

From report at bugs.python.org  Mon Feb 11 22:07:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 21:07:19 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1360616839.71.0.0832205618662.issue13555@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file29020/pickle_overflow-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Feb 11 22:09:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 21:09:50 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1360616990.65.0.0573265379019.issue13555@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Test updated too. Now it doesn't try to write a string larger than 2 GiB (it's impossible), instead writes a lot of shorter strings with total size larger than 2 GiB.

----------
Added file: http://bugs.python.org/file29042/pickle_overflow-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Feb 11 22:15:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Feb 2013 21:15:50 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360617350.18.0.667022438337.issue17170@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A related issue: the speed of finding and hence replacing chars in strings is known to have regressed in 3.3 relative to 3.2, especially on Windows. For long strings, that will negate in 3.3 the speedup for the initial method call. See #16061, with patches. The holdup seems to be deciding which of two good patches to apply.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Mon Feb 11 23:31:40 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Feb 2013 22:31:40 +0000
Subject: [issue17185] create_autospec
Message-ID: <1360621900.03.0.519438692167.issue17185@psf.upfronthosting.co.za>


New submission from Chris Withers:

Sticking an issue in at Michael's request...

Older versions of mock had a helper called mocksignature.
In newer versions, create_autospec replaces this, but doesn't get it right sometimes:

>>> from inspect import getargspec
>>> from mock import create_autospec
>>> def myfunc(x, y): pass
...
>>> getargspec(myfunc)
ArgSpec(args=['x', 'y'], varargs=None, keywords=None, defaults=None)
>>> getargspec(create_autospec(myfunc))
ArgSpec(args=[], varargs='args', keywords='kwargs', defaults=None)

mocksignature gets it right:

>>> from mock import mocksignature
>>> getargspec(mocksignature(myfunc))
ArgSpec(args=['x', 'y'], varargs=None, keywords=None, defaults=None)

----------
assignee: michael.foord
messages: 181934
nosy: cjw296, michael.foord
priority: normal
severity: normal
status: open
title: create_autospec

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17185>
_______________________________________

From report at bugs.python.org  Mon Feb 11 23:35:30 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 11 Feb 2013 22:35:30 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
Message-ID: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>


New submission from Chris Withers:

Python 2 had a private but usable way of introspecting and manipulating registered atexit handlers by way of the atexit._exithandlers.

In Python 3, registering and unregistering are handled, but there is no longer a way to see what atexit handlers are registered.

Barry suggested filing a bug to have this added as a new feature for Python 3.4. Some kind of read-only sequence would be fine, if the original list can no longer be exposed.

----------
messages: 181935
nosy: cjw296
priority: normal
severity: normal
status: open
title: no way to introspect registered atexit handlers
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Tue Feb 12 00:54:44 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 11 Feb 2013 23:54:44 +0000
Subject: [issue17187] Python segfaults from improperly formed and called
	function
Message-ID: <1360626883.99.0.640748040618.issue17187@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Python 3.3 added a nice new feature: if you don't supply enough positional parameters to a function, it tells you the names of the positional parameters you omitted.

Unfortunately, the code that prints this error message assumes that the function is well-formed.  If I manually create a function using types.CodeType and types.FunctionType, and I don't provide enough entries in the types.CodeType  "varnames" parameter to satisfy all the positional parameters, and I call the resulting function with insufficient parameters, Python crashes.

I've attached a sample script that demonstrates this crash.  I can reproduce it with both 3.3.0 and a recent trunk.  Since this feature wasn't in 3.2 or before, the bug doesn't seem to exist in those versions; I couldn't reproduce with 3.2 or 2.7.

The crash occurs in missing_arguments() in Python/ceval.c, line 3256 in trunk.  The function calls PyTuple_GET_ITEM on the co_varnames tuple without checking that it has sufficient entries.  It gets a crazytown pointer, calls PyObject_Repr on it, and boom.

I've attached a band-aid patch which prevents the crash, but this is almost certainly not the fix we want.  Perhaps types.CodeType should refuse to generate the malformed code object in the first place?

----------
components: Interpreter Core
files: crashy.py
keywords: 3.3regression
messages: 181936
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Python segfaults from improperly formed and called function
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29043/crashy.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17187>
_______________________________________

From report at bugs.python.org  Tue Feb 12 00:55:15 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 11 Feb 2013 23:55:15 +0000
Subject: [issue17187] Python segfaults from improperly formed and called
	function
In-Reply-To: <1360626883.99.0.640748040618.issue17187@psf.upfronthosting.co.za>
Message-ID: <1360626915.8.0.270157508076.issue17187@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29044/lch.bandaid.for.malformed.fn.crash.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17187>
_______________________________________

From report at bugs.python.org  Tue Feb 12 01:07:09 2013
From: report at bugs.python.org (Greg Couch)
Date: Tue, 12 Feb 2013 00:07:09 +0000
Subject: [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1360627629.48.0.628654026974.issue16851@psf.upfronthosting.co.za>


Greg Couch added the comment:

In my opinion, the Python 2.7 results are wrong.

In Python 2.7, inspect.ismethod returns True for both bound and unbound methods -- ie., is broken according to the documentation.  As a workaround, I'm using:

def is_bound_method(obj):
    return hasattr(obj, '__self__') and obj.__self__ is not None

is_bound_method also works for methods of classes implemented in C, e.g., int:

>>> a = 1
>>> is_bound_method(a.__add__)
True
>>> is_bound_method(int.__add__)
False

But is not very useful in that case because inspect.getargspec does not work for functions implemented in C.

is_bound_method works unchanged in Python 3, but as noted above, in Python 3, inspect.ismethod properly distinguishes between bound and unbound methods, so it is not necessary.

----------
nosy: +gregcouch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16851>
_______________________________________

From report at bugs.python.org  Tue Feb 12 02:08:05 2013
From: report at bugs.python.org (Andrew Bennetts)
Date: Tue, 12 Feb 2013 01:08:05 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1360631285.3.0.079340620647.issue16997@psf.upfronthosting.co.za>


Andrew Bennetts added the comment:

googletest (an xUnit style C++ test framework) has an interesting feature: in addition to assertions like ASSERT_EQ(x, y) that stop the test, it has EXPECT_EQ(x, y) etc that will cause the test to fail without causing it to stop.  I think this decoupling of ?test failed? and ?test execution stopped? is very useful.  (Note this also implies a single test can have multiple failures, or if you prefer that a single test can have multiple messages attached to explain why its state is 'FAILED'.)

I wouldn't like to see a duplication of all assert* methods as expect* methods, but there are alternatives.  A single self.expectThat method that takes a value and a matcher, for instance.

Or you could have a context manager:

with self.continueOnFailure():
    self.assertEqual(x, y)

In fact, I suppose that's more-or-less what the subtests patch offers?  Except the subtests feature seems to want to get involved in knowing about parameters and the like too, which feels weird to me.

Basically, I really don't like the ?subtests? name, but if instead it's named something that directly says its only effect is that failures don't abort the test, then I'd be happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Tue Feb 12 02:20:00 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Feb 2013 01:20:00 +0000
Subject: [issue17188] Document 'from None' in raise statement doc.
Message-ID: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Language manual, section 7.8. The raise statement has no mention of the 'from None' option. Indeed it says "if given, the second expression must be another exception class or instance", which would exclude None.

Library manual, Ch 5. Built-in Exceptions, says
'''
When raising a new exception (rather than using a bare raise to re-raise the exception currently being handled), the implicit exception context can be supplemented with an explicit cause by using from with raise:

raise new_exc from original_exc

The expression following from must be an exception or None. It will be set as __cause__ on the raised exception. Setting __cause__ also implicitly sets the __suppress_context__ attribute to True, so that using raise new_exc from None effectively replaces the old exception with the new one for display purposes (e.g. converting KeyError to AttributeError, while leaving the old exception available in __context__ for introspection when debugging.
'''
I am not sure how much should be copied over, but None should be at least mentioned and perhaps there should be a cross-reference.

I am also not sure how much applies to 3.2, but there is no version-added or -changed note with the above.

----------
assignee: docs at python
components: Documentation
messages: 181939
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document 'from None' in raise statement doc.
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17188>
_______________________________________

From report at bugs.python.org  Tue Feb 12 02:21:43 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Feb 2013 01:21:43 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1360632103.37.0.23394436296.issue17159@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I opened separate issue #17188:
Document 'from None' in raise statement doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Tue Feb 12 06:29:24 2013
From: report at bugs.python.org (William Mallard)
Date: Tue, 12 Feb 2013 05:29:24 +0000
Subject: [issue17189] Add zip64 support to shutil
Message-ID: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>


New submission from William Mallard:

This patch enables creation of 64-bit zip files via make_archive().

make_archive uses ZipFile to create zip files. ZipFile already supports creation of 64-bit archives via a kwarg, but make_archive hard-codes it to 32-bit. This patch exposes the option in a backwards compatible way.

----------
components: Library (Lib)
files: shutil_zip64.patch
keywords: patch
messages: 181941
nosy: william.mallard
priority: normal
severity: normal
status: open
title: Add zip64 support to shutil
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file29045/shutil_zip64.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Tue Feb 12 07:02:08 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 12 Feb 2013 06:02:08 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1360648928.18.0.971934656278.issue1518@psf.upfronthosting.co.za>


Larry Hastings added the comment:

It sort of looks like this was closed because we assumed we were moving to Unladen Swallow.  We're not.  Should this be reopened?

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Tue Feb 12 07:11:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Feb 2013 06:11:38 +0000
Subject: [issue17111] test_surrogates of test_fileio fails sometimes on OS X
	10.4
In-Reply-To: <1359881195.85.0.467111019736.issue17111@psf.upfronthosting.co.za>
Message-ID: <3Z4tmT3YBNzPsY@mail.python.org>


Roundup Robot added the comment:

New changeset 9497adb7355f by Ned Deily in branch '2.7':
Issue #17111: Prevent test_surrogates (test_fileio) failure on OS X 10.4.
http://hg.python.org/cpython/rev/9497adb7355f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17111>
_______________________________________

From report at bugs.python.org  Tue Feb 12 07:12:53 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Feb 2013 06:12:53 +0000
Subject: [issue17111] test_surrogates of test_fileio fails sometimes on OS X
	10.4
In-Reply-To: <1359881195.85.0.467111019736.issue17111@psf.upfronthosting.co.za>
Message-ID: <1360649573.84.0.315961126852.issue17111@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17111>
_______________________________________

From report at bugs.python.org  Tue Feb 12 07:14:34 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 12 Feb 2013 06:14:34 +0000
Subject: [issue17190] _FAST opcodes do no range checking
Message-ID: <1360649674.7.0.74265466328.issue17190@psf.upfronthosting.co.za>


New submission from Larry Hastings:

The implementations for LOAD_FAST, STORE_FAST, and DELETE_FAST don't check that the index is <= the size of fastlocals.  So it's a snap to crash the interpreter with hand-written bytecode, by going past the end of the fastlocals array.  Kaboom!

Attached is a program that demonstrates a crash with each of LOAD_FAST, STORE_FAST, and DELETE_FAST.  These all crashed 2.7, 3.2, 3.3, and a recent trunk.  (Well, two exceptions: LOAD_FAST and DELETE_FAST didn't crash 3.2.  Given the behavior, my suspicion is not that 3.2 is hardened, just that there's something dopey with my thrown-together test.)

It could be that this is not an interesting bug, that policy suggests that anyone who can write their own bytecode is a Consenting Adult.  You tell me.

----------
components: Interpreter Core
files: crashy2.py
messages: 181944
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: _FAST opcodes do no range checking
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29046/crashy2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17190>
_______________________________________

From report at bugs.python.org  Tue Feb 12 08:12:27 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Feb 2013 07:12:27 +0000
Subject: [issue17190] _FAST opcodes do no range checking
In-Reply-To: <1360649674.7.0.74265466328.issue17190@psf.upfronthosting.co.za>
Message-ID: <1360653147.43.0.325128752653.issue17190@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> It could be that this is not an interesting bug,
> that policy suggests that anyone who can write their 
> own bytecode is a Consenting Adult.

Yes, that is correct on all counts.

Sorry, this is an *ancient* discussion, long ago put to bed.

Besides, did you really want to kill the performance of our fastest opcodes in everyone's code just to save a bytecode hacker from shooting him/herself in the foot?

----------
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17190>
_______________________________________

From report at bugs.python.org  Tue Feb 12 08:21:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Feb 2013 07:21:38 +0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1360653698.72.0.379350002985.issue1518@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

See issue 10401.
Quoting myself: ?Here is the Nth patch for a globals/builtins cache. As other caches at the same kind, it shows very small to no gain on non-micro benchmarks, showing that contrary to popular belief, globals/builtins lookup are not a major roadblock in today's Python performance.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
_______________________________________

From report at bugs.python.org  Tue Feb 12 08:36:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Feb 2013 07:36:40 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <3Z4wfb5QpwzPkW@mail.python.org>


Roundup Robot added the comment:

New changeset 3893ab574c55 by Serhiy Storchaka in branch '3.2':
Issue #4591: Uid and gid values larger than 2**31 are supported now.
http://hg.python.org/cpython/rev/3893ab574c55

New changeset 035cbc654889 by Serhiy Storchaka in branch '2.7':
Issue #4591: Uid and gid values larger than 2**31 are supported now.
http://hg.python.org/cpython/rev/035cbc654889

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Tue Feb 12 09:23:37 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 12 Feb 2013 08:23:37 +0000
Subject: [issue17190] _FAST opcodes do no range checking
In-Reply-To: <1360649674.7.0.74265466328.issue17190@psf.upfronthosting.co.za>
Message-ID: <1360657417.2.0.808181587811.issue17190@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I'm not surprised it was discussed to death long ago.  And I can get behind wontfix.  But let me just say that

a) I think an uncrashable Python interpreter is a laudable goal, and steps we can take towards that should not be dismissed out of hand.

b) I doubt a range check would "kill" the performance of the _FAST operands.  It'd be one lookup/compare/branch each, and the branch predictor would always guess correctly.  But I admit I have not tested it.

c) Anyway we needn't do it at runtime.  We could just as easily scan over the opcodes in the code object constructor and do the range checking there.  If we only did the check when the constructor was called directly from Python, it should have no measurable performance impact, only a maintenance cost.

d) I expect all these points were brought up in the original discussion.  I'd like to read that--but I can't find it.  Any pointers would be appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17190>
_______________________________________

From report at bugs.python.org  Tue Feb 12 09:25:53 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Feb 2013 08:25:53 +0000
Subject: [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1360657553.57.0.558195123662.issue12077@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12077>
_______________________________________

From report at bugs.python.org  Tue Feb 12 10:00:05 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 12 Feb 2013 09:00:05 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360659605.68.0.136482449369.issue17136@psf.upfronthosting.co.za>


Dirkjan Ochtman added the comment:

libffi-3.0.12 has been released with that fix. Perhaps that should be included in future Python releases?

----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17136>
_______________________________________

From report at bugs.python.org  Tue Feb 12 10:57:08 2013
From: report at bugs.python.org (Torsten Bronger)
Date: Tue, 12 Feb 2013 09:57:08 +0000
Subject: [issue9400] multiprocessing.pool.AsyncResult.get() messes up
	exceptions
In-Reply-To: <1280333027.17.0.112361474517.issue9400@psf.upfronthosting.co.za>
Message-ID: <1360663028.75.0.0616108026451.issue9400@psf.upfronthosting.co.za>


Changes by Torsten Bronger <bronger at physik.rwth-aachen.de>:


----------
nosy: +bronger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9400>
_______________________________________

From report at bugs.python.org  Tue Feb 12 11:42:11 2013
From: report at bugs.python.org (Mauro Cicognini)
Date: Tue, 12 Feb 2013 10:42:11 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1360665731.59.0.969392558743.issue917120@psf.upfronthosting.co.za>


Mauro Cicognini added the comment:

The removal of the dead code causes imaplib under py3k to lose the quoting functionality that is described in documentation (except for passwords, that do get always quoted as stated).

I submit that we give at least a temporary warning in the docs, and that the _quote() function is exposed to let the programmer do their own quoting when they feel it necessary.

----------
nosy: +Mauro.Cicognini
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue917120>
_______________________________________

From report at bugs.python.org  Tue Feb 12 11:47:37 2013
From: report at bugs.python.org (Abram Clark)
Date: Tue, 12 Feb 2013 10:47:37 +0000
Subject: [issue17191] pdb list shows unexpected code when stack frame includes
	a try / finally block
Message-ID: <1360666057.12.0.723928905172.issue17191@psf.upfronthosting.co.za>


New submission from Abram Clark:

The list command in pdb shows an unexpected portion of code after an up command enters a try / finally block in the call stack.

To reproduce:

pdb pdb_list_bug_reproduce.py
c
up
list

Expected behavior: Show 11 lines around line 8, "throw_something()", which was the entry point to the lower stack frame.

Actual behavior: Shows code centered around line 10, in the finally block, which is likely cleanup code that has nothing to do with the exception thrown.

----------
files: pdb_list_bug_reproduce.py
messages: 181951
nosy: Abram.Clark
priority: normal
severity: normal
status: open
title: pdb list shows unexpected code when stack frame includes a try / finally block
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29047/pdb_list_bug_reproduce.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17191>
_______________________________________

From report at bugs.python.org  Tue Feb 12 12:01:21 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Feb 2013 11:01:21 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360666881.8.0.701759044328.issue17170@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I left some comments on Rietveld.

I wonder if PyArg_ParseTupleAndKeywords can be replaced by something that would compute and cache the set of keywords; a bit like _Py_IDENTIFIER.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Tue Feb 12 13:47:33 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Feb 2013 12:47:33 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1360673253.48.0.860417923934.issue9285@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Tue Feb 12 13:47:48 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Feb 2013 12:47:48 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1360673268.12.0.713859324583.issue17130@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Tue Feb 12 13:55:49 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 12 Feb 2013 12:55:49 +0000
Subject: [issue17187] Python segfaults from improperly formed and called
	function
In-Reply-To: <1360626883.99.0.640748040618.issue17187@psf.upfronthosting.co.za>
Message-ID: <1360673749.69.0.0602736850482.issue17187@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

> Perhaps types.CodeType should refuse to generate the malformed code object in the first place?
Yup.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17187>
_______________________________________

From report at bugs.python.org  Tue Feb 12 14:16:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Feb 2013 13:16:11 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360674971.5.0.169898616544.issue17189@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Tue Feb 12 14:32:43 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 12 Feb 2013 13:32:43 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360675963.32.0.887573344949.issue17172@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Attached is a patch. I hope the File menu is the right place for this. I had to move the code in Lib/turtledemo.py after "if __name__ ==..." into main().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Tue Feb 12 14:33:09 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 12 Feb 2013 13:33:09 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360675989.34.0.789389847088.issue17172@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29048/issue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Tue Feb 12 14:34:45 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 12 Feb 2013 13:34:45 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360676085.42.0.875599070302.issue17172@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Should this be added to Lib/idlelib/NEWS.txt ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Tue Feb 12 14:52:52 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 12 Feb 2013 13:52:52 +0000
Subject: [issue17192] libffi-3.0.12 import
Message-ID: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>


New submission from Matthias Klose:

issue for tracking the libffi-3.0.12 import. checked that builds on x86_64-linux-gnu and arm-linux-gnueabihf do work.

still needs updating/checking the extra copies of:

 - libffi_arm_wince
 - libffi_msvc
 - libffi_osx

----------
components: Extension Modules
messages: 181956
nosy: doko
priority: normal
severity: normal
status: open
title: libffi-3.0.12 import
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 12 15:00:16 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Feb 2013 14:00:16 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1360677616.15.0.531010403028.issue917120@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't understand what you mean by removing dead code leading to loss of functionality, unless you mean that the removal of the call to the quoting code in Python3 led to a loss of functionality relative to Python2, in which case I agree.  It also led to the behavior being out of sync with the documentation.

Reviewing the history of the changes (see issue 1210), it appears to me that the removal of the call to _checkquote was in fact unintentional and is a bug (it existed in the port-to-python3 patch submitted by Victor, but was commented out, which probably means he had it commented out for testing and did not notice he had not restored it).  This makes the later removal of _checkquote incorrect as well.

This error is primarily a consequence of imaplib having very few tests.

This module needs a lot of love in Python3 from someone, and it is not an easy topic to wrap ones head around.  It's on my list of things to look at, but there are a bunch of things ahead of it.

For the immediate issue, it is working as documented in Python2.7, so there is nothing to do there.  For Python3 we haven't had the quoting since the start, so we have the opportunity to consider changing the quoting rules if we wish...and we may have have no choice, since the new behavior has been in released versions for several Python3 versions now and starting to quote like Python2.7 did might break otherwise working code.  I don't have an opinion on how to fix this this yet, since while I know more about the IMAP protocol than I did a year ago, I still don't know enough to even write the tests....

----------
components: +email
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue917120>
_______________________________________

From report at bugs.python.org  Tue Feb 12 15:33:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Feb 2013 14:33:33 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <3Z55vc3gb4zPyc@mail.python.org>


Roundup Robot added the comment:

New changeset 7727be7613f9 by doko in branch 'default':
- Issue #17192: Import libffi-3.0.12.
http://hg.python.org/cpython/rev/7727be7613f9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 12 15:34:39 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 12 Feb 2013 14:34:39 +0000
Subject: [issue17136] ctypes tests fail with clang on non-OS X
In-Reply-To: <1360081451.14.0.916980822692.issue17136@psf.upfronthosting.co.za>
Message-ID: <1360679679.09.0.671593525508.issue17136@psf.upfronthosting.co.za>


Matthias Klose added the comment:

libffi-3.0.12 is now imported, tracked in issue #17192.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17136>
_______________________________________

From report at bugs.python.org  Tue Feb 12 15:35:20 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 12 Feb 2013 14:35:20 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1360679720.44.0.703870985613.issue17192@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 12 15:43:30 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 Feb 2013 14:43:30 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1360680210.05.0.0096655718327.issue17192@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

libffi_osx is not a copy of the regular libffi, but a (fairly old) fork. I don't know how far the two "branches" have diverged.  

An important feature  of liffi_osx is that is compiles cleanly when all intel and ppc related sources are compiled with '-arch ppc -arch i386 -arch x86_64' (that is, the relevant sources contain preprocessor guards to ensure the code in those files is only compiled for the right archictures). This greatly simplifies the build process because it is not necessary to build libffi a couple of times and then merge the resulting binaries.

I'm -0 at this point w.r.t. trying to remove libffi_osx, that tree works and I'll work on it anyway (it is also used in PyObjC).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 12 15:54:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 14:54:57 +0000
Subject: [issue17193] Use binary prefixes
Message-ID: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Starting around 1998, a number of standards and trade organizations approved standards and recommendations for a new set of binary prefixes that would refer unambiguously to powers of 1024. According to these, the SI prefixes would only be used in the decimal sense, even when referring to data storage capacities: kilobyte and megabyte would denote one thousand bytes and one million bytes respectively (consistent with SI), while new terms such as kibibyte, mebibyte and gibibyte, abbreviated KiB, MiB, and GiB, would denote 1024 bytes, 1048576 bytes, and 1073741824 bytes respectively.[1]

The proposed patch replaces old terms such as kB or KBytes by new terms such as KiB.

[1] http://en.wikipedia.org/wiki/Binary_prefix

----------
assignee: docs at python
components: Documentation
files: binary_prefixes.patch
keywords: easy, patch
messages: 181961
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use binary prefixes
type: enhancement
Added file: http://bugs.python.org/file29049/binary_prefixes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Tue Feb 12 16:07:18 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Feb 2013 15:07:18 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1360681638.78.0.333474893536.issue9285@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

A preliminary patch for cProfile.py is in attachment. Will make changes to profile.py later.

----------
Added file: http://bugs.python.org/file29050/profile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Tue Feb 12 16:10:07 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Feb 2013 15:10:07 +0000
Subject: [issue17187] Python segfaults from improperly formed and called
	function
In-Reply-To: <1360626883.99.0.640748040618.issue17187@psf.upfronthosting.co.za>
Message-ID: <1360681807.24.0.259909182036.issue17187@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

In general, you can generate whatever junky bytecode you want, and the eval loop will happy crash itself. Your on your own when screwing with types.CodeType.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17187>
_______________________________________

From report at bugs.python.org  Tue Feb 12 17:15:36 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Feb 2013 16:15:36 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360666881.8.0.701759044328.issue17170@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLR=foCC6Sy+ojZb99VLxgC=C3b_vXW7zYBH7Wp1Lgxog@mail.gmail.com>


Guido van Rossum added the comment:

What's the status of Argument Clinic? Won't that make this obsolete?

--Guido van Rossum (sent from Android phone)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Tue Feb 12 17:13:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2013 16:13:38 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360685618.37.0.206063877507.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch looks good except for the consistent lack of space between number and unit, e.g. "5MiB" instead of "5 MiB". Is there a reason for this?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Tue Feb 12 17:37:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 16:37:42 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360687062.84.0.731523839757.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, there is a little reason. It looks ugly if a line broken between number and unit (this is possible if we use space). A non-breakable space is better, but it seems that there is no easy way to specify it in ReST. I will be glad to be wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Tue Feb 12 17:43:15 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Feb 2013 16:43:15 +0000
Subject: [issue17194] operator.attrgetter is slow
Message-ID: <1360687395.37.0.294029575872.issue17194@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

When two implementations give the same result, I use to run micro benchmarks to give me an hint.

I just noticed that attrgetter is slower than a lambda here:

$ python3.3 -m timeit -s 'from operator import attrgetter; n1 = attrgetter("__name__"); n2 = lambda s: s.__name__' 'rv = n1(int)'
1000000 loops, best of 3: 0.275 usec per loop
$ python3.3 -m timeit -s 'from operator import attrgetter; n1 = attrgetter("__name__"); n2 = lambda s: s.__name__' 'rv = n2(int)'
1000000 loops, best of 3: 0.347 usec per loop

(verified with 2.6, 2.7 and 3.3. But for 2.5 attrgetter is faster)


The function operator.itemgetter does not have same issue.
$ python3.3 -m timeit -s 'from operator import itemgetter; n1 = itemgetter("foot"); n2 = lambda s: s["foot"]; d = {"foot": 42}' 'rv = n1(d)'
10000000 loops, best of 3: 0.122 usec per loop
$ python3.3 -m timeit -s 'from operator import itemgetter; n1 = itemgetter("foot"); n2 = lambda s: s["foot"]; d = {"foot": 42}' 'rv = n2(d)'
10000000 loops, best of 3: 0.176 usec per loop

----------
messages: 181967
nosy: flox
priority: low
severity: normal
status: open
title: operator.attrgetter is slow
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17194>
_______________________________________

From report at bugs.python.org  Tue Feb 12 17:43:38 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Feb 2013 16:43:38 +0000
Subject: [issue17194] operator.attrgetter is slower than a lambda
In-Reply-To: <1360687395.37.0.294029575872.issue17194@psf.upfronthosting.co.za>
Message-ID: <1360687418.99.0.119165698036.issue17194@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
title: operator.attrgetter is slow -> operator.attrgetter is slower than a lambda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17194>
_______________________________________

From report at bugs.python.org  Tue Feb 12 18:04:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2013 17:04:49 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360688689.64.0.605661724598.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It might be ugly but it's also incorrect formatting to leave the space out. =) And I think it makes it harder to actually read the number.

If you really want to avoid the breaking you can use the tip at http://stackoverflow.com/questions/11830242/non-breaking-space or the Unicode \xa0 literal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Tue Feb 12 18:06:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Feb 2013 17:06:59 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360666881.8.0.701759044328.issue17170@psf.upfronthosting.co.za>
Message-ID: <268137348.29957053.1360688812890.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I left some comments on Rietveld.
> 
> I wonder if PyArg_ParseTupleAndKeywords can be replaced by something
> that would compute and cache the set of keywords; a bit like
> _Py_IDENTIFIER.

It would make sense indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Tue Feb 12 18:50:01 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 12 Feb 2013 17:50:01 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1360691401.97.0.507125095248.issue11816@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I've updated Nick's patch so that test_dis and test_peephole pass again, and added a prototype ByteCode class (without any docs or tests for now, to allow for API discussion).

The prototype ByteCode is instantiated with any of the objects that get_instructions already accepts (functions, methods, code strings & code objects). Iterating over it yields Instruction objects. It has info(), show_info() and display_code() methods, which correspond to the code_info(), show_code() and disassemble() functions.

I've tried to go for names that make sense, rather than names that fit the existing pattern, because the existing pattern feels a bit messy. E.g. the show_code() function doesn't actually show the code, so I've called its method equivalent show_info().

----------
nosy: +takluyver
Added file: http://bugs.python.org/file29051/dis_api.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Tue Feb 12 19:16:50 2013
From: report at bugs.python.org (Julian)
Date: Tue, 12 Feb 2013 18:16:50 +0000
Subject: [issue17195] Reading source code from file on exception
Message-ID: <1360693010.27.0.768238405027.issue17195@psf.upfronthosting.co.za>


New submission from Julian:

When an exception occurs and a traceback is printed, the source code is read from the file which leads to confusion when the file has been modified, but the code that produced the exception still had the old code in memory.

----------
components: Interpreter Core
messages: 181971
nosy: Mezgrman
priority: normal
severity: normal
status: open
title: Reading source code from file on exception
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17195>
_______________________________________

From report at bugs.python.org  Tue Feb 12 20:21:07 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Feb 2013 19:21:07 +0000
Subject: [issue17195] Reading source code from file on exception
In-Reply-To: <1360693010.27.0.768238405027.issue17195@psf.upfronthosting.co.za>
Message-ID: <1360696867.29.0.245201162882.issue17195@psf.upfronthosting.co.za>


Florent Xicluna added the comment:

Duplicate of #8087

----------
nosy: +flox
resolution:  -> duplicate
status: open -> closed
superseder:  -> Unupdated source file in traceback

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17195>
_______________________________________

From report at bugs.python.org  Tue Feb 12 20:37:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Feb 2013 19:37:47 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <3Z5Dff2gKkzQFN@mail.python.org>


Roundup Robot added the comment:

New changeset 680959a3ae2e by Serhiy Storchaka in branch '2.7':
Issue #13555: cPickle now supports files larger than 2 GiB.
http://hg.python.org/cpython/rev/680959a3ae2e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Tue Feb 12 21:07:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 20:07:31 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360699651.33.0.643712530382.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes I have seen these tips and they look complicated enough. Here is an updated patch with spaces between numbers and units.

----------
Added file: http://bugs.python.org/file29052/binary_prefixes_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Tue Feb 12 22:13:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2013 21:13:51 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360703631.34.0.574001705692.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Tue Feb 12 22:33:09 2013
From: report at bugs.python.org (jake)
Date: Tue, 12 Feb 2013 21:33:09 +0000
Subject: [issue17196] crash
Message-ID: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>


New submission from jake:

I have had python 3.3.0 on my mac and have been successfully using it for the past few weeks.  Today in my class I had the program open and it was running fine.  Then suddenly it quit working and shut itself down.  I have restarted my machine multiple times and reinstalled the program over 5 times and it still will not open at all now.  Does anyone know why this might be?  I am currently running OSX 10.8.2 and trying to get the python version 3.3.0 to run.  I am puzzled as to why it would work fine for so long and then suddenly decide to stop and even not open after reinstallation.  I would appreciate it if someone could help me troubleshoot how to get it up and running again.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 181976
nosy: flynn11, ronaldoussoren
priority: normal
severity: normal
status: open
title: crash
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Tue Feb 12 22:59:45 2013
From: report at bugs.python.org (Mauro Cicognini)
Date: Tue, 12 Feb 2013 21:59:45 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1360706385.7.0.572101806926.issue917120@psf.upfronthosting.co.za>


Mauro Cicognini added the comment:

David, that is exactly what I meant: functionality for Python 3 is less than the functionality available for Python 2, and behavior is completely out of sync with the documentation.

Bug or not, and independent of the root cause (I don't know if anyone will ever come up with more or better tests), I agree that this behavior for Python 3 has been around for a long time. I don't think it will break any significant code, but that's just my personal opinion; the main point is that re-introducing quoting functionality in imaplib would be a significant effort, also because reading the other relevant threads it is apparent that correct implementation is not there in Python 2 either.

I think that we have an easy way: 1) fix the documentation for Python 3 so that it reflects behavior and 2) expose the _quote() private method with a new static function that the user will be able to call when they deem it necessary.
They get to come up with a good regex or other ways to detect strings that need quoting, but still it's better than relying (like I did) on the advertised functionality and having to dig into the bowels of the module to understand the source of some bizarre bugs...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue917120>
_______________________________________

From report at bugs.python.org  Tue Feb 12 23:23:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 22:23:30 +0000
Subject: [issue17194] operator.attrgetter is slower than a lambda
In-Reply-To: <1360687395.37.0.294029575872.issue17194@psf.upfronthosting.co.za>
Message-ID: <1360707810.17.0.745792568867.issue17194@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Are you sure? 0.275 < 0.347

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17194>
_______________________________________

From report at bugs.python.org  Tue Feb 12 23:30:54 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 12 Feb 2013 22:30:54 +0000
Subject: [issue17194] operator.attrgetter is slower than a lambda
In-Reply-To: <1360687395.37.0.294029575872.issue17194@psf.upfronthosting.co.za>
Message-ID: <1360708254.36.0.265533301909.issue17194@psf.upfronthosting.co.za>


Florent Xicluna added the comment:

You're right. I've misinterpreted the figures.

Only 2.6 and 2.7 are affected --> closing the issue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17194>
_______________________________________

From report at bugs.python.org  Tue Feb 12 23:40:09 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Feb 2013 22:40:09 +0000
Subject: [issue17197] c/profile refactoring
Message-ID: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

profile and cProfile modules define the same utility functions (run() and runctx()) which use the same code except the profiler class.
Considering that we're going to add 2 new utility functions (runcall() and runblock(), see issue9285 and issue17130) I think we should refactor the code in order to avoid this code duplication.
Patch in attachment does that.
The approach I came up with looks a bit hackish though so I'd like to get some feedback. Is it acceptable?

----------
files: profile-refactoring.diff
keywords: patch
messages: 181980
nosy: georg.brandl, giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: c/profile refactoring
Added file: http://bugs.python.org/file29053/profile-refactoring.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Tue Feb 12 23:40:35 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Feb 2013 22:40:35 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>
Message-ID: <1360708835.29.0.126037732295.issue17197@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
components: +Library (Lib)
keywords: +easy -patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Tue Feb 12 23:42:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Feb 2013 22:42:25 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <3Z5Jlh3NnRzMt7@mail.python.org>


Roundup Robot added the comment:

New changeset b368fc93dca8 by Serhiy Storchaka in branch '2.7':
Issue #16800: tempfile.gettempdir() no longer left temporary files when
http://hg.python.org/cpython/rev/b368fc93dca8

New changeset 377123f10820 by Serhiy Storchaka in branch '3.2':
Issue #16800: tempfile.gettempdir() no longer left temporary files when
http://hg.python.org/cpython/rev/377123f10820

New changeset 6f432bb11b28 by Serhiy Storchaka in branch '3.3':
Issue #16800: tempfile.gettempdir() no longer left temporary files when
http://hg.python.org/cpython/rev/6f432bb11b28

New changeset b66a5b41d82f by Serhiy Storchaka in branch 'default':
Issue #16800: tempfile.gettempdir() no longer left temporary files when
http://hg.python.org/cpython/rev/b66a5b41d82f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16800>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:02:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Feb 2013 23:02:26 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <3Z5KBp1JYMzPst@mail.python.org>


Roundup Robot added the comment:

New changeset a43f67e95ef0 by Serhiy Storchaka in branch '2.7':
Fix for issue #16800: Use buffered write to handle EINTR.
http://hg.python.org/cpython/rev/a43f67e95ef0

New changeset 4622206db91b by Serhiy Storchaka in branch '3.2':
Fix for issue #16800: Use buffered write to handle EINTR.
http://hg.python.org/cpython/rev/4622206db91b

New changeset 2fb03fe354e3 by Serhiy Storchaka in branch '3.3':
Fix for issue #16800: Use buffered write to handle EINTR.
http://hg.python.org/cpython/rev/2fb03fe354e3

New changeset fec33725f319 by Serhiy Storchaka in branch 'default':
Fix for issue #16800: Use buffered write to handle EINTR.
http://hg.python.org/cpython/rev/fec33725f319

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16800>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:06:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 23:06:03 +0000
Subject: [issue16800] tempfile._get_default_tempdir() leaves files behind when
	HD is full
In-Reply-To: <1356673057.72.0.476993951408.issue16800@psf.upfronthosting.co.za>
Message-ID: <1360710363.88.0.290568997618.issue16800@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for explanation, Antoine.

Thank you for your contribution, Amir.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16800>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:44:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 23:44:32 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1360712672.54.0.696993494424.issue11311@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11311>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:44:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 23:44:44 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360712684.79.0.837796046836.issue5308@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:47:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 23:47:04 +0000
Subject: [issue16996] Reuse shutil.which() in webbrowser module
In-Reply-To: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za>
Message-ID: <1360712824.44.0.180149691752.issue16996@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16996>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:49:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 23:49:30 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <1360712970.25.0.687530020765.issue16743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 00:52:18 2013
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 12 Feb 2013 23:52:18 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <1360713138.31.0.529466431533.issue16743@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 01:08:15 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Feb 2013 00:08:15 +0000
Subject: [issue17196] crash
In-Reply-To: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>
Message-ID: <1360714095.36.0.323714216322.issue17196@psf.upfronthosting.co.za>


Ned Deily added the comment:

How exactly are you invoking Python?  From a terminal command line?  What messages do you see when you type:

    /usr/local/bin/python3.3

Or from IDLE?  If so, try invoking IDLE from a terminal:

    /usr/local/bin/idle3.3

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Wed Feb 13 01:36:13 2013
From: report at bugs.python.org (jake)
Date: Wed, 13 Feb 2013 00:36:13 +0000
Subject: [issue17196] crash
In-Reply-To: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>
Message-ID: <1360715773.84.0.648316573534.issue17196@psf.upfronthosting.co.za>


jake added the comment:

Ned,
   I was starting python from the applications menu and selecting IDLE.  I tried both of those commands.  Both worked, the first started python in terminal and displayed this message:
"Last login: Tue Feb 12 16:32:21 on ttys000
localhost:~ jakeflynn$ /usr/local/bin/python3.3
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 01:25:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "

, the second started up a python shell.  But even though python is now open, the icon on the dock is different and none of my previous python files will open.  When i try to open them, the IDLE icon im used to seeing bounces a few times and then disappears while the other python IDLE icon that started up after entering the second command line you gave me is up the whole time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Wed Feb 13 01:53:06 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Feb 2013 00:53:06 +0000
Subject: [issue17196] crash
In-Reply-To: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>
Message-ID: <1360716786.73.0.0444646913931.issue17196@psf.upfronthosting.co.za>


Ned Deily added the comment:

"But even though python is now open, the icon on the dock is different and none of my previous python files will open.  When i try to open them, the IDLE icon im used to seeing bounces a few times and then disappears while the other python IDLE icon that started up after entering the second command line you gave me is up the whole time."

>From that I take it that you are trying to open the python files by double clicking on them?  If so, try launching idle from the command line again and, from its menu bar (which will be labeled as "Python" instead of "IDLE", try opening your python files with the File -> Open menu and see if that brings up an IDLE edit window that you can use.

Also, after quitting the command line IDLE, try the following in the terminal:

grep TK_PATCH_LEVEL /Library/Frameworks/Tk.framework/tkConfig.sh
# report what this says
cd ~
mv .idlerc .idlerc-DISABLED

That will restore all of IDLE's defaults.  Then, try double-clicking on IDLE again.  If it still fails to launch, check the system.log for relevant error messages.  You can use the Console app (in /Applications/Utilities/) for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Wed Feb 13 02:02:14 2013
From: report at bugs.python.org (jake)
Date: Wed, 13 Feb 2013 01:02:14 +0000
Subject: [issue17196] crash
In-Reply-To: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>
Message-ID: <1360717334.42.0.409307893657.issue17196@psf.upfronthosting.co.za>


jake added the comment:

It is working correctly now.  Thank you for the help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Wed Feb 13 02:06:53 2013
From: report at bugs.python.org (Michael Foord)
Date: Wed, 13 Feb 2013 01:06:53 +0000
Subject: [issue17196] crash
In-Reply-To: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>
Message-ID: <1360717613.81.0.142915453014.issue17196@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Wed Feb 13 02:07:59 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Feb 2013 01:07:59 +0000
Subject: [issue17196] crash
In-Reply-To: <1360704789.39.0.076255717707.issue17196@psf.upfronthosting.co.za>
Message-ID: <1360717679.97.0.664143914985.issue17196@psf.upfronthosting.co.za>


Ned Deily added the comment:

If moving .idlerc fixed the problem, undoubtedly one of the IDLE config files had a corrupted value.  There have been some fixes since 3.3.0 to make that part of IDLE more robust.  If you want to pursue the issue, you can reopen this issue and upload the files from the broken .idlerc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17196>
_______________________________________

From report at bugs.python.org  Wed Feb 13 04:18:18 2013
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 13 Feb 2013 03:18:18 +0000
Subject: [issue17198] dbm.whichdbm references non-existent 'ndbm'
Message-ID: <1360725498.06.0.499686664826.issue17198@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

There are a couple references to an 'ndbm' variable/module in this function on Python 3.2 and above (and just one reference on default). It appears to be leftover from the 3.x reworking of this module

----------
components: Library (Lib)
messages: 181990
nosy: georg.brandl, pjenvey
priority: normal
severity: normal
stage: needs patch
status: open
title: dbm.whichdbm references non-existent 'ndbm'
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17198>
_______________________________________

From report at bugs.python.org  Wed Feb 13 04:33:15 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 13 Feb 2013 03:33:15 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360726395.11.0.333643731071.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

This is a gentle ping of this issue.  Can somebody please review and let me know what needs to be done to get this committed?  I did test the patch on 2/12/2013 and it seems to work from the latest 3.4.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 05:47:57 2013
From: report at bugs.python.org (Enrique A Tobis)
Date: Wed, 13 Feb 2013 04:47:57 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
Message-ID: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>


New submission from Enrique A Tobis:

import logging

f = logging.StrFormatStyle('{asctimer}')
print(f.usesTime())
f = logging.PercentStyle('%(astimer)s')
print(f.usesTime())

prints

True
False

and I think it should print

False
False

----------
components: Library (Lib)
messages: 181992
nosy: etobis
priority: normal
severity: normal
status: open
title: Slightly wrong behavior of logging.StrFormatStyle.usesTime
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 05:49:43 2013
From: report at bugs.python.org (Enrique A Tobis)
Date: Wed, 13 Feb 2013 04:49:43 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
In-Reply-To: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>
Message-ID: <1360730983.65.0.451393162961.issue17199@psf.upfronthosting.co.za>


Changes by Enrique A Tobis <enrique at tobis.com.ar>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29054/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 06:06:46 2013
From: report at bugs.python.org (Reuben D'Netto)
Date: Wed, 13 Feb 2013 05:06:46 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
Message-ID: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>


New submission from Reuben D'Netto:

read_until() takes a value for timeout in seconds, but passes it to poll(), which takes a value in milliseconds.

----------
files: telnetlib.py.patch
keywords: patch
messages: 181993
nosy: Reuben.D'Netto
priority: normal
severity: normal
status: open
title: telnetlib.read_until() timeout uses the wrong units
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29055/telnetlib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Feb 13 06:34:27 2013
From: report at bugs.python.org (Reuben D'Netto)
Date: Wed, 13 Feb 2013 05:34:27 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>
Message-ID: <1360733667.7.0.699822660492.issue17200@psf.upfronthosting.co.za>


Reuben D'Netto added the comment:

Updated patch to fix expect() as well.

----------
Added file: http://bugs.python.org/file29056/telnetlib.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Feb 13 06:59:40 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 05:59:40 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>
Message-ID: <1360735180.71.0.758594857167.issue17200@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the bug report, Reuben. I verified that this is indeed a bug and should be fixed in all versions. Thanks for the patch too, would you like to enhance it with tests? GeneralTests in test_telnetlib.py support timeout and you could that exercise timeout value in secs.

----------
nosy: +orsenthil
stage:  -> test needed
versions: +Python 2.7, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Feb 13 07:18:30 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 13 Feb 2013 06:18:30 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>
Message-ID: <1360736310.04.0.403027857964.issue17200@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

this bug was likely introduced when i applied the telnetlib patches to use poll to not hit the select fd limit.  doh.  nice catch!

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Feb 13 07:39:20 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 06:39:20 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360736310.04.0.403027857964.issue17200@psf.upfronthosting.co.za>
Message-ID: <CAPOVWORGMuGMumHKiD0-165OBQ=k3HHOdtw7F74rwLxtV=vWYw@mail.gmail.com>


Senthil Kumaran added the comment:

@gps: looks like it is. For changeset:   78129:de229dde486b for Issue #14635

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Feb 13 08:06:22 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Feb 2013 07:06:22 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1360739182.2.0.407641998387.issue11816@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks Thomas! It's a promising start - a few more detailed comments in the patch review.

I like the idea of creating the initial version as an object-oriented wrapper around the existing APIs, rather than completely refactoring the module to make everything else a functional wrapper around an underlying object-oriented implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From senthil at uthcode.com  Wed Feb 13 08:16:20 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 12 Feb 2013 23:16:20 -0800
Subject: [issue16996] Reuse shutil.which() in webbrowser module
In-Reply-To: <1360712824.44.0.180149691752.issue16996@psf.upfronthosting.co.za>
References: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za>
	<1360712824.44.0.180149691752.issue16996@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSFB1vUQQENZtiK2Rmf3bJT0365uRizpuR4Wzep3OWzhw@mail.gmail.com>

Serhiy: The patch LGTM.

From report at bugs.python.org  Wed Feb 13 08:16:22 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 07:16:22 +0000
Subject: [issue16996] Reuse shutil.which() in webbrowser module
In-Reply-To: <1360712824.44.0.180149691752.issue16996@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSFB1vUQQENZtiK2Rmf3bJT0365uRizpuR4Wzep3OWzhw@mail.gmail.com>


Senthil Kumaran added the comment:

Serhiy: The patch LGTM.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16996>
_______________________________________

From report at bugs.python.org  Wed Feb 13 08:42:20 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Feb 2013 07:42:20 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1360741340.92.0.0192313331868.issue16612@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for documenting the clinic DSL as a PEP. It's a bit too hard to find the rationale for toolchain changes like this when they're hidden away in tracker issues.

It doesn't need to be an extended essay like most of the PEPs I write, it can be relatively short and sweet (consider the PEP that approved the addition of unittest.mock: http://www.python.org/dev/peps/pep-0417/)

As Greg suggested, taking the current clinic.txt and publishing it as a "DSL for C API argument processing" PEP would get you most of the way there.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Wed Feb 13 08:44:49 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Feb 2013 07:44:49 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360741489.48.0.10532364025.issue17170@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

To answer Guido's question about clinic, see http://bugs.python.org/issue16612

Mostly positive feedback, but several of us would like a PEP to make sure we're happy with the resolution of the limited negative feedback.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Wed Feb 13 09:05:18 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 13 Feb 2013 08:05:18 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360742718.17.0.00821739217575.issue17170@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Argument Clinic has languished for lack of time.  I didn't get much feedback, though a couple people were shouting for a PEP, which I was resisting.  I figured, if they have something to say, they can go ahead and reply on the tracker issue, and if they don't have something to say, why do we need a PEP?

I need to reply to one bit of thorough feedback, and after that--I don't know.  I'd like to get things moving before PyCon so we can point sprinters at it.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Wed Feb 13 09:05:37 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 08:05:37 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360742737.56.0.212742812052.issue16278@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The doc change looks good to me. I am adding Terry and Ezio to see if they have any comments on wordings in the doc. If not, I can commit this change. I think that this is helpful.

----------
nosy: +ezio.melotti, orsenthil, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 09:10:21 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 08:10:21 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360743021.67.0.0864078681857.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I commented above that the tests are not very DRY though.  Shouldn't there be tests to check that the documented behavior is correct?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 09:43:42 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 08:43:42 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1360743021.67.0.0864078681857.issue16278@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSaZNPxDhnBJ08xaJtAAN1ZR__+rKr2W3rY-d4yKS1C9Q@mail.gmail.com>


Senthil Kumaran added the comment:

Chris:  The patch is for the docs. the test code I believe, is for
reference. It would be to run it on different OS and verify the
documentation matches the behavior.I am okay with more than one person
verifying this and I shall do on OS'es I have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 09:57:10 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 13 Feb 2013 08:57:10 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360745830.89.0.541843359388.issue17170@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Oh, and, as to whether Argument Clinic would solve this problem, the answer is "not yet".  Right now Argument Clinic literally generates calls to PyArg_ParseTupleAndKeywords.  (In special cases it switches to PyArg_ParseTuple.)

I'm more interested in Argument Clinic from the API perspective; I wanted to make a better way of specifying arguments to functions so we got all the metadata we needed without having to endlessly repeat ourselves.  Truthfully I was hoping someone else would pick up the gauntlet once it was checked in and make a new argument processing API / hack up the Argument Clinic output to make it faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:05:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 10:05:51 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360749951.94.0.949693407961.issue17170@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Truthfully I was hoping someone else would pick up the gauntlet once it 
> was checked in and make a new argument processing API / hack up the
> Argument Clinic output to make it faster.

Argument Clinic's preprocessing would be a very nice building block to generate faster parsing sequences.
Like Nick I'd still like to see a PEP, though ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:09:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 10:09:09 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>
Message-ID: <1360750149.48.0.312599387636.issue17197@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The patch doesn't look right to me. If you import cProfile, profile will always invoke the cProfile profiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:10:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 10:10:24 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360750224.45.0.139424238188.issue17189@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Would there be a way to automatically switch the flag as necessary?
(i.e. when writing more than 2GB, I guess)

----------
nosy: +hynek, pitrou, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:10:58 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Feb 2013 10:10:58 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>
Message-ID: <1360750258.42.0.775186583691.issue17197@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

No, it's the other way around. It's from cProfile which I import profile.

diff --git a/Lib/cProfile.py b/Lib/cProfile.py
--- a/Lib/cProfile.py
+++ b/Lib/cProfile.py
...
+import profile as _pyprofile

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:11:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 10:11:49 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360750309.77.0.513864015034.issue17180@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes, hynek, tarek
priority: normal -> high
type:  -> security
versions: +Python 3.3, Python 3.4 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:15:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Feb 2013 10:15:18 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <3Z5c792F5kzRCW@mail.python.org>


Roundup Robot added the comment:

New changeset 385d982ce641 by Serhiy Storchaka in branch '2.7':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/385d982ce641

New changeset e0464fa28c85 by Serhiy Storchaka in branch '3.2':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/e0464fa28c85

New changeset b48e1cd2d3be by Serhiy Storchaka in branch '3.3':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/b48e1cd2d3be

New changeset ea36478a36ee by Serhiy Storchaka in branch 'default':
Issue #5308: Raise ValueError when marshalling too large object (a sequence
http://hg.python.org/cpython/rev/ea36478a36ee

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:20:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Feb 2013 10:20:34 +0000
Subject: [issue16996] Reuse shutil.which() in webbrowser module
In-Reply-To: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za>
Message-ID: <3Z5cFG1JR1zRCW@mail.python.org>


Roundup Robot added the comment:

New changeset 050c94f5f72c by Serhiy Storchaka in branch 'default':
Issue #16996: webbrowser module now uses shutil.which() to find a
http://hg.python.org/cpython/rev/050c94f5f72c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16996>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:27:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Feb 2013 10:27:56 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <3Z5cPm0bZBzQBG@mail.python.org>


Roundup Robot added the comment:

New changeset 7513bd184a01 by Serhiy Storchaka in branch '2.7':
Issue #11311: StringIO.readline(0) now returns an empty string as all other
http://hg.python.org/cpython/rev/7513bd184a01

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11311>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:34:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Feb 2013 10:34:26 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <3Z5cYF4msBzQGN@mail.python.org>


Roundup Robot added the comment:

New changeset 72e75ea25d00 by Serhiy Storchaka in branch '2.7':
Fix tests for issue #5308.
http://hg.python.org/cpython/rev/72e75ea25d00

New changeset 0407e5e5915e by Serhiy Storchaka in branch '3.3':
Cleanup a test for issue #5308.
http://hg.python.org/cpython/rev/0407e5e5915e

New changeset e45f2fcf202c by Serhiy Storchaka in branch 'default':
Cleanup a test for issue #5308.
http://hg.python.org/cpython/rev/e45f2fcf202c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:38:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:38:38 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360751918.51.0.895723161427.issue5308@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Perhaps you could add a bigmem test for this?
> (assuming you have enough memory somewhere to test it)

Some tests require more than 252 GiB of memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:40:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:40:40 +0000
Subject: [issue11311] StringIO.readline(0) returns incorrect results
In-Reply-To: <1298583142.96.0.124636829869.issue11311@psf.upfronthosting.co.za>
Message-ID: <1360752040.62.0.395476465784.issue11311@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed. Thank you for the report, Ville.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11311>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:41:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:41:25 +0000
Subject: [issue16996] Reuse shutil.which() in webbrowser module
In-Reply-To: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za>
Message-ID: <1360752085.43.0.364303745373.issue16996@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you, Senthil.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16996>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:46:25 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 13 Feb 2013 10:46:25 +0000
Subject: [issue16692] Support TLS 1.1 and TLS 1.2
In-Reply-To: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za>
Message-ID: <1360752385.64.0.515484481516.issue16692@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16692>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:55:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:55:30 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360752930.81.0.0444453590029.issue17189@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Would there be a way to automatically switch the flag as necessary?
> (i.e. when writing more than 2GB, I guess)

Yes, there is a special flag for this in zipfile. It is named allowZip64.

The only reason to use allowZip64=False is when you expect to unzip a zipfile with a tool which doesn't support zip64 (PKUNZIP.EXE for DOS?) and you want to keep yourself from unintentional zipping a file larger than 2 GiB.

Perhaps sometime we should to change the default value for allowZip64 from False to True.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:56:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:56:50 +0000
Subject: [issue16996] Reuse shutil.which() in webbrowser module
In-Reply-To: <1358541875.07.0.897350417662.issue16996@psf.upfronthosting.co.za>
Message-ID: <1360753010.24.0.573858174936.issue16996@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16996>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:58:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:58:22 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360753102.73.0.557959058656.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For what versions can I apply this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Wed Feb 13 11:59:26 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Feb 2013 10:59:26 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360753166.9.0.186746596966.issue17180@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks for the report. I agree with your analysis. We should follow the behavior of cp and always strip off the suid/sgid bits in shutil.copy(). coreutil's cp removes the bits and doesn't handle source owner = destination owner special.

There are other bits that may need special treatment, too. I'm going to check the sources of cp.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 12:10:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Feb 2013 11:10:31 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360753831.24.0.898622654153.issue17180@psf.upfronthosting.co.za>


Christian Heimes added the comment:

cp removes three bits unless preserve ownership is enabled and some additional things are true. 

mode &= ~ (S_ISUID | S_ISGID | S_ISVTX)

S_ISVTX is the sticky bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 12:49:27 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 13 Feb 2013 11:49:27 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360756167.22.0.450761827367.issue17180@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

While I agree that it?s a problem, I?m a bit uneasy about changing that back to 2.7. I?m pretty sure this would break numerous programs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:00:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Feb 2013 12:00:38 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360756838.37.0.345669432997.issue17180@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a patch for the issue with test and doc updates.

I'm escalating the bug to release blocker to draw the attention of our RMs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:00:47 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Feb 2013 12:00:47 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360756847.69.0.487106060379.issue17180@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29057/17180.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:01:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Feb 2013 12:01:23 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
In-Reply-To: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>
Message-ID: <1360756883.7.0.135209906565.issue17199@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/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:02:25 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Feb 2013 12:02:25 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
In-Reply-To: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>
Message-ID: <1360756945.22.0.635131001866.issue17199@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type: enhancement -> behavior
versions: +Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:05:55 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Feb 2013 12:05:55 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360757155.58.0.0735856994984.issue17180@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Sorry for the extra noise. I got into a comment conflict with Hynek.

Hynek,
I don't think it's going to break lots of apps. setuid/setgid programs are rare these days. Most operating system ignore sticky bits on files, too.

It may break system scripts that copy entire Unix systems with a recursive copytree(), though ...

----------
nosy: +benjamin.peterson, georg.brandl, larry
priority: high -> release blocker
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:07:01 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 13 Feb 2013 12:07:01 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360757221.5.0.447680664964.issue17180@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

Yeah, I?m thinking about backup scripts etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:08:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 12:08:04 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360750258.42.0.775186583691.issue17197@psf.upfronthosting.co.za>
Message-ID: <91414180.31981704.1360757278458.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> No, it's the other way around. It's from cProfile which I import
> profile.
> 
> diff --git a/Lib/cProfile.py b/Lib/cProfile.py
> --- a/Lib/cProfile.py
> +++ b/Lib/cProfile.py
> ...
> +import profile as _pyprofile

That's exactly what I'm saying. Once you import cProfile, the attributes
on the profile functions are overriden.
Either way, a module shouldn't mutate another module's functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:10:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 12:10:17 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360757417.28.0.677229355025.issue17189@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Yes, there is a special flag for this in zipfile. It is named
> allowZip64.

Then I think shutil should set allowZip64 to True by default.
People who want fine-grained control over the zipfile's characteristics can still use the zipfile module directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 13:55:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Feb 2013 12:55:16 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <3Z5ggl4ZHzzMvM@mail.python.org>


Roundup Robot added the comment:

New changeset b1bbe519770b by Richard Oudkerk in branch '2.7':
Issue #16743: Fix mmap overflow check on 32 bit Windows
http://hg.python.org/cpython/rev/b1bbe519770b

New changeset c2c84d3ab393 by Richard Oudkerk in branch '3.2':
Issue #16743: Fix mmap overflow check on 32 bit Windows
http://hg.python.org/cpython/rev/c2c84d3ab393

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 14:04:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 13 Feb 2013 13:04:01 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360760641.04.0.610411811451.issue17180@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a new patch with a new keyword argument preserve_sbits. Perhaps we use `True` as default for Python 2.6 to 3.3 and switch to False in Python 3.4?

----------
Added file: http://bugs.python.org/file29058/17180_preserve_sbits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 14:06:29 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Feb 2013 13:06:29 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1360760789.18.0.617983449453.issue16612@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Here's a proposal for an alternative without parameter docstrings and a
different DSL (see os_stat.c). I guess it's easiest to present my thoughts
in list form.


Changes and rationale:
======================

  Split docstring into function header and rest
  ---------------------------------------------

    - Since the docstrings aren't repeated, less vertical space is used.

    - The main part of the docstring can go into a header file.

    - It's (IMO) easier to compare the generated header (see OS_STAT_HEADER)
      to the specification in the comment.


  More formal DSL
  ---------------

    This is my personal opinion: The existing DSL is fine for a configuration
    file (think .hgrc), but I have trouble with it in the context of a C file.

    Most importantly, I'm unable to take in the required information at a
    single glance.

    So I propose to make the structure of the specification explicit. For
    me the result is more readable. Also, it's already pretty close to a formal
    grammar and can be optionally condensed into single lines.

  Logical grouping
  ----------------

    The preprocessor comment, OS_STAT_HEADER and the os_stat() definition are
    close together and fit on a single screen.

----------
Added file: http://bugs.python.org/file29059/os_stat.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Wed Feb 13 14:09:15 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Wed, 13 Feb 2013 13:09:15 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360760955.88.0.833723870366.issue17180@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

SGTM. I?d like an explicit warning on the security implications in the docs though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 14:14:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 13:14:26 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360761266.13.0.398829744597.issue17189@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 14:26:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 13:26:01 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <1360761960.98.0.338751410701.issue16743@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps NEWS item needed for this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 14:46:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 13:46:43 +0000
Subject: [issue17089] Expat parser parses strings only when XML encoding is
	UTF-8
In-Reply-To: <1359626479.25.0.87229024986.issue17089@psf.upfronthosting.co.za>
Message-ID: <1360763203.91.0.416978355457.issue17089@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17089>
_______________________________________

From report at bugs.python.org  Wed Feb 13 15:11:36 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 13 Feb 2013 14:11:36 +0000
Subject: [issue17061] tokenize unconditionally emits NL after comment lines &
	blank lines
In-Reply-To: <1359371668.59.0.445577508897.issue17061@psf.upfronthosting.co.za>
Message-ID: <1360764696.92.0.481936320507.issue17061@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Hmm, that's interesting.

For our purposes, a blank line or a comment line shouldn't result in a continuation prompt. This is consistent with what the plain Python shell does.

As part of this, we're tokenizing the code, and if the final \n results in a NL token (instead of NEWLINE), we wait to build a 'Python line'. (Likewise if the final \n doesn't appear before EOFError, indicating that a string continues to the next line). Since tokenize doesn't expose parenlev (parentheses level), my modification to tokenize makes this work as we need.

Maybe another way forward would be to make parenlev accessible in some way, so that we can use that rather than using NL == parenlev > 0?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17061>
_______________________________________

From report at bugs.python.org  Wed Feb 13 15:28:50 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 13 Feb 2013 14:28:50 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
In-Reply-To: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>
Message-ID: <1360765730.58.0.189472973042.issue17199@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

It's not a bug - the reason it's like that is that it allows conversion and format specifiers to be given - {field_name!conversion:format_spec}.

Of course a more robust solution using regular expressions could be implemented, but it's not really worth it. If there's a misspelt field name, generally you'll know because there will either be an exception raised, or (in production) no output will be produced.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 15:31:15 2013
From: report at bugs.python.org (Enrique A Tobis)
Date: Wed, 13 Feb 2013 14:31:15 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
In-Reply-To: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>
Message-ID: <1360765875.8.0.743596800662.issue17199@psf.upfronthosting.co.za>


Enrique A Tobis added the comment:

Thanks! Got it. Sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 15:33:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 Feb 2013 14:33:35 +0000
Subject: [issue17199] Slightly wrong behavior of
	logging.StrFormatStyle.usesTime
In-Reply-To: <1360730877.2.0.90775500368.issue17199@psf.upfronthosting.co.za>
Message-ID: <1360766015.22.0.0866251386114.issue17199@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would still consider it a bug myself, but I understand and accept that you feel it is not worth fixing.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17199>
_______________________________________

From report at bugs.python.org  Wed Feb 13 15:33:50 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 13 Feb 2013 14:33:50 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1360766030.81.0.81128624691.issue17170@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:27:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Feb 2013 15:27:13 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <3Z5l344sTBzPZG@mail.python.org>


Roundup Robot added the comment:

New changeset 82db097cd2e0 by Richard Oudkerk in branch '2.7':
Add Misc/NEWS entry for Issue #16743
http://hg.python.org/cpython/rev/82db097cd2e0

New changeset efe489f87881 by Richard Oudkerk in branch '3.2':
Add Misc/NEWS entry for Issue #16743
http://hg.python.org/cpython/rev/efe489f87881

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:29:18 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 13 Feb 2013 15:29:18 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <1360769358.78.0.494159422599.issue16743@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Perhaps NEWS item needed for this change.

Done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:29:43 2013
From: report at bugs.python.org (Sebastian Berg)
Date: Wed, 13 Feb 2013 15:29:43 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1360769383.81.0.493875253305.issue7279@psf.upfronthosting.co.za>


Sebastian Berg added the comment:

This is closed, and maybe I am missing something. But from a general point of view, why does hashing of NaN not raise an error as it did for decimals, i.e. why was this not resolved exactly the other way around? I am mostly just wondering about this it is not a problem for me.

Hashing NaNs seems dangerous and surprising because it might work in dicts/sets, but normally doesn't. (The only thing for it to work right would be if NaN was a singleton, but that is impossible for subclasses, etc.).

The thing is:

In [16]: s = {float('nan'): 1, float('nan'): 2, float('nan'): 3}
In [17]: s
Out[17]: {nan: 1, nan: 2, nan: 3}

In [18]: s[float('nan')]
KeyError: nan

In [19]: n = float('nan')
In [20]: s = {n: 1, n: 2, n: 3}
In [21]: s
Out[21]: {nan: 3}

This is because `n is n`, and PyObject_RichCompareBool assumes that if `a is b` then `a == b` which is simply wrong for NaNs and also makes comparisons  of iterables including NaNs an impossible business. NaNs have their unavoidable weirdness, but at least for dictionaries/sets it would seem more clear to me if they raised an error.

----------
nosy: +seberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:31:08 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 13 Feb 2013 15:31:08 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360769468.52.0.127393508468.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Chris,
   I first verified the issue then created some wording and you pointed out that we needed test cases so I created a bunch of test cases.  As you pointed out "I count 2*3*2=12 possibilities to check (excluding src and dst being on different filesystems):" so I created 16 test cases then discovered that the behavior is different on Windows and Unix so all together there are 32 test cases.  Your last comment about the test cases being "Dry" didn't make sense to me.  If you provide specific feedback I would be glad to work on the issue.  The test cases are designed to make sure that the documented behavior is actually how Python performs.  It made the most sense to me to put together two patches one for the test cases and another for the documentation, but maybe that has confused everybody?  If it would help I could submit a single patch.  OSRenameCombinations.py was just for reference to prove to myself that I got all the possible test cases.

I am a fairly new Python contributor and this is my first attempt at writing test cases so I could be missing something.  Thanks for the mentorship and the time required for a little extra guidance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:47:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Feb 2013 15:47:33 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360770453.38.0.0923693018631.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

IMO I say just do 3.4 since it isn't really a bug fix but a cleanup, but I wouldn't object if it was backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:50:41 2013
From: report at bugs.python.org (William Mallard)
Date: Wed, 13 Feb 2013 15:50:41 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360770641.48.0.984598989435.issue17189@psf.upfronthosting.co.za>


William Mallard added the comment:

Ok, here's a patch that makes zip64 the default in make_archive() when format='zip'.

I also agree that ZipFile should set allowZip64=True by default. (PKZIP has supported zip64 since 2001!)

----------
Added file: http://bugs.python.org/file29060/shutil_zip64_by_default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 16:53:50 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Feb 2013 15:53:50 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1360770830.69.0.662001368139.issue7279@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Sebastian:  I think this discussion is a bit off-topic for this particular bug;  you might want to raise it on python-dev or python-ideas instead.  

Bear in mind, though, that the behaviour of NaNs and containers has been discussed to death many times in the past;  I'd suggest not bringing the issue up again unless there's something genuinely new to bring to the discussion.  The current behaviour is certainly a compromise, but it seems to be the best compromise available.

Note that with respect to this particular issue: it's only *signalling* nans that raise on hashing for the Decimal type.  Quiet nans are hashable as usual.  Since for float, all nans can be regarded as quiet, Decimal and float behave the same way on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Wed Feb 13 17:29:58 2013
From: report at bugs.python.org (Sebastian Berg)
Date: Wed, 13 Feb 2013 16:29:58 +0000
Subject: [issue7279] decimal.py: == and != comparisons involving NaNs
In-Reply-To: <1257590632.12.0.893741146745.issue7279@psf.upfronthosting.co.za>
Message-ID: <1360772998.56.0.623247874188.issue7279@psf.upfronthosting.co.za>


Sebastian Berg added the comment:

Thanks, yes, you are right, should have googled a bit more anyway. Though I did not find much on the hashable vs unhashable itself, so if I ever stumble across it again, I will write a mail...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7279>
_______________________________________

From report at bugs.python.org  Wed Feb 13 17:39:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 16:39:06 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized
	preprocessor	into CPython trunk
In-Reply-To: <1360760789.18.0.617983449453.issue16612@psf.upfronthosting.co.za>
Message-ID: <1850603693.32643469.1360773539385.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Here's a proposal for an alternative without parameter docstrings and
> a
> different DSL (see os_stat.c). I guess it's easiest to present my
> thoughts
> in list form.

It's a bit difficult to give an opinion without a more formal definition.
For example it seems you are using REQUIRED and KEYWORD as opposites,
but a required argument can also be a keyword argument.

As for the docstring: I would like it better if I could avoid typing
the cumbersome "\n\"s.

As for the general parameter declaration syntax: I think it shouldn't
be too verbose, otherwise it will quickly become tiring.
(also I don't think it should be required to write "[preprocessor]"
twice)

----------
title: Integrate "Argument Clinic" specialized preprocessor into CPython trunk -> Integrate "Argument Clinic" specialized preprocessor	into CPython trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Wed Feb 13 17:41:40 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 13 Feb 2013 16:41:40 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1360773700.1.0.0298165497314.issue17192@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Maybe Modules/_ctypes/libffi in 2.7, 3.2 and 3.3 branches should be updated?

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:04:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:04:32 +0000
Subject: [issue17201] Use allowZip64=True by default
Message-ID: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Python supports ZIP64 extension since 2.5 (more 6 years ago). May be it is time to use it by default, leaving the option to disable it by specifying allowZip64=False.

----------
components: Library (Lib)
messages: 182048
nosy: alanmcintyre, loewis, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use allowZip64=True by default
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:07:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:07:26 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360775246.83.0.00886161149961.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then I'll apply this to 3.3 too. This will facilitate support of both versions.

----------
assignee: docs at python -> serhiy.storchaka
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:08:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 17:08:08 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360775288.93.0.346986698762.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Senthil, in my experience, whenever documentation is added that documents new aspects of behavior (e.g. is not just a rewording of existing documentation), tests are always added simultaneously (if not already present) to ensure that the code doesn't regress against the new documentation.

Todd, DRY means "don't repeat yourself."  You can look it up on Wikipedia, etc.  Identical chunks of code are repeated several times which make it harder for others to see how the test cases differ from each other (as well as making the code harder to maintain).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:13:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 17:13:51 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360775631.21.0.426559387271.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> If it would help I could submit a single patch.

Yes, a single patch is best.  One way to make code more DRY is refactoring to use helper functions as needed (i.e. same code in multiple places -> one helper function).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:17:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:17:07 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360775827.52.0.443478438574.issue17189@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This should be reflected in the documentation.

----------
dependencies: +Use allowZip64=True by default

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:18:01 2013
From: report at bugs.python.org (Bradley Froehle)
Date: Wed, 13 Feb 2013 17:18:01 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized
	preprocessor	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1360775881.25.0.397854831408.issue16612@psf.upfronthosting.co.za>


Bradley Froehle added the comment:

> As for the docstring: I would like it better if I could avoid typing
> the cumbersome "\n\"s.

I agree with Stefan that the file is a lot more readable if the docstring
is not repeated twice. It's unfortunate that C doesn't have a notion of
a raw string (as opposed to C++11 with the new R"(...)" syntax) but I
think it is something we'll have to live with. I would have expected
that a good text editor would be able to convert a selected region into a
C string, but I've never actually seen such a feature.

In general I think we should aim for clarity in scope of the arguments in
the DSL -- either by using curly-braces (a C construct) or indentation (a
Python construct). To minimize the usage of vertical space, I'd like to
see the DSL not require a blank line between arguments.

In a project I worked on recently I ended up writing a parser to go
through a list of C arguments and automatically produce the
PyArg_ParseTuple / PyArg_ParseTupleAndKeywords lines. It's not as
full featured as what we are looking for here, but it did have the
benefit of minimizing the number of extra vertical lines.  For example::

    static PyObject *
    w_rktime(PyObject *self, PyObject *args, PyObject *kwargs)
    {
        /*[kwargs rktime]*/
        darray u;
        meshdata msh;
        double dt;
        int nsteps=1;
        /*[/kwargs]*/
        static char *_keywords[] = {"u", "msh", "dt", "nsteps", NULL};
        if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&O&d|i:rktime", _keywords, view_as_darray, &u, DgMeshData_Converter, &msh, &dt, &nsteps))
            return NULL;
        /*[checksum=...]*/
        ...
    }

I could imagine extending such a syntax to allow custom converters
and other extensions using comments::

    path_t path = PATH_T_INITIALIZE("stat", 0, 1)
        /* converter = path_converter; default = None */;
    int dir_fd = DEFAULT_DIR_FD
        /* converter = OS_STAT_DIR_FD_CONVERTER */;

The biggest downside to this approach would be that the parser could
not inject C code directly into the global scope -- instead it would
be limited to producing #define lines.

-Brad

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:43:11 2013
From: report at bugs.python.org (Jim Jewett)
Date: Wed, 13 Feb 2013 17:43:11 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized
	preprocessor	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1360777391.34.0.975836306339.issue16612@psf.upfronthosting.co.za>


Jim Jewett added the comment:

I'm not sure I correctly understand skrah's proposal.  If I do, then

(1)  The first several lines ( "/* pymacro.h */" until "/* could go into a separate header file */" ) would not be written at all, and are just there to help reviewers understand.

(2)  The "#define OS_STAT_DOC ..." line is the docstring, and would be needed, but could easily go into a separate header file, like os_stat__doc.h.  For something like cdecimal, there might be only a single _cdecimal__doc.h containing all the docstrings.  There might even be a build switch that (at a minimum) replaced anything from those __doc.h files with "" for space-constrained builds.

(3)  The human-maintained code would be the DSL between "/*[preprocessor]" and "[preprocessor]*/".

(4)  The lines between "[preprocessor]*/" and "/*[preprocessor end:f3e6b328245207c240825782d908d3ff3a9c11c0]*/" would NOT be written or maintained by a human, but WOULD be checked into hg for the benefit builders without the argument-clinic tool.

(5)  The only C code written or maintained by a human (or another macro system) would be the last 5 lines (the system call, the path cleanup, and the return).

If I'm wrong about the above assumptions, then I think your proposal is insufficiently ambitious.  

If I'm correct, then your proposal boils down to

(1)  Allow (require?) the function-level docstring to be defined somewhere else, possibly in another file.

(2)  Change the DSL
  (2a)  Get rid of function flags?  (Not sure this is workable)
  (2b)  Replace the (previously proposed) parameter declarations with literal C code forming an array of [parameter kind, array-of-setup-instructions-and-or-magically-named-variable-settings]


More flexibility in building the docstring is probably good.  

The other changes -- I'm not sure I see the advantage, except that it might simplify writing the thing as a C pre-processing macro.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:47:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:47:14 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1360777634.52.0.0392703382731.issue2175@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28954/sax_character_stream.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:47:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:47:52 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1360777672.65.0.157842857331.issue2175@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file29061/sax_character_stream.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:48:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:48:32 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1360777712.73.0.817024697069.issue2175@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file29062/sax_character_stream-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:50:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:50:59 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1360777859.05.0.85374820105.issue2175@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This patch is rather complicated and I doubt whether it is necessary to apply it to the older version. Can anyone review it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Wed Feb 13 18:52:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:52:22 +0000
Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...)
In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za>
Message-ID: <1360777942.62.0.270093134562.issue10590@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Expat sax parser silently ignores the InputSource protocol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10590>
_______________________________________

From report at bugs.python.org  Wed Feb 13 19:06:02 2013
From: report at bugs.python.org (Andrew McNabb)
Date: Wed, 13 Feb 2013 18:06:02 +0000
Subject: [issue14191] argparse doesn't allow optionals within positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1360778762.99.0.899917666657.issue14191@psf.upfronthosting.co.za>


Changes by Andrew McNabb <amcnabb at mcnabbs.org>:


----------
nosy: +amcnabb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14191>
_______________________________________

From report at bugs.python.org  Wed Feb 13 19:06:44 2013
From: report at bugs.python.org (Andrew McNabb)
Date: Wed, 13 Feb 2013 18:06:44 +0000
Subject: [issue15258] argparse documentation: Improve optparse section
	regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1360778804.86.0.335314448603.issue15258@psf.upfronthosting.co.za>


Changes by Andrew McNabb <amcnabb at mcnabbs.org>:


----------
nosy: +amcnabb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15258>
_______________________________________

From report at bugs.python.org  Wed Feb 13 19:41:20 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Wed, 13 Feb 2013 18:41:20 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1360780880.25.0.0533527524112.issue1285086@psf.upfronthosting.co.za>


Maciej Fijalkowski added the comment:

As per discussion on python-dev, this bug should probably be reopened and the patch maybe reverted as relying on the refcounting hack is both dodgy and hurts other implementations, like PyPy.

----------
nosy: +fijall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Wed Feb 13 19:48:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 18:48:08 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1360781288.56.0.652173632837.issue1285086@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Wed Feb 13 19:59:13 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 13 Feb 2013 18:59:13 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360781953.07.0.448127783494.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Chris,
  Thanks for the clarification.  I thought you were telling me my test cases were dry as in dry humor....I will read-up on the dry concept and see what I can do to consolidate plus I will combine the patches.  Initially I am thinking I could collapse all the test cases into two functions each for their respective operating system.  Would that be ok?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 20:09:53 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 19:09:53 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360782593.31.0.376244737265.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The number of test cases isn't the problem.  Having more but finer-grained test cases is usually preferred in fact.  It's just that the test cases should be sharing code where possible so that they're shorter and easy to see how they differ from one another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Wed Feb 13 20:25:26 2013
From: report at bugs.python.org (William Mallard)
Date: Wed, 13 Feb 2013 19:25:26 +0000
Subject: [issue17189] Add zip64 support to shutil
In-Reply-To: <1360646964.87.0.900673993367.issue17189@psf.upfronthosting.co.za>
Message-ID: <1360783526.33.0.218988486051.issue17189@psf.upfronthosting.co.za>


William Mallard added the comment:

Documentation added. See attached.

----------
Added file: http://bugs.python.org/file29063/shutil_zip64_by_default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17189>
_______________________________________

From report at bugs.python.org  Wed Feb 13 20:30:51 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 13 Feb 2013 19:30:51 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized
	preprocessor	into CPython trunk
In-Reply-To: <1360777391.34.0.975836306339.issue16612@psf.upfronthosting.co.za>
Message-ID: <20130213193053.GA522@sleipnir.bytereef.org>


Stefan Krah added the comment:

Jim Jewett <report at bugs.python.org> wrote:
> (1)  The first several lines ( "/* pymacro.h */" until "/* could go into a separate header file */" ) would not be written at all, and are just there to help reviewers understand.

Yes, they should ultimately go into Include/pymacro.h.

> (2)  The "#define OS_STAT_DOC ..." line is the docstring, and would be needed, but could easily go into a separate header file, like os_stat__doc.h.  For something like cdecimal, there might be only a single _cdecimal__doc.h containing all the docstrings.  There might even be a build switch that (at a minimum) replaced anything from those __doc.h files with "" for space-constrained builds.

Yes, it's supposed to be the main part of the docstring. The docstring header
containing the function signature would be autogenerated.

> (3)  The human-maintained code would be the DSL between "/*[preprocessor]" and "[preprocessor]*/".

Yes.

> (4)  The lines between "[preprocessor]*/" and "/*[preprocessor end:f3e6b328245207c240825782d908d3ff3a9c11c0]*/" would NOT be written or maintained by a human, but WOULD be checked into hg for the benefit builders without the argument-clinic tool.

Yes, all that code would be generated by clinic.py.

> (5)  The only C code written or maintained by a human (or another macro system) would be the last 5 lines (the system call, the path cleanup, and the return).

Correct.

> If I'm correct, then your proposal boils down to
> 
> (1)  Allow (require?) the function-level docstring to be defined somewhere else, possibly in another file.

Yes.

> (2)  Change the DSL
>   (2a)  Get rid of function flags?  (Not sure this is workable)

I didn't intend to but you're right, they were missing.

>   (2b)  Replace the (previously proposed) parameter declarations with literal C code forming an array of [parameter kind, array-of-setup-instructions-and-or-magically-named-variable-settings]

Regarding the DSL: I wanted to change the syntax, not the functionality.
Unfortunately, as Antoine pointed out, I didn't get it quite right.

(2b): Perhaps I misunderstand, but the snippets of literal C code are also
present in Larry's original:

/*[clinic]
os.stat -> stat result

    path_t path = PATH_T_INITIALIZE("stat", 0, 1);
    required
    converter=path_converter

    int dir_fd = DEFAULT_DIR_FD;
    default=None
    converter=OS_STAT_DIR_FD_CONVERTER
    keyword-only

    int follow_symlinks = 1;
    default=True
    types=bool
[clinic]*/

The motivation for trying to change the DSL is that I'd like to see
a) something that looks more like a C declaration, b) something that
is easily compressible vertically and c) some visual hints that
subdivide the declaration into sections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Wed Feb 13 22:04:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 21:04:37 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1360789477.31.0.674336219379.issue1285086@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patches not only get rid of the refcount hack, but make unquote() and unquote_to_bytes() even significant faster for large strings.

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file29064/urllib_faster_unquote.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Wed Feb 13 22:05:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 21:05:20 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1360789520.86.0.572593654365.issue1285086@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29065/urllib_faster_unquote-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Wed Feb 13 22:09:19 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 13 Feb 2013 21:09:19 +0000
Subject: [issue16743] mmap on Windows can mishandle files larger than
	sys.maxsize
In-Reply-To: <1356101011.63.0.640174538358.issue16743@psf.upfronthosting.co.za>
Message-ID: <1360789759.93.0.756045624567.issue16743@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16743>
_______________________________________

From report at bugs.python.org  Wed Feb 13 22:19:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Feb 2013 21:19:59 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1360790399.95.0.837700696191.issue17180@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Shouldn't you try to make the permission removal atomic? Otherwise there's a window of opportunity to exploit the suid bit.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Wed Feb 13 22:51:43 2013
From: report at bugs.python.org (William Mallard)
Date: Wed, 13 Feb 2013 21:51:43 +0000
Subject: [issue17201] Use allowZip64=True by default
In-Reply-To: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>
Message-ID: <1360792303.46.0.394952911622.issue17201@psf.upfronthosting.co.za>


William Mallard added the comment:

Enabling ZIP64 seems like a reasonable default.

The documentation justifies the current 32-bit default with outdated information:
"""
ZIP64 extensions are disabled by default because the default 'zip' and 'unzip' commands on Unix (the InfoZIP utilities) don't support these extensions.
"""

But InfoZIP has supported the ZIP64 extension for 4 years (since UnZip 6.0, and Zip 3.0).

----------
nosy: +william.mallard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Wed Feb 13 22:52:51 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 13 Feb 2013 21:52:51 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1360792371.22.0.0919510552579.issue2175@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fred at fdrake.net>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Wed Feb 13 23:20:00 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Wed, 13 Feb 2013 22:20:00 +0000
Subject: [issue16692] Support TLS 1.1 and TLS 1.2
In-Reply-To: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za>
Message-ID: <1360794000.0.0.374799736054.issue16692@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file29066/issue16692.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16692>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:13:36 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Feb 2013 23:13:36 +0000
Subject: [issue16692] Support TLS 1.1 and TLS 1.2
In-Reply-To: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za>
Message-ID: <1360797216.59.0.164330468422.issue16692@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16692>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:15:38 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Feb 2013 23:15:38 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360797338.59.0.830570427992.issue17179@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
title: TypeError: type() takes 1 or 3 arguments -> Incorrect use of type function in types.new_class
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:16:42 2013
From: report at bugs.python.org (Chris Withers)
Date: Wed, 13 Feb 2013 23:16:42 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360797402.8.0.339320185439.issue17179@psf.upfronthosting.co.za>


Chris Withers added the comment:

Eric, surely this is a bugfix candidate for 3.3.1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:17:42 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Feb 2013 23:17:42 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360797462.57.0.265701215619.issue17179@psf.upfronthosting.co.za>


?ric Araujo added the comment:

> I'm guessing ns and kwds should be combined before being passed through to meta?
Possibly; can you try that?

> surely this is a bugfix candidate for 3.3.1?
If we get a patch with a test in time, otherwise 3.3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:20:12 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Feb 2013 23:20:12 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1360797612.1.0.115264926329.issue17192@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Sound like a large change for stable releases.  Usually we would not do that.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:24:52 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Feb 2013 23:24:52 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <20130213193053.GA522@sleipnir.bytereef.org>
Message-ID: <CADiSq7fH-CvFr84vmCmob=UrBGK29QKqrKoAN8HoSazOzPkaxw@mail.gmail.com>


Nick Coghlan added the comment:

Stefan, would you be willing to write up your version as a PEP? (FWIW, I
personally favour your suggested C'ish style for the preprocessor, since my
brain would be in that mode anyway when hacking on C code)

----------
title: Integrate "Argument Clinic" specialized preprocessor	into CPython trunk -> Integrate "Argument Clinic" specialized preprocessor into CPython trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Thu Feb 14 00:58:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Feb 2013 23:58:01 +0000
Subject: [issue17198] dbm.whichdbm references non-existent 'ndbm'
In-Reply-To: <1360725498.06.0.499686664826.issue17198@psf.upfronthosting.co.za>
Message-ID: <1360799881.84.0.299560421596.issue17198@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17198>
_______________________________________

From report at bugs.python.org  Thu Feb 14 03:17:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 02:17:34 +0000
Subject: [issue15220] Reduce parsing overhead in
	email.feedparser.BufferedSubFile
In-Reply-To: <1340918364.55.0.874046229823.issue15220@psf.upfronthosting.co.za>
Message-ID: <1360808254.06.0.413807669656.issue15220@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15220>
_______________________________________

From report at bugs.python.org  Thu Feb 14 04:00:08 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 03:00:08 +0000
Subject: [issue17198] dbm.whichdbm references non-existent 'ndbm'
In-Reply-To: <1360725498.06.0.499686664826.issue17198@psf.upfronthosting.co.za>
Message-ID: <1360810808.43.0.121612075375.issue17198@psf.upfronthosting.co.za>


R. David Murray added the comment:

The code appears to be correct, but I think we need to add an explicit import for ndbm in the __init__ file.  Right now I think it is only passing the tests because the test infrastructure imports all the dbm modules, including ndbm.

(I did not realize that doing 'import X.abc' causes 'abc' to be defined in the X.__init__.py module's namespace, but of course it must once I thought about it.)

The tricky bit here is writing a test case :)

----------
nosy: +r.david.murray
stage: needs patch -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17198>
_______________________________________

From report at bugs.python.org  Thu Feb 14 04:06:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 03:06:55 +0000
Subject: [issue17198] dbm.whichdb references unitialized 'ndbm' variable
In-Reply-To: <1360725498.06.0.499686664826.issue17198@psf.upfronthosting.co.za>
Message-ID: <1360811215.24.0.731191751079.issue17198@psf.upfronthosting.co.za>


R. David Murray added the comment:

By the way, this will demonstrate the bug:

  touch foo.pag
  python -m dbm.__init__ foo

Perhaps that could be the basis for the test (using subprocess).

----------
stage:  -> needs patch
title: dbm.whichdbm references non-existent 'ndbm' -> dbm.whichdb references unitialized 'ndbm' variable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17198>
_______________________________________

From report at bugs.python.org  Thu Feb 14 04:10:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 03:10:45 +0000
Subject: [issue17198] dbm.whichdb references unitialized 'ndbm' variable
In-Reply-To: <1360725498.06.0.499686664826.issue17198@psf.upfronthosting.co.za>
Message-ID: <1360811445.25.0.0496040512552.issue17198@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, that test works only on 3.2/3.3, because by 3.4 the ndbm variable is only referenced in the second try; make it 'touch foo.db' instead for 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17198>
_______________________________________

From report at bugs.python.org  Thu Feb 14 04:21:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Feb 2013 03:21:04 +0000
Subject: [issue15220] Reduce parsing overhead in
	email.feedparser.BufferedSubFile
In-Reply-To: <1340918364.55.0.874046229823.issue15220@psf.upfronthosting.co.za>
Message-ID: <3Z62tl1VzCzRTD@mail.python.org>


Roundup Robot added the comment:

New changeset 0f827775f7b7 by R David Murray in branch 'default':
#15220: simplify and speed up feedparser's line splitting.
http://hg.python.org/cpython/rev/0f827775f7b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15220>
_______________________________________

From report at bugs.python.org  Thu Feb 14 04:50:15 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 14 Feb 2013 03:50:15 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360813815.59.0.0227633512248.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I've given this some more thought and quite a bit more work and reorganization. I think this clarifies the usage of memoryviews and buffers as well as the C-level API for each.

This is my first run at contributing a patch of any sort, so please let me know if there's anything further needed or any changes are required (or I'm just right out to lunch with this).

----------
Added file: http://bugs.python.org/file29067/buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17145>
_______________________________________

From report at bugs.python.org  Thu Feb 14 04:56:54 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Feb 2013 03:56:54 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1360814214.05.0.248227331823.issue9822@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I just stumbled across this issue in looking for another issue, and this turns out to be of interest to me as well.  As such, I've updated sorin's patch to apply to the current default branch, added the same kind of change to the new-since-then clean-amd64.bat, and fixed a bug in the initial patch to external-common.bat--it had been doing 'cd /D "%~dp0\.."' instead of "%~dp0\..\..\..".  It also looks like my editor stripped some trailing whitespace in a couple of files.

A much larger change that I made was to switch to using pushd/popd to make the initial dir change, and to return to the calling dir.  It strikes me as good practice not to change directory without warning simply by calling a batch file.  Alternately, things could be switched back to cd /D instead of pushd, and switch popd to "echo Leaving you in %CD%..." just to give some notice of the change.

I can't test whether the change would affect the buildbots, but it doesn't look like it should.  I have tested calling each file from several locations, including the root of the source tree, and everything seems to work as expected.

I will also be attaching a patch that also moves external*.bat into PCbuild as Martin suggested, as that does seem a more natural place for them.

----------
components: +Windows
nosy: +zach.ware
versions: +Python 3.4 -Python 3.2
Added file: http://bugs.python.org/file29068/issue9822.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Thu Feb 14 05:56:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Feb 2013 04:56:02 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360817762.4.0.28366937755.issue16278@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

"directory name.Yet a" needs spaces after '.'.

The text is decent English and clear enough sentence by sentence, but the reality and hence the text as a whole is confusing.

I wonder if it would be possible to make a little table

                    dest
                    ----   
Src     file         empty-dir    non-empty-dir
----    -----------------------------------------
file |            |            |

dir

with the behavior for each combination indicated, 'success' or 'OSError', with two lines prefixed with Unix, Win where they differ. Then the differences would be much more obvious.

(A separate issue: Patch says that Windows currently raises a different error in one situation. I think it would be better -- in a future version -- if that were caught and reraised as OSError also.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Thu Feb 14 06:29:38 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Feb 2013 05:29:38 +0000
Subject: [issue9822] windows batch files are dependent on cmd current directory
In-Reply-To: <1284118620.1.0.910652087288.issue9822@psf.upfronthosting.co.za>
Message-ID: <1360819778.27.0.548642465383.issue9822@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's the patch that moves external*.bat into PCbuild.  I also took the opportunity to give the three files more descriptive names: external.bat -> get_externals.bat, external-common.bat -> get_common_externals.bat, and external-amd64.bat -> get_externals-amd64.bat.  I'm pretty sure I got all references to them; I know I got everything in PCbuild\readme.txt and in the Tools\buildbot scripts.

As an aside, it seems like my last message caused my avast! to freak out about and refuse to load this page, calling it an HTML:Script-inf virus.  My apologies if anyone else is similarly affected.

----------
Added file: http://bugs.python.org/file29069/issue9822.v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9822>
_______________________________________

From report at bugs.python.org  Thu Feb 14 07:11:14 2013
From: report at bugs.python.org (Reuben D'Netto)
Date: Thu, 14 Feb 2013 06:11:14 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>
Message-ID: <1360822274.17.0.854461765928.issue17200@psf.upfronthosting.co.za>


Reuben D'Netto added the comment:

Sure, no problem. I'll upload the completed patch once I've got it working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Thu Feb 14 07:41:27 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Feb 2013 06:41:27 +0000
Subject: [issue17202] Add .bat line to .hgeol
Message-ID: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Most times (though not all, for some reason) I try to use Doc\make.bat update, it fails with "The system cannot find the batch label specified - update" even though it is obviously there.  The reason for this appears to be the fact that the file uses UNIX line endings[1].  As a fix, I think it would make the most sense to add a "**.bat = CRLF" line to .hgeol.

The attached patch makes that change and includes the changes that that change entails.  The complete list of affected files is as follows:

Doc\make.bat
Lib\ctypes\macholib\fetch_macholib.bat
Lib\idlelib\idle.bat
Modules\_decimal\tests\runall.bat
PCbuild\build.bat
PCbuild\build_env.bat
PCbuild\build_pgo.bat
PCbuild\build_ssl.bat
PCbuild\env.bat
PCbuild\idle.bat
PCbuild\rt.bat
Tools\buildbot\build-amd64.bat
Tools\buildbot\build.bat
Tools\buildbot\buildmsi.bat
Tools\buildbot\clean-amd64.bat
Tools\buildbot\clean.bat
Tools\buildbot\external-amd64.bat
Tools\buildbot\external-common.bat
Tools\buildbot\external.bat
Tools\buildbot\test-amd64.bat
Tools\buildbot\test.bat
Tools\unicode\genwincodecs.bat

As far as I know, there is no reason to believe that the changes to line endings in these files would cause any change to behavior other than possibly avoid strange and random bugs in their execution, particularly in Doc\make.bat.

If we don't want to a blanket rule like this, I think we should at least add a rule for Doc\make.bat to convert it to CRLF line endings to avoid the bug with :update.

Thanks,

Zach

[1] http://stackoverflow.com/questions/232651/why-the-system-cannot-find-the-batch-label-specified-is-thrown-even-if-label-e/232674#232674

----------
components: Windows
files: batch_eol_fix.diff
keywords: patch
messages: 182077
nosy: brian.curtin, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add .bat line to .hgeol
versions: Python 3.4
Added file: http://bugs.python.org/file29070/batch_eol_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17202>
_______________________________________

From report at bugs.python.org  Thu Feb 14 07:47:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 14 Feb 2013 06:47:08 +0000
Subject: [issue17203] add long option names to unittest discovery docs
Message-ID: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, unittest's discovery command-line documentation:

http://docs.python.org/dev/library/unittest.html#test-discovery

does not include the long option names (--start-directory, --pattern, and --top-level-directory):

http://hg.python.org/cpython/file/0f827775f7b7/Lib/unittest/main.py#l215

This issue is to add those.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 182078
nosy: chris.jerdonek, docs at python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: add long option names to unittest discovery docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17203>
_______________________________________

From senthil at uthcode.com  Thu Feb 14 07:51:37 2013
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 13 Feb 2013 22:51:37 -0800
Subject: [issue1285086] urllib.quote is too slow
In-Reply-To: <1360789520.86.0.572593654365.issue1285086@psf.upfronthosting.co.za>
References: <1360789520.86.0.572593654365.issue1285086@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT_-87A7O9rhUnxHFfZqEEABsgrfJ-Csj+kkc5uKXyu1w@mail.gmail.com>

Applying this patch - I tried this hypothetical test.

$ ./python.exe -m timeit -s "import urllib.parse; x='a%20' * 100000"
"urllib.parse.unquote(x)"
10 loops, best of 3: 205 msec per loop

Without the patch, the above test will run for minutes!

This creates a significant difference for extremely long query
strings. For small strings the performance is negligible.

Serhiy: One question. Is there a need to have  -

+ append = res.append

And then use 'append'? res.append is easier for readability IMO.
Besides that I dont have any other comments. Maciej's comment could be
sought as he (correctly) brought up this issue.

From report at bugs.python.org  Thu Feb 14 07:51:40 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Feb 2013 06:51:40 +0000
Subject: [issue1285086] urllib.quote is too slow
In-Reply-To: <1360789520.86.0.572593654365.issue1285086@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT_-87A7O9rhUnxHFfZqEEABsgrfJ-Csj+kkc5uKXyu1w@mail.gmail.com>


Senthil Kumaran added the comment:

Applying this patch - I tried this hypothetical test.

$ ./python.exe -m timeit -s "import urllib.parse; x='a%20' * 100000"
"urllib.parse.unquote(x)"
10 loops, best of 3: 205 msec per loop

Without the patch, the above test will run for minutes!

This creates a significant difference for extremely long query
strings. For small strings the performance is negligible.

Serhiy: One question. Is there a need to have  -

+ append = res.append

And then use 'append'? res.append is easier for readability IMO.
Besides that I dont have any other comments. Maciej's comment could be
sought as he (correctly) brought up this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Thu Feb 14 08:00:12 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Feb 2013 07:00:12 +0000
Subject: [issue1285086] urllib.quote is too slow
In-Reply-To: <CAPOVWOT_-87A7O9rhUnxHFfZqEEABsgrfJ-Csj+kkc5uKXyu1w@mail.gmail.com>
Message-ID: <CAPOVWOTO=oir_-Ew6tCwMhjdahLrOtPoXHG0ZvMFL6tx97Wzjg@mail.gmail.com>


Senthil Kumaran added the comment:

I wrongly minutes. Here is actual data of execution speeds.  There is
magnitude of difference (almost 130x faster). Measured on  macbook pro
with 2 cores and 4 Gig mem.

Before Patch:

$ ./python.exe -m timeit -s "import urllib.parse; x='a%20' * 100000"
"urllib.parse.unquote(x)"
10 loops, best of 3: 26.8 sec per loop

After Patch:

$ ./python.exe -m timeit -s "import urllib.parse; x='a%20' * 100000"
"urllib.parse.unquote(x)"
10 loops, best of 3: 205 msec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Thu Feb 14 08:01:07 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 14 Feb 2013 07:01:07 +0000
Subject: [issue17204] argparser's subparsers.add_parser() should accept an
	ArgumentParser
Message-ID: <1360825267.06.0.240295052102.issue17204@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, argparser's subparsers.add_parser() method (for adding sub-commands) takes the following input:

"This object has a single method, add_parser(), which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual."

(from http://docs.python.org/dev/library/argparse.html#argparse.ArgumentParser.add_subparsers )

It would be nice if one could also pass an ArgumentParser object to add_parser().  This would allow the composition of parsers.  For example, if a library exposed an ArgumentParser command-line API, one could expose that library's commands as a sub-command of the parent project's command-line API using add_parser().

----------
components: Library (Lib)
messages: 182081
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: argparser's subparsers.add_parser() should accept an ArgumentParser
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17204>
_______________________________________

From report at bugs.python.org  Thu Feb 14 10:15:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 09:15:27 +0000
Subject: [issue4591] 32-bits unsigned user/group identifier
In-Reply-To: <1228738930.96.0.415999724625.issue4591@psf.upfronthosting.co.za>
Message-ID: <1360833327.05.0.462448418721.issue4591@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4591>
_______________________________________

From report at bugs.python.org  Thu Feb 14 10:19:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 09:19:17 +0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1360833557.97.0.719361951332.issue2005@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Auxiliary conversion functions for uid_t and gid_t was added in issue4591. They are supports unsigned types not larger than unsigned long.

If someone need the support of the platform with signed uid_t/gid_t or with uid_t/gid_t larger than long (I don't know such modern platforms), here's the patch.

----------
dependencies: +32-bits unsigned user/group identifier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
_______________________________________

From report at bugs.python.org  Thu Feb 14 10:19:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 09:19:52 +0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1360833592.64.0.290871923238.issue2005@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file29071/posix_uid_gid_conv_signed_long_long.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
_______________________________________

From report at bugs.python.org  Thu Feb 14 10:21:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 09:21:10 +0000
Subject: [issue15528] Better support for finalization with weakrefs
In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za>
Message-ID: <1360833670.72.0.898869325576.issue15528@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Richard, do you still want to push this forward? Otherwise I'd like to finalize the patch (in the other sense ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________

From report at bugs.python.org  Thu Feb 14 10:33:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 09:33:14 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1360834394.46.0.1696343854.issue16612@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I agree with Stefan that the file is a lot more readable if the 
> docstring
> is not repeated twice.

Couldn't the generated C docstring end up in a separate file? It's only a 
constant after all.
It seems to me that one reason we don't give much love to C docstrings is
that they're painful to edit, compared to Python docstrings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Thu Feb 14 11:51:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 10:51:02 +0000
Subject: [issue7365] grp and pwd should treat uid and gid as unsigned
In-Reply-To: <1258680245.88.0.627899346962.issue7365@psf.upfronthosting.co.za>
Message-ID: <1360839062.43.0.989311769969.issue7365@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed by patch for issue4591.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> 32-bits unsigned user/group identifier

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7365>
_______________________________________

From report at bugs.python.org  Thu Feb 14 11:56:30 2013
From: report at bugs.python.org (py.user)
Date: Thu, 14 Feb 2013 10:56:30 +0000
Subject: [issue17205] In the help() function the order of methods changes
Message-ID: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>


New submission from py.user:

>>> class A:
...   '''class'''
...   def c(self):
...     '''c doc'''
...     pass
...   def b(self):
...     '''b doc'''
...     pass
...   def a(self):
...     '''a doc'''
...     pass
... 
>>> help(A)

class A(builtins.object)
 |  class
 |  
 |  Methods defined here:
 |  
 |  a(self)
 |      a doc
 |  
 |  b(self)
 |      b doc
 |  
 |  c(self)
 |      c doc
 |  
 

When I have many methods ordered in the source in readable order, the help() function is mixing them, so the last method goes to the top and the first method goes to the bottom.

I would like to have an option, whether I want sort them or not.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 182086
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the help() function the order of methods changes
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17205>
_______________________________________

From report at bugs.python.org  Thu Feb 14 12:24:29 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 14 Feb 2013 11:24:29 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1360841069.43.0.88245813484.issue16043@psf.upfronthosting.co.za>


Christian Heimes added the comment:

IMHO the patch should also limit the maximum amount of read bytes in Transport.parse_response(). Do you agree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Thu Feb 14 12:24:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 11:24:36 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1360841076.69.0.804572771324.issue15301@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Similar test was committed for issue4591 and it fixes this issue. There are only two differences with Larry's patch: tests and handling of non-integers.

Here is a patch based on Larry's patch which extends tests for *chown().

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file29072/posix_uid_gid_conv_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Feb 14 12:33:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 11:33:08 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1360841588.84.0.0136694138472.issue15301@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And here is a patch which uses __index__ for uid and gid conversion. decimal.Decimal should be added to the list of wrong types in the test.

I'm not sure about the last patch, whether to consider it as a bugfix or as a new feature?

----------
nosy: +skrah
versions: +Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29073/posix_uid_gid_conv_index.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Thu Feb 14 12:52:37 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Feb 2013 11:52:37 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1360842757.64.0.903298813407.issue12641@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

doko: this issue is about Windows; autoconf is not being used here (plus the "correct" compiler would be MSC).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Feb 14 12:59:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 11:59:35 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1360843175.41.0.890866615789.issue1285086@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Serhiy: One question. Is there a need to have  -
>
> + append = res.append
>
> And then use 'append'?

This speed up unquote_to_bytes by 15%.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Thu Feb 14 13:01:34 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 14 Feb 2013 12:01:34 +0000
Subject: [issue15528] Better support for finalization with weakrefs
In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za>
Message-ID: <1360843294.57.0.582575816572.issue15528@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Richard, do you still want to push this forward? Otherwise I'd like to 
> finalize the patch (in the other sense ;-).

I started to worry a bit about daemon threads.  I think they can still run while atexit functions are being run.*  So if a daemon thread creates an atexit finalizer during shutdown it may never be run.

I am not sure how much to worry about this potential race.  Maybe a lock could be used to cause any daemon threads which try to create finalizers to block.

* Is it necessary/desirable to allow daemon threads to run during shutdown.  Maybe blocking thread switching at shutdown could cause deadlocks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________

From report at bugs.python.org  Thu Feb 14 13:10:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 12:10:37 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1360843837.1.0.632073165316.issue16043@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think instead of global variable it will be better to add an optional parameter for gzip_decode() (with a sane default value) and related functions. Or at least in additional to it.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Thu Feb 14 13:39:28 2013
From: report at bugs.python.org (Todd Rovito)
Date: Thu, 14 Feb 2013 12:39:28 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1360817762.4.0.28366937755.issue16278@psf.upfronthosting.co.za>
Message-ID: <C26B99FA-F178-4C9B-B375-AAF604B00D2C@gmail.com>


Todd Rovito added the comment:

Thanks Terry and Chris you guys have supplied great feedback.  I will work on the issue and try to get a new patch updated by end of the weekend (2/18/13).

Sent from my iPhone

On Feb 13, 2013, at 11:56 PM, "Terry J. Reedy" <report at bugs.python.org> wrote:

> 
> Terry J. Reedy added the comment:
> 
> "directory name.Yet a" needs spaces after '.'.
> 
> The text is decent English and clear enough sentence by sentence, but the reality and hence the text as a whole is confusing.
> 
> I wonder if it would be possible to make a little table
> 
>                    dest
>                    ----   
> Src     file         empty-dir    non-empty-dir
> ----    -----------------------------------------
> file |            |            |
> 
> dir
> 
> with the behavior for each combination indicated, 'success' or 'OSError', with two lines prefixed with Unix, Win where they differ. Then the differences would be much more obvious.
> 
> (A separate issue: Patch says that Windows currently raises a different error in one situation. I think it would be better -- in a future version -- if that were caught and reraised as OSError also.)
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16278>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Thu Feb 14 14:30:24 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 14 Feb 2013 13:30:24 +0000
Subject: [issue17205] In the help() function the order of methods changes
In-Reply-To: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>
Message-ID: <1360848624.38.0.641593769612.issue17205@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Sorry, but there is no way of telling the order as methods are respresented internally as a dictionary. Please close this as invalid.

----------
nosy: +ramchandra.apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17205>
_______________________________________

From report at bugs.python.org  Thu Feb 14 14:32:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 13:32:25 +0000
Subject: [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1360848745.66.0.802072094268.issue17135@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +brett.cannon
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17135>
_______________________________________

From report at bugs.python.org  Thu Feb 14 14:33:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 13:33:09 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360848789.31.0.603307913299.issue17143@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/issue17143>
_______________________________________

From report at bugs.python.org  Thu Feb 14 14:36:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 13:36:13 +0000
Subject: [issue17160] test_urllib2net fails
In-Reply-To: <1360341954.01.0.966595141063.issue17160@psf.upfronthosting.co.za>
Message-ID: <1360848973.42.0.645110116407.issue17160@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #16969.

----------
nosy: +ezio.melotti
resolution: out of date -> duplicate
superseder:  -> test_urlwithfrag fail
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17160>
_______________________________________

From report at bugs.python.org  Thu Feb 14 15:10:12 2013
From: report at bugs.python.org (Ronald Chapman)
Date: Thu, 14 Feb 2013 14:10:12 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360851012.97.0.777214350643.issue17143@psf.upfronthosting.co.za>


Ronald Chapman added the comment:

Islamabad l guythen vkd dudziozl

----------
hgrepos: +174
nosy: +Ronald.Chapman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Thu Feb 14 15:19:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 14:19:10 +0000
Subject: [issue17103] ampersand "&" in path prevents compilation of Python
In-Reply-To: <1359796958.56.0.232245529308.issue17103@psf.upfronthosting.co.za>
Message-ID: <1360851550.11.0.0842422920219.issue17103@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17103>
_______________________________________

From report at bugs.python.org  Thu Feb 14 15:29:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 14:29:42 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360852182.4.0.612907893761.issue17143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg182097

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Thu Feb 14 15:29:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 14:29:49 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360852189.67.0.470852225514.issue17143@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
hgrepos:  -174

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Thu Feb 14 15:33:30 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Feb 2013 14:33:30 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360852410.02.0.377020387758.issue17143@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy:  -Ronald.Chapman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:13:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 15:13:33 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360854813.43.0.304995031715.issue17143@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Eric, do you want to commit?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:16:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 15:16:59 +0000
Subject: [issue15528] Better support for finalization with weakrefs
In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za>
Message-ID: <1360855019.73.0.649251419156.issue15528@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Is it necessary/desirable to allow daemon threads to run during
> shutdown.  Maybe blocking thread switching at shutdown could cause
> deadlocks?

Mmmh... thread switching is already blocked at shutdown:
http://hg.python.org/cpython/file/0f827775f7b7/Python/ceval.c#l434

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:18:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 15:18:29 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360855109.88.0.0298819493008.issue17179@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:19:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 15:19:04 +0000
Subject: [issue17201] Use allowZip64=True by default
In-Reply-To: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>
Message-ID: <1360855144.84.0.174965136682.issue17201@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

+1. Let's make it for 3.4.

----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:42:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 15:42:21 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1360856541.24.0.318256686304.issue13461@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Can we fix this easy issue before 2.7.4 release?

----------
keywords: +easy
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:44:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 15:44:37 +0000
Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za>
Message-ID: <1360856677.73.0.565703956771.issue13461@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ageed, it's probably easy enough.

----------
stage:  -> needs patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13461>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:45:23 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 14 Feb 2013 15:45:23 +0000
Subject: [issue15528] Better support for finalization with weakrefs
In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za>
Message-ID: <1360856723.59.0.56869913329.issue15528@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

On 14/02/2013 3:16pm, Antoine Pitrou wrote:
> Mmmh... thread switching is already blocked at shutdown:
> http://hg.python.org/cpython/file/0f827775f7b7/Python/ceval.c#l434

But in Py_Finalize(), call_py_exitfuncs() is called *before* _Py_Finalizing is set to a non-NULL value.

    http://hg.python.org/cpython/file/0f827775f7b7/Python/pythonrun.c#l492

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________

From report at bugs.python.org  Thu Feb 14 16:49:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 15:49:47 +0000
Subject: [issue11048] "import ctypes" causes segfault on read-only filesystem
In-Reply-To: <1296234309.62.0.290829997988.issue11048@psf.upfronthosting.co.za>
Message-ID: <1360856987.44.0.0102798912415.issue11048@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> test needed
versions: +Python 3.4 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11048>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:01:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 16:01:41 +0000
Subject: [issue11837] smtplib._quote_periods triggers spurious type error in
	re.sub
In-Reply-To: <1302628161.84.0.82021620589.issue11837@psf.upfronthosting.co.za>
Message-ID: <1360857701.37.0.823361593662.issue11837@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already fixed in issue12283.

----------
components: +email
nosy: +barry, r.david.murray, serhiy.storchaka
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> python3.2 smtplib _quote_periods
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11837>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:06:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 16:06:34 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360857994.33.0.937943936063.issue13153@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:07:37 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Feb 2013 16:07:37 +0000
Subject: [issue17206] Py_XDECREF() expands its argument multiple times
Message-ID: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

When running my refcount static analyzer [1] on a large corpus of real-world C extension code for Python, I ran into the following construct in various places:

    Py_XDECREF(PyObject_CallObject(callable, args));

This is bogus code: Py_XDECREF expands its argument multiple times, so after this goes through the C preprocessor the callable is actually called invoked up to 4 times, leaking refs to 3 of the results - assuming that none of the calls fail, and a non pydebug build of CPython (which would expand the argument more times).

The raw preprocessor output for an optimized Python 2.7 looks like this:
   do { if ((PyObject_CallObject(callable, args)) == ((void *)0)) ; else do { if ( --((PyObject*)(PyObject_CallObject(callable, args)))->ob_refcnt != 0) ; else ( (*(((PyObject*)((PyObject *)(PyObject_CallObject(callable, args))))->ob_type)->tp_dealloc)((PyObject *)((PyObject *)(PyObject_CallObject(callable, args))))); } while (0); } while (0);

Cleaned up (and removing some of the casts for clarity) it looks like this:
  do { 
    if ((PyObject_CallObject(callable, args)) == ((void *)0))
      ; 
    else 
      do {
        if (--(PyObject_CallObject(callable, args)->ob_refcnt) != 0)
          ;
        else
          (*(PyObject_CallObject(callable, args)->ob_type)->tp_dealloc)
            PyObject_CallObject(callable, args);
      } while (0);
  } while (0);
which is clearly not what the extension author was expecting.

Should we:
  (A) update the macro so that it expands its argument only once, or
  (B) warn people not to write code like the above?

Similar considerations apply to the other macros, I guess, but I've seen the above used "in the wild", I haven't yet seen it for the other macros).

Seen in the wild in:
  python-alsa-1.0.25-1.fc17:
      pyalsa/alsamixer.c:179
    00174 | 	for (i = 0; i < count; i++) { 
    00175 | 		t = PyTuple_New(2); 
    00176 | 		if (t) { 
    00177 | 			PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd)); 
    00178 | 			PyTuple_SET_ITEM(t, 1, PyInt_FromLong(pfd[i].events)); 
    00179>| 			Py_XDECREF(PyObject_CallObject(reg, t)); 
    00180 | 			Py_DECREF(t); 
    00181 | 		} 
    00182 | 	}	 
    00183 |  
    00184 | 	Py_XDECREF(reg); 

      pyalsa/alsahcontrol.c:190
    00185 | 	for (i = 0; i < count; i++) { 
    00186 | 		t = PyTuple_New(2); 
    00187 | 		if (t) { 
    00188 | 			PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd)); 
    00189 | 			PyTuple_SET_ITEM(t, 1, PyInt_FromLong(pfd[i].events)); 
    00190>| 			Py_XDECREF(PyObject_CallObject(reg, t)); 
    00191 | 			Py_DECREF(t); 
    00192 | 		} 
    00193 | 	}	 
    00194 |  
    00195 | 	Py_XDECREF(reg); 

      pyalsa/alsaseq.c:3277
    03272 |     for (i = 0; i < count; i++) { 
    03273 |         t = PyTuple_New(2); 
    03274 |         if (t) { 
    03275 |             PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd)); 
    03276 |             PyTuple_SET_ITEM(t, 1, PyInt_FromLong(pfd[i].events)); 
    03277>|             Py_XDECREF(PyObject_CallObject(reg, t)); 
    03278 |             Py_DECREF(t); 
    03279 |         } 
    03280 |     } 
    03281 |  
    03282 |     Py_XDECREF(reg); 

 python-4Suite-XML-1.0.2-14.fc17:
      Ft/Xml/src/domlette/refcounts.c:80
    00075 |     /* refcount = this */ 
    00076 |     expected = 1; 
    00077 |   } 
    00078 |   else { 
    00079 |     sprintf(buf, "Unexpected object type '%.200s'" ,node->ob_type->tp_name); 
    00080>|     Py_XDECREF(PyObject_CallMethod(tester, "error", "s", buf)); 
    00081 |     return 0; 
    00082 |   } 
    00083 |  
    00084 |   sprintf(buf, "%.200s refcounts", node->ob_type->tp_name); 
    00085 |   return do_test(tester, buf, expected, node->ob_refcnt); 


[Note to self: I actually saw this because it uncovered a traceback in cpychecker, which I fixed as:
http://git.fedorahosted.org/cgit/gcc-python-plugin.git/commit/?id=99fa820487e380b74c2eda1d97facdf2ee6d2f3a ]


[1] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html

----------
components: Interpreter Core
messages: 182107
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Py_XDECREF() expands its argument multiple times
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17206>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:11:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 16:11:01 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1360858261.74.0.648138369655.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

FreeBSD 6.4 and Windows test failures was fixed in changesets 8fb98fb758e8 and ec70abe8c886.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:14:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 16:14:56 +0000
Subject: [issue17205] In the help() function the order of methods changes
In-Reply-To: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>
Message-ID: <1360858496.16.0.797771874789.issue17205@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ramchandra is correct.  If you were to implement a "don't sort" flag, what you would get is *random* order (and a different order each time, in 3.3+).

Further, this is Python-interpreter internal data structure we are talking about, so it isn't even an option to use OrderedDict in pydoc.

I'm closing this as "won't fix" because it would certainly be nice to have this ability...but there is no practical way to implement it.

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17205>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:16:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 16:16:05 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1360858565.46.0.524054512811.issue6083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I shouldn't close this until this dangerous feature will be deprecated.

----------
assignee: serhiy.storchaka -> 
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:32:30 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Feb 2013 16:32:30 +0000
Subject: [issue17206] Py_XDECREF() expands its argument multiple times
In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W5b2=rraqasTj4tFjfdHRog_DCkHN4iya9p9g04HQS+1g@mail.gmail.com>


Brett Cannon added the comment:

On Thu, Feb 14, 2013 at 11:07 AM, Dave Malcolm <report at bugs.python.org>wrote:

>
> New submission from Dave Malcolm:
>
> When running my refcount static analyzer [1] on a large corpus of
> real-world C extension code for Python, I ran into the following construct
> in various places:
>
>     Py_XDECREF(PyObject_CallObject(callable, args));
>

Eww.

>
> This is bogus code: Py_XDECREF expands its argument multiple times, so
> after this goes through the C preprocessor the callable is actually called
> invoked up to 4 times, leaking refs to 3 of the results - assuming that
> none of the calls fail, and a non pydebug build of CPython (which would
> expand the argument more times).
>
> The raw preprocessor output for an optimized Python 2.7 looks like this:
>    do { if ((PyObject_CallObject(callable, args)) == ((void *)0)) ; else
> do { if ( --((PyObject*)(PyObject_CallObject(callable, args)))->ob_refcnt
> != 0) ; else ( (*(((PyObject*)((PyObject *)(PyObject_CallObject(callable,
> args))))->ob_type)->tp_dealloc)((PyObject *)((PyObject
> *)(PyObject_CallObject(callable, args))))); } while (0); } while (0);
>
> Cleaned up (and removing some of the casts for clarity) it looks like this:
>   do {
>     if ((PyObject_CallObject(callable, args)) == ((void *)0))
>       ;
>     else
>       do {
>         if (--(PyObject_CallObject(callable, args)->ob_refcnt) != 0)
>           ;
>         else
>           (*(PyObject_CallObject(callable, args)->ob_type)->tp_dealloc)
>             PyObject_CallObject(callable, args);
>       } while (0);
>   } while (0);
> which is clearly not what the extension author was expecting.
>
> Should we:
>   (A) update the macro so that it expands its argument only once, or
>

How expensive is that going to be? Since there is a 'do' statement using a
temp variable would be easy to introduce, but is a compiler going to be
smart enough to inline it all so it doesn't have to waste an allocation,
etc.?

>   (B) warn people not to write code like the above?
>

Only if (A) is too costly. I would modify a checkout for ALL refcount
macros and run the benchmark suite to see if there is a noticeable
difference. If there isn't then I say change all the macros (can't make one
safe and the rest not as that is just asking for inconsistent usage and
trouble).

-Brett

>
> Similar considerations apply to the other macros, I guess, but I've seen
> the above used "in the wild", I haven't yet seen it for the other macros).
>
> Seen in the wild in:
>   python-alsa-1.0.25-1.fc17:
>       pyalsa/alsamixer.c:179
>     00174 |     for (i = 0; i < count; i++) {
>     00175 |             t = PyTuple_New(2);
>     00176 |             if (t) {
>     00177 |                     PyTuple_SET_ITEM(t, 0,
> PyInt_FromLong(pfd[i].fd));
>     00178 |                     PyTuple_SET_ITEM(t, 1,
> PyInt_FromLong(pfd[i].events));
>     00179>|                     Py_XDECREF(PyObject_CallObject(reg, t));
>     00180 |                     Py_DECREF(t);
>     00181 |             }
>     00182 |     }
>     00183 |
>     00184 |     Py_XDECREF(reg);
>
>       pyalsa/alsahcontrol.c:190
>     00185 |     for (i = 0; i < count; i++) {
>     00186 |             t = PyTuple_New(2);
>     00187 |             if (t) {
>     00188 |                     PyTuple_SET_ITEM(t, 0,
> PyInt_FromLong(pfd[i].fd));
>     00189 |                     PyTuple_SET_ITEM(t, 1,
> PyInt_FromLong(pfd[i].events));
>     00190>|                     Py_XDECREF(PyObject_CallObject(reg, t));
>     00191 |                     Py_DECREF(t);
>     00192 |             }
>     00193 |     }
>     00194 |
>     00195 |     Py_XDECREF(reg);
>
>       pyalsa/alsaseq.c:3277
>     03272 |     for (i = 0; i < count; i++) {
>     03273 |         t = PyTuple_New(2);
>     03274 |         if (t) {
>     03275 |             PyTuple_SET_ITEM(t, 0, PyInt_FromLong(pfd[i].fd));
>     03276 |             PyTuple_SET_ITEM(t, 1,
> PyInt_FromLong(pfd[i].events));
>     03277>|             Py_XDECREF(PyObject_CallObject(reg, t));
>     03278 |             Py_DECREF(t);
>     03279 |         }
>     03280 |     }
>     03281 |
>     03282 |     Py_XDECREF(reg);
>
>  python-4Suite-XML-1.0.2-14.fc17:
>       Ft/Xml/src/domlette/refcounts.c:80
>     00075 |     /* refcount = this */
>     00076 |     expected = 1;
>     00077 |   }
>     00078 |   else {
>     00079 |     sprintf(buf, "Unexpected object type '%.200s'"
> ,node->ob_type->tp_name);
>     00080>|     Py_XDECREF(PyObject_CallMethod(tester, "error", "s", buf));
>     00081 |     return 0;
>     00082 |   }
>     00083 |
>     00084 |   sprintf(buf, "%.200s refcounts", node->ob_type->tp_name);
>     00085 |   return do_test(tester, buf, expected, node->ob_refcnt);
>
>
> [Note to self: I actually saw this because it uncovered a traceback in
> cpychecker, which I fixed as:
>
> http://git.fedorahosted.org/cgit/gcc-python-plugin.git/commit/?id=99fa820487e380b74c2eda1d97facdf2ee6d2f3a]
>
>
> [1] https://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html
>
> ----------
> components: Interpreter Core
> messages: 182107
> nosy: dmalcolm
> priority: normal
> severity: normal
> status: open
> title: Py_XDECREF() expands its argument multiple times
> versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4,
> Python 3.5
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17206>
> _______________________________________
> _______________________________________________
> New-bugs-announce mailing list
> New-bugs-announce at python.org
> http://mail.python.org/mailman/listinfo/new-bugs-announce
>

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17206>
_______________________________________

From report at bugs.python.org  Thu Feb 14 17:57:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 16:57:30 +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: <1360861050.52.0.0430293812421.issue7145@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Won't fix?

----------
nosy: +serhiy.storchaka
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________

From report at bugs.python.org  Thu Feb 14 18:57:35 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 14 Feb 2013 17:57:35 +0000
Subject: [issue16246] Multiprocessing infinite loop on Windows
In-Reply-To: <1350389817.55.0.995425148307.issue16246@psf.upfronthosting.co.za>
Message-ID: <1360864655.06.0.554267158093.issue16246@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16246>
_______________________________________

From report at bugs.python.org  Thu Feb 14 18:58:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 17:58:51 +0000
Subject: [issue5202] wave.py cannot write wave files into a shell pipeline
In-Reply-To: <1234266301.49.0.830035453307.issue5202@psf.upfronthosting.co.za>
Message-ID: <1360864731.28.0.244384514528.issue5202@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Now, is there some problem if we remove the calls to the "tell" method
> in _write_header ? See patch attached (tests are very welcome too).

Yes, there is a problem. User can pass already open file to wave.open() and file position can be not 0 at the start of the WAVE file. But you can do with only one tell(). Note a magic number 36 in many places of the code. This is struct.calcsize(wave_header_format).

Test is needed as well as a documentation change.

I think this is rather a new feature and should be added only in 3.4. Actually the current behavior is documented: "If *file* is a string, open the file by that name, otherwise treat it as a seekable file-like object."

----------
nosy: +serhiy.storchaka
stage: patch review -> needs patch
type: behavior -> enhancement
versions: +Python 3.4 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5202>
_______________________________________

From report at bugs.python.org  Thu Feb 14 19:05:50 2013
From: report at bugs.python.org (William Mallard)
Date: Thu, 14 Feb 2013 18:05:50 +0000
Subject: [issue17201] Use allowZip64=True by default
In-Reply-To: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>
Message-ID: <1360865150.78.0.708257446039.issue17201@psf.upfronthosting.co.za>


William Mallard added the comment:

See attached. The patch updates ZipFile, its documentation, and its unit tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file29074/zipfile_zip64_by_default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Thu Feb 14 19:31:03 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Feb 2013 18:31:03 +0000
Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1360866663.75.0.347792269151.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ping!

If there are no objections, would anyone mind committing this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16893>
_______________________________________

From report at bugs.python.org  Thu Feb 14 20:07:53 2013
From: report at bugs.python.org (William Mallard)
Date: Thu, 14 Feb 2013 19:07:53 +0000
Subject: [issue17201] Use allowZip64=True by default
In-Reply-To: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>
Message-ID: <1360868873.31.0.457404546559.issue17201@psf.upfronthosting.co.za>


Changes by William Mallard <wjm at llard.net>:


Added file: http://bugs.python.org/file29075/zipfile_zip64_by_default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Thu Feb 14 20:09:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 19:09:19 +0000
Subject: [issue11397] os.path.realpath() may produce incorrect results
In-Reply-To: <1299259038.05.0.675723191983.issue11397@psf.upfronthosting.co.za>
Message-ID: <1360868959.11.0.992447424268.issue11397@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already fixed in issue6975.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11397>
_______________________________________

From report at bugs.python.org  Thu Feb 14 20:16:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 19:16:10 +0000
Subject: [issue14515] tempfile.TemporaryDirectory documented as returning
	object but returns name
In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za>
Message-ID: <1360869370.97.0.0146498373754.issue14515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't understand a phrase "and is assigned to the target of the as clause on entry to a context". Typo?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14515>
_______________________________________

From report at bugs.python.org  Thu Feb 14 20:26:33 2013
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 14 Feb 2013 19:26:33 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360869993.07.0.851231438144.issue17179@psf.upfronthosting.co.za>


Daniel Urban added the comment:

I don't think this is a bug:

>>> from datetime import datetime
>>> class tdatetime(datetime, foo='bar'):
...     pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments
>>>

----------
nosy: +daniel.urban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Thu Feb 14 21:17:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 20:17:17 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <1360873037.5.0.854594744884.issue14720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Can convert_timestamp(val) be implemented as datetime.datetime.strptime(val.decode(), '%Y-%m-%d %H:%M:%S.%f')?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Thu Feb 14 22:13:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 21:13:08 +0000
Subject: [issue11649] startElementNS in xml.sax.saxutils.XMLGenerator ignored
	encoding
In-Reply-To: <1300887023.39.0.212589786895.issue11649@psf.upfronthosting.co.za>
Message-ID: <1360876388.46.0.851983604676.issue11649@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already fixed in issue1470548.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11649>
_______________________________________

From report at bugs.python.org  Thu Feb 14 22:18:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 21:18:05 +0000
Subject: [issue14515] tempfile.TemporaryDirectory documented as returning
	object but returns name
In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za>
Message-ID: <1360876685.97.0.0898275869696.issue14515@psf.upfronthosting.co.za>


R. David Murray added the comment:

The patch is missing the markup for the 'as' keyword (it should read :keyword:`as`).  If that were added, would the sentence make sense to you?  Would it be clearer to say that the directory name is returned by the __enter__ method?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14515>
_______________________________________

From report at bugs.python.org  Thu Feb 14 22:29:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 21:29:32 +0000
Subject: [issue14515] tempfile.TemporaryDirectory documented as returning
	object but returns name
In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za>
Message-ID: <1360877372.56.0.958546109872.issue14515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Aha, now it makes a sense to me.

I don't know which variant will be clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14515>
_______________________________________

From report at bugs.python.org  Thu Feb 14 23:32:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2013 22:32:57 +0000
Subject: [issue15528] Better support for finalization with weakrefs
In-Reply-To: <1360856723.59.0.56869913329.issue15528@psf.upfronthosting.co.za>
Message-ID: <1360880977.3562.1.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> But in Py_Finalize(), call_py_exitfuncs() is called *before*
> _Py_Finalizing is set to a non-NULL value.
> 
> 
> http://hg.python.org/cpython/file/0f827775f7b7/Python/pythonrun.c#l492

Ah, right. But is it any different from, e.g., registering an atexit
handler from a daemon thread?
In any case, I think it's just something we'll have to live with. Daemon
threads are not a terrific idea in general.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________

From report at bugs.python.org  Fri Feb 15 00:21:00 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 14 Feb 2013 23:21:00 +0000
Subject: [issue15528] Better support for finalization with weakrefs
In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za>
Message-ID: <1360884060.73.0.0709970187001.issue15528@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> In any case, I think it's just something we'll have to live with. Daemon
> threads are not a terrific idea in general.

I agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15528>
_______________________________________

From report at bugs.python.org  Fri Feb 15 00:47:38 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Thu, 14 Feb 2013 23:47:38 +0000
Subject: [issue17207] string format precision misbehaving
Message-ID: <1360885658.67.0.591874528903.issue17207@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Hi,
  I don't know if this is related to issue8040 or not. I find the 2.7 string formatting behavior inconsistent. I found out sometimes I have to divide my number by 100 so that the percentage values get printed correctly. Somehow, when a percent sign appears in the formatting "definition" python magically multiplies the number by 100. But sometimes not. This is not specified in http://docs.python.org/2/library/stdtypes.html#string-formatting so I really do not like this whole thing, sorry to say that.

Some examples, which should have been posted in the Library reference doc above.

$ python
Python 2.7.3 (default, Dec 19 2012, 00:02:12) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "%s" % 12.7666666667
'12.7666666667'
>>> "%s" % '{:.2%}'.format(12.7666666667)
'1276.67%'
>>> "%s" % '{:.2%}'.format(float(12.7666666667))
'1276.67%'
>>>
>>> "%s" % ( '{:.4%}'.format(12.7666666667) )
'1276.6667%'
>>> "%s" % ( '{:.4}'.format(12.7666666667) )
'12.77'
>>> "%s" % ( '{:.2}'.format(12.7666666667) )
'1.3e+01'
>>> "%s%%" % ( '{:.2}'.format(12.7666666667) )
'1.3e+01%'
>>> "%s%%" % ( '{:.2}'.format('12.7666666667') )
'12%'
>>> "%s%%" % ( '{:.4}'.format(float(12.7666666667)) )
'12.77%'
>>>

>>> "%s" % ( '{:.2%}'.format(1/10) )
'0.00%'
>>> "%s" % ( '{:.2%}'.format(1/10.0) )
'10.00%'
>>> "%s" % ( '{:.2%}'.format(1/10.0 * 100) )
'1000.00%'
>>> "%s" % ( '{:.2%}'.format((1/10.0) * 100) )
'1000.00%'
>>>
>>> "%s" % ( '{:.2}'.format((1/10.0) * 100) )
'1e+01'
>>> "%s" % ( '{:.2%}'.format((1/10.0) * 100) )
'1000.00%'
>>>


1) Would somebody please document the behavior?

2) Would somebody explain how can I print 12.67% (I want precision of 2 places after the decimal dot).

3) Why sometimes using float() fixes the behavior (likely converting int() to float()?

4) But why does the scientific exponential notation sometimes come out?



5) Finally, it would be nice if the python 2.7 docs contained how to format floats to 2 places after the dot using the "old" syntax":

"float=%f" % (12.7666666667)

I would like to get just "12.77" out. I can use round() but that is not what I am asking for. I want to change just the formatting of the output:

>>> round(12.7666666667, 2)
12.77
>>> 


Thank you

----------
components: ctypes
messages: 182125
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: string format precision misbehaving
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17207>
_______________________________________

From report at bugs.python.org  Fri Feb 15 01:16:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Feb 2013 00:16:50 +0000
Subject: [issue17207] string format precision misbehaving
In-Reply-To: <1360885658.67.0.591874528903.issue17207@psf.upfronthosting.co.za>
Message-ID: <1360887410.67.0.832931476602.issue17207@psf.upfronthosting.co.za>


R. David Murray added the comment:

You appear to be mixing up % style formatting and 'format' style formatting, especially since you seem to be using both in your examples, which is redundant.

Please see http://docs.python.org/2.7/library/string.html#format-string-syntax for the explanation of the format method, including the % presentation type.

Your questions will probably be answered better and more thoroughly if you post to the python-lits mailing list (the tracker is not a place to get help, I'm afraid), but some quick hints:  In Python2.7, 1/10 is 0. In a 'format' format string you can get what it sounds like you want by doing this:

  >>> '{:.2f}%'.format(12.67777)
  '12.68%'

In % style formatting you would do

  >>> '%.2f%%' % 12.67777
  '12.68%'

This is all well documented, but if you can see places it could be clarified, please let us know.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17207>
_______________________________________

From report at bugs.python.org  Fri Feb 15 02:37:25 2013
From: report at bugs.python.org (Sven Brauch)
Date: Fri, 15 Feb 2013 01:37:25 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360892245.84.0.646609645493.issue16795@psf.upfronthosting.co.za>


Sven Brauch added the comment:

I don't want to push anything, but did you find time to review this yet? It would be great to have it in the next release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16795>
_______________________________________

From report at bugs.python.org  Fri Feb 15 02:55:42 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Feb 2013 01:55:42 +0000
Subject: [issue16795] Patch: some changes to AST to make it more useful for
	static language analysis
In-Reply-To: <1356644683.65.0.359499511153.issue16795@psf.upfronthosting.co.za>
Message-ID: <1360893342.07.0.0805472612186.issue16795@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Python 3.4.0a1 isn't due until August so you have no worries about missing the next release. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16795>
_______________________________________

From report at bugs.python.org  Fri Feb 15 05:12:59 2013
From: report at bugs.python.org (Reuben D'Netto)
Date: Fri, 15 Feb 2013 04:12:59 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>
Message-ID: <1360901579.27.0.274249487082.issue17200@psf.upfronthosting.co.za>


Reuben D'Netto added the comment:

OK, I've implemented tests for read_until() and expect() using both poll and select. I ended up rewriting _read_until_with_select() to look more like the poll equivalent in the process, which should hopefully make it more maintainable.

----------
Added file: http://bugs.python.org/file29076/telnetlib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Fri Feb 15 09:10:33 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Feb 2013 08:10:33 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360915833.27.0.0346897280315.issue13153@psf.upfronthosting.co.za>


Ned Deily added the comment:

LGTM.  The patch does prevent the crash in IDLE which is certainly an improvement until such time as someone investigates having Tk/tkinter fully support non-BMP characters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 09:12:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Feb 2013 08:12:31 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1360732006.1.0.547363663584.issue17200@psf.upfronthosting.co.za>
Message-ID: <1360915951.11.0.364361860005.issue17200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

0 and None must be different.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Fri Feb 15 09:25:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Feb 2013 08:25:27 +0000
Subject: [issue5308] cannot marshal objects with more than 2**31 elements
In-Reply-To: <1234997106.01.0.558053875674.issue5308@psf.upfronthosting.co.za>
Message-ID: <1360916727.79.0.117779045458.issue5308@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5308>
_______________________________________

From report at bugs.python.org  Fri Feb 15 09:26:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Feb 2013 08:26:40 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1360916800.21.0.336555466561.issue13555@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:21:28 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Feb 2013 09:21:28 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360920088.58.0.86149880714.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

Are there any objections to this unittest cleanup patch?  I'd like to commit it separately prior to anything that will go in for the C OrderedDict.

----------
Added file: http://bugs.python.org/file29077/cleanup-test-collections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:24:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 09:24:39 +0000
Subject: [issue17208] add note/warning about daemon threads
Message-ID: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

People are generally not aware of the properties of daemon threads.
I suggest to add a note such as the following:

? Daemon threads are abruptly stopped at shutdown. Their resources (such as open files, database transactions, etc.) may not be released properly. If you want your threads to stop gracefully, make them non-daemonic and use a suitable signalling mechanism such as an Event. ?

----------
assignee: docs at python
components: Documentation
messages: 182133
nosy: docs at python, pitrou, sbt
priority: normal
severity: normal
status: open
title: add note/warning about daemon threads
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17208>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:27:24 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Feb 2013 09:27:24 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360920444.73.0.950498438127.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

Incidently, I'm just about done with the OrdereDict patch.  I'm attaching the current one.  At present it passes the unit tests, but I have two memory-related issues and a number of open questions (that I don't think are critical).

The patch has the unittest cleanup merged in just so it will show up in reviewboard.

----------
Added file: http://bugs.python.org/file29078/odict.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:27:41 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Feb 2013 09:27:41 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360920461.92.0.208204427869.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file28839/cleanup-test-collections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:27:49 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Feb 2013 09:27:49 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360920469.13.0.264299680997.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file28956/odict.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:28:14 2013
From: report at bugs.python.org (Tim Golden)
Date: Fri, 15 Feb 2013 09:28:14 +0000
Subject: [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <511DFFAA.4010302@timgolden.me.uk>


Tim Golden added the comment:

+1 This is essentially the answer to the naive user's question:

"Why would anyone *not* use daemon threads given that they're less
hassle to manage?"

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17208>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:47:00 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 15 Feb 2013 09:47:00 +0000
Subject: [issue979407] urllib2 digest auth totally broken
Message-ID: <1360921620.71.0.291082978339.issue979407@psf.upfronthosting.co.za>


Michele Orr? added the comment:

Isn't this issue fixed and tested on Lib/test/test_urllib2.py:1304?

----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue979407>
_______________________________________

From report at bugs.python.org  Fri Feb 15 13:34:24 2013
From: report at bugs.python.org (raymontag)
Date: Fri, 15 Feb 2013 12:34:24 +0000
Subject: [issue17209] get_wch() doesn't handle KeyboardInterrupt
Message-ID: <1360931664.77.0.750623076852.issue17209@psf.upfronthosting.co.za>


New submission from raymontag:

If I've initialized a window in curses, try to get a single character with get_wch() and press Ctrl+C, the program crashes even if I handle KeyboardInterrupt. Here's a code example.

import curses

scr = curses.initscr()
try:
    char = scr.get_wch()
except KeyboardInterrupt:
    pass

With getch() instead of get_wch() it works though.

----------
components: Library (Lib)
messages: 182137
nosy: raymontag
priority: normal
severity: normal
status: open
title: get_wch() doesn't handle KeyboardInterrupt
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17209>
_______________________________________

From report at bugs.python.org  Fri Feb 15 13:35:06 2013
From: report at bugs.python.org (raymontag)
Date: Fri, 15 Feb 2013 12:35:06 +0000
Subject: [issue17209] get_wch() doesn't handle KeyboardInterrupt
In-Reply-To: <1360931664.77.0.750623076852.issue17209@psf.upfronthosting.co.za>
Message-ID: <1360931706.77.0.245721131552.issue17209@psf.upfronthosting.co.za>


Changes by raymontag <kkoenig at posteo.de>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17209>
_______________________________________

From report at bugs.python.org  Fri Feb 15 13:53:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 12:53:50 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1360932830.55.0.711860121581.issue16043@psf.upfronthosting.co.za>


Christian Heimes added the comment:

+1 for a keyword argument

I also have to add a limit to GzipDecodedResponse().

Python 2.6 and 3.1 are not affected by the issue. The problematic code was added in 2.7 and 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:17:28 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 15 Feb 2013 13:17:28 +0000
Subject: [issue17201] Use allowZip64=True by default
In-Reply-To: <1360775072.39.0.12779828627.issue17201@psf.upfronthosting.co.za>
Message-ID: <1360934248.12.0.0548007080543.issue17201@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

LGTM.

----------
nosy: +Ramchandra.Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17201>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:20:26 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 15 Feb 2013 13:20:26 +0000
Subject: [issue17210] documentation of PyUnicode_Format() states wrong
	argument type requirements
Message-ID: <1360934426.3.0.547345278452.issue17210@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The current documentation says:

"""
PyObject* PyUnicode_Format(PyObject *format, PyObject *args)
    Return value: New reference.

    Return a new string object from format and args; this is analogous to format % args. The args argument must be a tuple.
"""

According to the implementation, however, "args" can be a tuple, a unicode string, or an arbitrary mapping, i.e. everything that Python's "%" operator allows for strings as well.

----------
assignee: docs at python
components: Documentation
messages: 182140
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: documentation of PyUnicode_Format() states wrong argument type requirements
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17210>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:21:08 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 15 Feb 2013 13:21:08 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360934468.3.0.567087585971.issue13153@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

@Ned Deily
Tk, at least on my system, doesn't render Unicode characters, even within BMP correctly but the characters are kept (cut-and-paste works correctly)
What you mean by "support".

----------
nosy: +Ramchandra.Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:23:48 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 15 Feb 2013 13:23:48 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360934628.84.0.505980373738.issue17179@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

@Daniel Urban
Me too.

----------
nosy: +Ramchandra.Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:23:58 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 15 Feb 2013 13:23:58 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360934638.63.0.0432176721753.issue17179@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:40:10 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Fri, 15 Feb 2013 13:40:10 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
Message-ID: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

Will attach a patch soon.

----------
components: Library (Lib)
messages: 182143
nosy: Ramchandra.Apte
priority: normal
severity: normal
status: open
title: pkgutil.iter_modules and walk_packages should return a namedtuple
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Fri Feb 15 14:56:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Feb 2013 13:56:33 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
In-Reply-To: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>
Message-ID: <1360936593.74.0.0770116164009.issue17211@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Fri Feb 15 15:54:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 14:54:39 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
In-Reply-To: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>
Message-ID: <1360940079.17.0.934004831922.issue17211@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Fri Feb 15 15:56:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 14:56:13 +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: <1360940173.8.0.0376135771225.issue7145@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed, I would suggest won't fix.

----------
resolution:  -> wont fix
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7145>
_______________________________________

From report at bugs.python.org  Fri Feb 15 16:03:20 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Feb 2013 15:03:20 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360940600.8.0.271821921398.issue16991@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Why did you copy test_collections.py instead of just creating a new file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Fri Feb 15 16:05:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Feb 2013 15:05:43 +0000
Subject: [issue6426] imaplib.IMAP4 "command illegal in this state" is
	unhelpful error message
In-Reply-To: <1246868579.93.0.42678360783.issue6426@psf.upfronthosting.co.za>
Message-ID: <1360940743.33.0.715640473526.issue6426@psf.upfronthosting.co.za>


R. David Murray added the comment:

The issue 1605192 fix was applied to 2.7.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Make Imap Error more helpful

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6426>
_______________________________________

From report at bugs.python.org  Fri Feb 15 16:07:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Feb 2013 15:07:58 +0000
Subject: [issue6497] Support for digital Cinema/film DPX and Kodak Cineon
	image file formats in imghdr module
In-Reply-To: <1247779729.41.0.45019789349.issue6497@psf.upfronthosting.co.za>
Message-ID: <1360940878.6.0.0373420543946.issue6497@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file14520/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6497>
_______________________________________

From report at bugs.python.org  Fri Feb 15 17:56:40 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Feb 2013 16:56:40 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360947400.2.0.443172732659.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

> Why did you copy test_collections.py instead of just creating
> a new file?

To preserve the history of changes to the bulk of the code in test_ordereddict.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:19:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 17:19:36 +0000
Subject: [issue17163] Fix test discovery for test_file.py
Message-ID: <3Z71Rq6R8ZzT1x@mail.python.org>


New submission from Roundup Robot:

New changeset 9b3c5085b4a4 by Ezio Melotti in branch '3.3':
#17163: test_file now works with unittest test discovery.  Patch by Zachary Ware.
http://hg.python.org/cpython/rev/9b3c5085b4a4

New changeset f289e40b3d70 by Ezio Melotti in branch 'default':
#17163: merge with 3.3.
http://hg.python.org/cpython/rev/f289e40b3d70

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17163>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:20:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 17:20:07 +0000
Subject: [issue17163] Fix test discovery for test_file.py
In-Reply-To: <3Z71Rq6R8ZzT1x@mail.python.org>
Message-ID: <1360948807.53.0.342332954087.issue17163@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17163>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:22:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 17:22:01 +0000
Subject: [issue17167] python man page contains $Date$ in page footer
In-Reply-To: <1360400635.24.0.00924107320182.issue17167@psf.upfronthosting.co.za>
Message-ID: <1360948921.33.0.773925187089.issue17167@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17167>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:22:02 2013
From: report at bugs.python.org (Harvey Ormston)
Date: Fri, 15 Feb 2013 17:22:02 +0000
Subject: [issue16525] wave file module does not support 32bit float format
In-Reply-To: <1353528827.37.0.543069044809.issue16525@psf.upfronthosting.co.za>
Message-ID: <1360948922.45.0.462499247619.issue16525@psf.upfronthosting.co.za>


Harvey Ormston added the comment:

I see that this issue applies to Python 3.4. Nevertheless, I am now using the submitted patch (http://bugs.python.org/file28122/wave_float_issue16525.patch) with Python 2.7.

I find that the patched module fails when calling getwavformat(), becuase the _wavformat attribute is not set.

I attach wave_read_issue16525.patch, which properly sets the _wavformat attribute and allows getwavformat() to succeed.

Apologies if I have not followed the proper process here. I found this patch a while ago while looking for a solution to the limitations in the standard wave module and, upon using the patch, identified this potential issue which I have attampted to fix. I thought it would be best to share that fix.

----------
nosy: +harveyormston
Added file: http://bugs.python.org/file29079/wave_read_issue16525.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16525>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:30:48 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Feb 2013 17:30:48 +0000
Subject: [issue17178] In all.__doc__ and any.__doc__ need to clarify the
	behaviour with an empty iterable like in documentation
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360949448.53.0.447760908164.issue17178@psf.upfronthosting.co.za>


?ric Araujo added the comment:

If someone wants to write the patch for this, feel free to ask (here or on the core-mentorship friendly mailing list) if you need help finding the right C file or anything else.

----------
components: +Interpreter Core -Documentation
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:32:46 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Feb 2013 17:32:46 +0000
Subject: [issue17177] Document/deprecate imp
In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>
Message-ID: <1360949566.0.0.810151738706.issue17177@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I?ve always perceived imp as an implementation detail of the import system that people were sometimes forced to use to get to some things.  Now that we have importlib, deprecating (with a nice long compatibility-with-warnings period) sounds good.

Would checking with the other VMs be a good idea?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:36:56 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Feb 2013 17:36:56 +0000
Subject: [issue17167] python man page contains $Date$ in page footer
In-Reply-To: <1360400635.24.0.00924107320182.issue17167@psf.upfronthosting.co.za>
Message-ID: <1360949816.97.0.335609514651.issue17167@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Agreed with Ned, this sounds like a job for the release script to me.

I think we avoid manual edition of dates in the HTML docs thanks to Sphinx; we could generate the man page with Sphinx too (if there were enough advantages than just this issue).

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17167>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:52:54 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Feb 2013 17:52:54 +0000
Subject: [issue979407] urllib2 digest auth totally broken
Message-ID: <1360950774.54.0.46968718492.issue979407@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

let me check that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue979407>
_______________________________________

From report at bugs.python.org  Fri Feb 15 18:54:48 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Feb 2013 17:54:48 +0000
Subject: [issue17177] Document/deprecate imp
In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>
Message-ID: <1360950888.21.0.694726876491.issue17177@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Checking with the other VMs wouldn't benefit anyone. They still have to implement whatever is necessary from _imp in order for importlib to work. Otherwise it's just another stdlib module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Fri Feb 15 19:18:57 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Feb 2013 18:18:57 +0000
Subject: [issue6784] byte/unicode pickle incompatibilities between python2 and
	python3
In-Reply-To: <1251287773.44.0.222300610244.issue6784@psf.upfronthosting.co.za>
Message-ID: <1360952337.41.0.259992487178.issue6784@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Feb 15 19:44:36 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 18:44:36 +0000
Subject: [issue17178] In all.__doc__ and any.__doc__ need to clarify the
	behaviour with an empty iterable like in documentation
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360953876.05.0.380842812319.issue17178@psf.upfronthosting.co.za>


Ankur Ankan added the comment:

I am a beginner and want to write the patch for this issue, so please help me find the right C file.
Thanks.

----------
nosy: +Ankur.Ankan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 19:51:14 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 18:51:14 +0000
Subject: [issue17178] In all.__doc__ and any.__doc__ need to clarify the
	behaviour with an empty iterable like in documentation
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360954274.55.0.296706575157.issue17178@psf.upfronthosting.co.za>


Ankur Ankan added the comment:

I guess I have found it. It's bltinmodule.c .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 20:22:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 19:22:39 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <3Z749p1pvtz7LkJ@mail.python.org>


Roundup Robot added the comment:

New changeset 3f8b5fcbf07e by Ezio Melotti in branch '3.3':
#17143: fix a missing import in the trace module.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/3f8b5fcbf07e

New changeset 46e9f668aea9 by Ezio Melotti in branch 'default':
#17143: merge with 3.3.
http://hg.python.org/cpython/rev/46e9f668aea9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Fri Feb 15 20:26:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 19:26:11 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360956371.26.0.0144015182692.issue17143@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

I changed a couple of things:
1) test_deprecated_usage was printing the usage on stderr while running the tests -- I changed it to use a StringIO and added a minimal test to check that the usage is actually written;
2) there was an unnecessary "import warnings" that I removed;

FTR this bug was introduced in f1604371240a.

----------
assignee:  -> ezio.melotti
nosy: +flox
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Fri Feb 15 20:39:14 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 19:39:14 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360957154.65.0.999553714921.issue17172@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a comment in rietveld.

> I hope the File menu is the right place for this.

I think that's the best place where to put it.

> I had to move the code in Lib/turtledemo.py after "if __name__ ==..." into main().

Why?

> Should this be added to Lib/idlelib/NEWS.txt ?

Yes.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Fri Feb 15 20:50:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 19:50:35 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1360957835.36.0.850962845397.issue17143@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The windows buildbots are failing with the following error:
ERROR: test_deprecated_find_strings (test.test_trace.TestDeprecatedMethods)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_trace.py", line 401, in test_deprecated_find_strings
    trace.find_strings(fd.name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\trace.py", line 850, in find_strings
    return _find_strings(filename, encoding=None)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\trace.py", line 422, in _find_strings
    with open(filename, encoding=encoding) as f:
PermissionError: [Errno 13] Permission denied: 'c:\\users\\buildbot\\appdata\\local\\temp\\tmp_08yph'

See:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.3/builds/491/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1473/steps/test/logs/stdio

The problem seems to be related to the use of NamedTemporaryFile in test_deprecated_find_strings, but doesn't seem to affect test_deprecated_find_executable_linenos.

There's also a warning for test_ignored:
test_ignored (test.test_trace.Test_Ignore) ... Not printing coverage data for 'c:\\users\\buildbot\\appdata\\local\\temp\\tmpwrqs7_': [Errno 13] Permission denied: 'c:\\users\\buildbot\\appdata\\local\\temp\\tmpwrqs7_'

This was probably here already, but went unnoticed because it doesn't cause failures and it's probably printed in verbose mode only.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:04:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:04:38 +0000
Subject: [issue17175] update PEP 430
In-Reply-To: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>
Message-ID: <3Z756F45vHzSw2@mail.python.org>


Roundup Robot added the comment:

New changeset f306777e0b6d by Ezio Melotti in branch 'default':
#17175: remove outdated paragraph about issue #8040 from PEP 430.  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/peps/rev/f306777e0b6d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17175>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:04:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:04:38 +0000
Subject: [issue8040] documentation pages should link to other versions of the
	same page
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <3Z756G2mGSzSw2@mail.python.org>


Roundup Robot added the comment:

New changeset f306777e0b6d by Ezio Melotti in branch 'default':
#17175: remove outdated paragraph about issue #8040 from PEP 430.  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/peps/rev/f306777e0b6d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:05:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 20:05:51 +0000
Subject: [issue17175] update PEP 430
In-Reply-To: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>
Message-ID: <1360958751.02.0.169530103915.issue17175@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17175>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:15:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 20:15:34 +0000
Subject: [issue17177] Document/deprecate imp
In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>
Message-ID: <1360959334.27.0.944818410916.issue17177@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Basically I need to figure out what imp's role is supposed to be in the face of importlib.

If it's not even clear for you, even if you eventually figure that out, having two import-related modules is likely to be confusing for users.
OTOH deprecating/removing imp would affect the somewhat popular imp.reload(), that has already been moved for Python 3, and will now be moved again (this also means that the -3 warnings on 2.7 will no longer be valid).

----------
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:27:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 20:27:08 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360960028.22.0.30461548268.issue13153@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The characters tk can render depends on the font you tell it to use. On my Windows IDLE, I have Options Font Face set to Lucida Sans Unicode, though I am not sure what has the widest coverage. This page
https://www.microsoft.com/typography/fonts/font.aspx?FMID=1263
only mentions West Asian, but I seem to get more than that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:30:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:30:38 +0000
Subject: [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <3Z75hF4hKBzQ2s@mail.python.org>


Roundup Robot added the comment:

New changeset e63c4bc81d9f by Antoine Pitrou in branch '2.7':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/e63c4bc81d9f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17208>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:35:06 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Feb 2013 20:35:06 +0000
Subject: [issue17177] Document/deprecate imp
In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>
Message-ID: <1360960506.57.0.544368033436.issue17177@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I would probably document the deprecation but otherwise leave it alone at the module level. Considering I only documented imp.find_module() and .load_module() as documented thanks to their funky interfaces making nearly impossible to do a direct translation I don't see how I can justify raising a DeprecationWarning for the whole thing.

But it's gone in Python 4. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:35:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:35:51 +0000
Subject: [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <3Z75pH0H2wzQT1@mail.python.org>


Roundup Robot added the comment:

New changeset 8753a3be4a3c by Antoine Pitrou in branch '3.2':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/8753a3be4a3c

New changeset 917ae89e59ce by Antoine Pitrou in branch '3.3':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/917ae89e59ce

New changeset 8b85f10b5341 by Antoine Pitrou in branch 'default':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/8b85f10b5341

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17208>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:36:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 20:36:07 +0000
Subject: [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <1360960567.2.0.324114884305.issue17208@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Committed.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17208>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:47:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 20:47:18 +0000
Subject: [issue17178] Clarify empty iterable result in any/all.__doc__,
	as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360961238.16.0.881112855559.issue17178@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Titles should fit in the box if possible, and this can ;-).

----------
nosy: +terry.reedy
title: In all.__doc__ and any.__doc__ need to clarify the behaviour with an empty iterable like in documentation -> Clarify empty iterable result in any/all.__doc__, as in manual

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:48:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 20:48:42 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360961322.49.0.710995850753.issue13153@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The font used shouldn't affect the errors.  Usually if a glyph is missing in the current font, either a placeholder (usually a box) is showed instead or the missing glyph is taken from another font (if possible).

If you still want to do some tests, you can take a look at http://en.wikipedia.org/wiki/List_of_Unicode_fonts#Unicode_fonts

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:57:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 20:57:35 +0000
Subject: [issue17177] Document/deprecate imp
In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>
Message-ID: <1360961855.98.0.253040903007.issue17177@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

If you move them to importlib and just leave an alias in imp, you should still add a DeprecationWarning IMHO, even if you plan to remove them in Python 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:58:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 20:58:10 +0000
Subject: [issue17176] Document imp.NullImporter is NOT used anymore by import
In-Reply-To: <1360525827.54.0.547409827798.issue17176@psf.upfronthosting.co.za>
Message-ID: <1360961890.32.0.318576718651.issue17176@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17176>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:06:57 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 21:06:57 +0000
Subject: [issue17178] Clarify empty iterable result in any/all.__doc__,
	as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360962417.12.0.369640626923.issue17178@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29080/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:07:48 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 21:07:48 +0000
Subject: [issue17178] Clarify empty iterable result in any/all.__doc__,
	as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360962468.47.0.562048473361.issue17178@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


Removed file: http://bugs.python.org/file29080/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:08:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:08:18 +0000
Subject: [issue17184] re.VERBOSE doesn't respect whitespace in '( ?P<foo>...)'
In-Reply-To: <1360611548.83.0.365452859403.issue17184@psf.upfronthosting.co.za>
Message-ID: <1360962498.74.0.54131166927.issue17184@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> re.VERBOSE whitespace behavior not completely documented
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17184>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:08:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:08:52 +0000
Subject: [issue15606] re.VERBOSE whitespace behavior not completely documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1360962532.51.0.723196963586.issue15606@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #17184.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15606>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:09:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 21:09:42 +0000
Subject: [issue17179] Incorrect use of type function in types.new_class
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360962582.47.0.985679157762.issue17179@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As far as I know, currently, the only valid 'keyword' argument for a class statement is 'metaclass' and that is so advanced that it is not mentioned in *8.7. Class definitions* but only in the linked section *3.3.3. Customizing class creation*. The types.newclass doc also only mentions 'metaclass' as a possible keyword. (Maybe it should currently say that that is the only possibility, but perhaps the window was being left open for possible additions in the future.) So I agree that passing anything else is a bug and should raise. If so, this issue should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:10:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:10:13 +0000
Subject: [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1360962613.04.0.555795858827.issue17188@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +benjamin.peterson, ezio.melotti
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17188>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:12:22 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 21:12:22 +0000
Subject: [issue17178] Clarify empty iterable result in any/all.__doc__,
	as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360962742.81.0.966337431788.issue17178@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


Added file: http://bugs.python.org/file29081/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:20:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:20:58 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360963258.4.0.915757151093.issue17193@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

+1

I left some comments on Rietveld.
The SI standard says that there should be a space between the value and the unit, and I agree that while a no-break space would be better, a regular space is still better than no space at all.
Applying this on 3.3 and default is fine too.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:38:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 21:38:37 +0000
Subject: [issue17178] Clarify empty iterable result in any/all.__doc__,
	as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <3Z77Bh2dxNz7Ll4@mail.python.org>


Roundup Robot added the comment:

New changeset 0f7eec78569c by Ezio Melotti in branch '2.7':
#17178: update any()/all() docstrings to document their behavior with empty iterables.  Patch by Ankur Ankan.
http://hg.python.org/cpython/rev/0f7eec78569c

New changeset 1d4849f9e37d by Ezio Melotti in branch '3.2':
#17178: update any()/all() docstrings to document their behavior with empty iterables.  Patch by Ankur Ankan.
http://hg.python.org/cpython/rev/1d4849f9e37d

New changeset 34cfe145b286 by Ezio Melotti in branch '3.3':
#17178: merge with 3.2.
http://hg.python.org/cpython/rev/34cfe145b286

New changeset 168efd87e051 by Ezio Melotti in branch 'default':
#17178: merge with 3.3.
http://hg.python.org/cpython/rev/168efd87e051

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:40:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:40:16 +0000
Subject: [issue17178] Clarify empty iterable result in any/all.__doc__,
	as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360964416.13.0.748204688122.issue17178@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
components: +Documentation -Interpreter Core
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17178>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:42:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:42:02 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1360964522.97.0.213703232395.issue17183@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

We should add some benchmarks to see if there is any difference between the two forms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:43:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:43:56 +0000
Subject: [issue17202] Add .bat line to .hgeol
In-Reply-To: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>
Message-ID: <1360964636.31.0.6091264957.issue17202@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +djc, ezio.melotti, loewis
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17202>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:47:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Feb 2013 21:47:35 +0000
Subject: [issue17209] get_wch() doesn't handle KeyboardInterrupt
In-Reply-To: <1360931664.77.0.750623076852.issue17209@psf.upfronthosting.co.za>
Message-ID: <1360964855.68.0.322378756193.issue17209@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17209>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:57:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Feb 2013 21:57:00 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360965420.3.0.339545849571.issue13153@psf.upfronthosting.co.za>


Ned Deily added the comment:

Also, there are differences in behavior among the various flavors of Tk.  I know of at least four main flavors in use by current Python builds:  Unix X11-based Tk 8.5, Windows Tk 8.5, OS X Cocoa Tk 8.5, OS X Carbon Tk 8.4.  Some third-party distributors are starting to supply Tk 8.6, in its various flavors, now that 8.6 has been released. Each flavor has various build options and features to fit in with its host o/s environment.  This makes testing tkinter issues *interesting*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 22:59:06 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 15 Feb 2013 21:59:06 +0000
Subject: [issue17202] Add .bat line to .hgeol
In-Reply-To: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>
Message-ID: <1360965546.64.0.565649778622.issue17202@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +georg.brandl, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17202>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:03:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Feb 2013 22:03:52 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360965832.01.0.153124932867.issue13153@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Tkinter is not compatible with Tcl/Tk 8.6 yet (issue16809).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:07:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 22:07:35 +0000
Subject: [issue17202] Add .bat line to .hgeol
In-Reply-To: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>
Message-ID: <1360966055.92.0.204796078651.issue17202@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

**.bat used to be there, but it was removed in 1762d79eab65.

I have a very faint memory of some discussion about bat files and EOLs, but the best I could find was:
http://mail.python.org/pipermail/python-dev/2012-May/119220.html
http://mail.python.org/pipermail/python-dev/2012-May/119225.html

This seems to suggest that CRLF shouldn't be necessary.

There's also an older discussion about adding CRLF for make.bat here (the discussion is actually somewhat unrelated, but back then adding these entries sounded like a good idea): http://mail.python.org/pipermail/python-committers/2011-May/001685.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17202>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:10:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 22:10:02 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1360966202.49.0.379937192151.issue17183@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'Enhancement' issues are for visible behavior additions (or occasionally, changes). This is intended to be an invisible small speedup, hence it is a 'performance' issue, and gets a different title.

As explained in #17170, the change will not be a speedup if the substring being looked for is usually not there. The reason is the .find lookup and function call versus the direct syntax. Even if it is faster, I strongly doubt it would be hardly noticeable in the context of this function, which itself is a small piece of parsing an entire document, and it is against our policy to make such micro-optimizations in working code.

The complete block in question Lib/_markupbase.py, 254:7 is

  rawdata = self.rawdata
  if '>' in rawdata[j:]:
    return rawdata.find(">", j) + 1
  return -1

[Ugh. Localizing rawdata negates some of whatever advantage is gained from the double scan.]

If I were to rewrite it, I would replace it with

  try:
    return self.rawdata.index(">", j) + 1
  except ValueError:
    return -1

as better style, and a better example for readers, regardless of micro speed differences. But style-only changes in working code is also against our policy. So I would be closing this if Ezio had not grabbed it ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:11:14 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Feb 2013 22:11:14 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1360966274.53.0.323435976148.issue13153@psf.upfronthosting.co.za>


Ned Deily added the comment:

Serhiy, I'm aware of that; regardless, Tk 8.6 is starting to be used out in the field with tkinter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:22:17 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 22:22:17 +0000
Subject: [issue17187] Python segfaults from improperly formed and called
	function
In-Reply-To: <1360626883.99.0.640748040618.issue17187@psf.upfronthosting.co.za>
Message-ID: <1360966937.61.0.34120858983.issue17187@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17187>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:28:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 22:28:07 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1360967287.27.0.72581029241.issue17183@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I would still do a benchmark, for these reasons:
1) IIRC rawdata might be the whole document (or at least everything that has not been parsed yet);
2) the '>' is very likely to be found;

This situation is fairly different from the one presented in #17170, where the strings are shorts and the character is not present in the majority of the strings.

Profiling and improving html.parser (and hence _markupbase) was already on my todo list (even if admittedly not anywhere near the top :), so writing a benchmark for it might be useful for further enhancements too.

(Note: HTMLParser is already fairly fast, parsing ~1.3MB/s according to http://www.crummy.com/2012/02/06/0, but I've never done anything to make it even faster, so there might still be room for improvements.)

----------
type: enhancement -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:31:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 22:31:50 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360967510.5.0.770842707114.issue17193@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that we should contribute to ending the confusion. Searching KiB, MiB, GiB (with Google) gives a Wikipedia article as first or second hit, so the meanings of the abbreviations and terms are easily discoverable.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:41:34 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 15 Feb 2013 22:41:34 +0000
Subject: [issue17202] Add .bat line to .hgeol
In-Reply-To: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>
Message-ID: <1360968094.66.0.0119868426398.issue17202@psf.upfronthosting.co.za>


Zachary Ware added the comment:

> This seems to suggest that CRLF shouldn't be necessary.

It's not necessary on .bat files without labels, but those with labels are subject to the (Windows) bug described in my first message and link.

Adding an entry specifically for Doc/make.bat and any other batch scripts with labels would be fine as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17202>
_______________________________________

From report at bugs.python.org  Fri Feb 15 23:49:59 2013
From: report at bugs.python.org (G. Poore)
Date: Fri, 15 Feb 2013 22:49:59 +0000
Subject: [issue17212] os.path.isfile() in Python 3.3 sometimes fails
Message-ID: <1360968598.97.0.73683430526.issue17212@psf.upfronthosting.co.za>


New submission from G. Poore:

os.path.isfile() sometimes incorrectly reports that a file does not exist under Python 3.3 (only tested under Windows).  This may be encoding related.  The issue only appears under a very particular set of circumstances; see comments in the attached script.  The attached script demonstrates the issue by testing for an arbitrary file x.txt (you will need to create a file with that name for the test script to work).

----------
components: Library (Lib)
files: os-path-issue-3-3.py
messages: 182188
nosy: gpoore
priority: normal
severity: normal
status: open
title: os.path.isfile() in Python 3.3 sometimes fails
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29082/os-path-issue-3-3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17212>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:24:06 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:24:06 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1360970646.85.0.853285859479.issue16041@psf.upfronthosting.co.za>


Christian Heimes added the comment:

RFC 1939 says:

   Responses in the POP3 consist of a status indicator and a keyword
   possibly followed by additional information.  All responses are
   terminated by a CRLF pair.  Responses may be up to 512 characters
   long, including the terminating CRLF.

It doesn't say anything about the length of a line in a multi-line response. It's reasonable to belief that 512 octets are valid, too. We could quadruple the limit to 2048 in order to be safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:42:22 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:42:22 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1360971742.31.0.302726700339.issue16040@psf.upfronthosting.co.za>


Christian Heimes added the comment:

RFC 3977 specifies:

  Command lines MUST NOT exceed 512 octets, which includes
  the terminating CRLF pair.

However NNTP also have multi-line data blocks. The RFC says nothing about the maximum length of a data line. We may need two limits here, one for command lines (2048 perhaps) and one much larger for data lines (a couple of MB?).

Can somebody check other implementations?

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:43:37 2013
From: report at bugs.python.org (Lars Buitinck)
Date: Fri, 15 Feb 2013 23:43:37 +0000
Subject: [issue9369] const char* for PyObject_CallMethod and
	PyObject_CallFunction
In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>
Message-ID: <1360971817.45.0.757450099221.issue9369@psf.upfronthosting.co.za>


Lars Buitinck added the comment:

I'm sorry, I really don't understand this refcounts.dat file and I'm not going to hack it further. Does the patch as it currently stands solve the issue with CallMethod and CallFunction, or not? (It has the changes to the docs.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9369>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:47:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 23:47:25 +0000
Subject: [issue16389] re._compiled_typed's lru_cache causes significant
	degradation of the mako_v2 bench
In-Reply-To: <1351880615.07.0.187029674279.issue16389@psf.upfronthosting.co.za>
Message-ID: <1360972045.83.0.750016068517.issue16389@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Since switching from a simple custom cache to the generalized lru cache made a major slowdown, I think the change should be reverted. A dict + either occasional clearing or a circular queue and a first-in, first-out discipline is quite sufficient. There is no need for the extra complexity of a last-used, first out discipline.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16389>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:53:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:53:50 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1360972430.81.0.263564891455.issue16039@psf.upfronthosting.co.za>


Christian Heimes added the comment:

RFC 3501 and 2060 (IMAP 4rev1) don't specify a line length


RFC 2683 says:

  A client should limit the length of the command lines it
  generates to approximately 1000 octets.

  For its part, a server should allow for a command line of at
  least 8000 octets.

Some config files and code have values between 2k and 64k, usually around 8k to 10k, e.g.

 UW and Panda IMAP have a limit of 10,000 octets which is far
 more than what anything is ever likely to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:58:46 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:58:46 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1360972726.98.0.666268390523.issue16037@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1752  Unbound readline() DoS vulnerabilities in Python stdlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:58:54 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:58:54 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1360972734.82.0.0690362519621.issue16038@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1752  Unbound readline() DoS vulnerabilities in Python stdlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:59:06 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:59:06 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1360972746.91.0.0456294561952.issue16039@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1752  Unbound readline() DoS vulnerabilities in Python stdlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:59:15 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:59:15 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1360972755.56.0.0574548489963.issue16040@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1752  Unbound readline() DoS vulnerabilities in Python stdlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Sat Feb 16 00:59:23 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2013 23:59:23 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1360972763.87.0.648411554525.issue16041@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1752  Unbound readline() DoS vulnerabilities in Python stdlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:00:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Feb 2013 00:00:00 +0000
Subject: [issue16389] re._compiled_typed's lru_cache causes significant
	degradation of the mako_v2 bench
In-Reply-To: <1351880615.07.0.187029674279.issue16389@psf.upfronthosting.co.za>
Message-ID: <1360972800.08.0.400565446621.issue16389@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

For 3.4 #14373 might solve the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16389>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:04:23 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2013 00:04:23 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1360973063.96.0.724935646869.issue16042@psf.upfronthosting.co.za>


Christian Heimes added the comment:

RFC 2821 says:

   command line
      The maximum total length of a command line including the command
      word and the <CRLF> is 512 characters.  SMTP extensions may be
      used to increase this limit.

   reply line
      The maximum total length of a reply line including the reply code
      and the <CRLF> is 512 characters.  More information may be
      conveyed through multiple-line replies.

   text line
      The maximum total length of a text line including the <CRLF> is
      1000 characters (not counting the leading dot duplicated for
      transparency).  This number may be increased by the use of SMTP
      Service Extensions.

I suggest a response limit of 2048 octets (that is four times the max limit) to be on the safe side for a bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:04:41 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2013 00:04:41 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1360973081.48.0.335241126228.issue16042@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1752  Unbound readline() DoS vulnerabilities in Python stdlib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:05:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2013 00:05:30 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1360973130.35.0.178105115106.issue16042@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Oh, next time I should read my own patch and responses first ... ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:08:02 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2013 00:08:02 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1360973282.0.0.253768355405.issue16043@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1753 gzip bomb and unbound read DoS vulnerabilities in Python's xmlrpc library

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:10:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2013 00:10:53 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1360973453.27.0.881164406434.issue12226@psf.upfronthosting.co.za>


Christian Heimes added the comment:

CVE-2013-1754  Man-in-the-middle vulnerability in package upload feature of Python's distutils

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Feb 16 01:39:48 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 16 Feb 2013 00:39:48 +0000
Subject: [issue14373] C implementation of functools.lru_cache
In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za>
Message-ID: <1360975188.2.0.315793233396.issue14373@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/issue14373>
_______________________________________

From report at bugs.python.org  Sat Feb 16 02:00:12 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 16 Feb 2013 01:00:12 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1360976412.44.0.14649524441.issue17192@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

However internal copy of expat was updated in 2.7 and 3.2 branches about 2 weeks ago (issue #14340).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Sat Feb 16 02:40:43 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 16 Feb 2013 01:40:43 +0000
Subject: [issue17206] Py_XDECREF() expands its argument multiple times
In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>
Message-ID: <1360978843.93.0.548062468376.issue17206@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/issue17206>
_______________________________________

From report at bugs.python.org  Sat Feb 16 02:54:49 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Feb 2013 01:54:49 +0000
Subject: [issue1285086] urllib.quote is too slow
In-Reply-To: <1360843175.41.0.890866615789.issue1285086@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOS+0G4q1qip7=VeeXia6fQVuUfhOKYHB84nxdNFokCWtA@mail.gmail.com>


Senthil Kumaran added the comment:

> Serhiy Storchaka added the comment:
>>
>> + append = res.append
>>
>> And then use 'append'?
>
> This speed up unquote_to_bytes by 15%.

Thanks for the response. In fact, writing the whole _hextobyte
verbatim would further increase the speed, but that would be huge
dis-advantage in terms of space occupied by that dict in the code. I
am +1 with the patch, please go ahead with committing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1285086>
_______________________________________

From report at bugs.python.org  Sat Feb 16 04:03:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Feb 2013 03:03:03 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1360983783.34.0.279531581407.issue1285086@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/issue1285086>
_______________________________________

From report at bugs.python.org  Sat Feb 16 04:21:49 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 16 Feb 2013 03:21:49 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1360960028.22.0.30461548268.issue13153@psf.upfronthosting.co.za>
Message-ID: <CAExgZOg-GAQrOABOKDeMidXO9NhSsTMBRpFQeJCpqgmv9_z0rw@mail.gmail.com>


Ramchandra Apte added the comment:

I have set it to "Ubuntu", which supports the Unicode characters. Maybe
Tkinter doesn't work properly with all the fonts.

On 16 February 2013 01:57, Terry J. Reedy <report at bugs.python.org> wrote:

>
> Terry J. Reedy added the comment:
>
> The characters tk can render depends on the font you tell it to use. On my
> Windows IDLE, I have Options Font Face set to Lucida Sans Unicode, though I
> am not sure what has the widest coverage. This page
> https://www.microsoft.com/typography/fonts/font.aspx?FMID=1263
> only mentions West Asian, but I seem to get more than that.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13153>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Sat Feb 16 04:25:27 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 16 Feb 2013 03:25:27 +0000
Subject: [issue17172] Add turtledemo to IDLE menu
In-Reply-To: <1360441966.18.0.528447885335.issue17172@psf.upfronthosting.co.za>
Message-ID: <1360985127.32.0.509502059775.issue17172@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Because turtledemo doesn't have a main() function. I moved the code under 'if __name__ == "__main__"' into a main() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17172>
_______________________________________

From report at bugs.python.org  Sat Feb 16 05:12:29 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Feb 2013 04:12:29 +0000
Subject: [issue17206] Py_XDECREF() expands its argument multiple times
In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za>
Message-ID: <1360987949.57.0.385797194908.issue17206@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I wish we could use inline functions...

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17206>
_______________________________________

From report at bugs.python.org  Sat Feb 16 05:20:22 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 04:20:22 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1360988422.56.0.0397033706379.issue1615@psf.upfronthosting.co.za>


Eric Snow added the comment:

Got bit by a variation of this today in 2.7:


class Spam(object):
    def __getattr__(self, attr):
        raise AttributeError(attr)
    @property
    def eggs(self):
        return self.ham

s = Spam()
s.eggs
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __getattr__
AttributeError: eggs


It took me a little while to figure out what was going on.  A real head-scratcher.  This is because the AttributeError was attributed to the property, but was actually caused by the __getattr__ call triggered by the property's code.  I would expect the AttributeError to reference "ham", not "eggs".  As already noted, if __getattr__() is not there, that's what happens.

Regardless, I'm just not seeing where the hurdle is to improving this behavior.  I certainly agree that this is not a feature.  It is the source of very mysterious failures.

I was surprised that AttributeError does not have an attribute to which the name would be bound.  If it did, then slot_tp_getattr_hook() could check against that:


    if (res == NULL && PyErr_ExceptionMatches(PyExc_AttributeError)) {
        PyObject *tp, *exc, *tb, *exc_attr;

        PyErr_Fetch(&tp, &exc, &tb);
        exc_attr = PyObject_GetAttrString(exc, "attribute");
        PyErr_Restore(tp, exc, tb);

        if (!exc_attr || exc_attr == name) { 
            PyErr_Clear();
            res = call_attribute(self, getattr, name);
        }
        Py_XDECREF(exc_attr);
    }


Alternatively, when an AttributeError comes out of a getter in _PyObject_GenericSetAttrWithDict() (in either spot they're called), another exception (not AttributeError) could be raised with the original chained onto it.  Then slot_tp_getattr_hook() won't silently ignore it.  It would be something like this:


        if (f != NULL && PyDescr_IsData(descr)) {
            res = f(descr, obj, value);
            if (!res && PyErr_ExceptionMatches(PyExc_AttributeError)) {
                PyObject *msg = PyUnicode_FromFormat("getter failed for '%U'", name);
                /* implicit chaining here */
                PyErr_SetObject(PyExc_???Error, msg);
            }
            goto done;
        }


Conceptually, it's as though locating the attribute and extracting the value are lumped together here.  Distinguishing the two would help make this failure situation much less confusing.

Additionally, it would be really helpful to have a brief mention of this behavior (AttributeErrors in getters falling back to __getattr__) in the language reference entry for __getattr__ and/or descriptors.

----------
nosy: +eric.snow
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Sat Feb 16 06:05:12 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Feb 2013 05:05:12 +0000
Subject: [issue17179] Misleading error from type() when passing unknown
	keyword argument
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360991112.28.0.120316277499.issue17179@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The types.new_class docs are quite clear that the supplied keyword arguments are equivalent to those provided in the type header (if you want to pre-populate the namespace, that's what exec_body is for). The problem here is that the dual signature of type (retrieving the type of an existing object, or creating a new one), and the fact that type.__prepare__ ignores all arguments, means the error message is thoroughly misleading when you pass an unknown keyword argument:

>>> type.__prepare__(foo=1)
{}
>>> type("Example", (), {}, foo=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments

>>> class Example(foo=1): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments

>>> import types
>>> types.new_class("Example", (), dict(foo=1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/types.py", line 52, in new_class
    return meta(name, bases, ns, **kwds)
TypeError: type() takes 1 or 3 arguments

The reason type.__prepare__ ignores its arguments is to make it easy for people to use type to anchor a custom metaclass hierarchy and call super().__prepare__(name, bases, **kwds) without needing to worry much about filtering the keyword arguments. (The class machinery intercepts the metaclass hint and never passes it to __prepare__ or the metaclass constructor).

That means the real change needed here is to update type's error message for bad arguments to properly report unknown keyword errors when using the PEP 3115 metaclass API.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Incorrect use of type function in types.new_class -> Misleading error from type() when passing unknown keyword argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Sat Feb 16 06:28:10 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 16 Feb 2013 05:28:10 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360992490.77.0.700803895027.issue16991@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Sat Feb 16 06:33:20 2013
From: report at bugs.python.org (Daniel Colascione)
Date: Sat, 16 Feb 2013 05:33:20 +0000
Subject: [issue17213] ctypes loads wrong version of C runtime,
	leading to error message box from system
Message-ID: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za>


New submission from Daniel Colascione:

Suppose we're running a Python program in an environment where PATH contains a directory that contains msvcr90.dll version A and that python27.exe is manifested to use msvcr90.dll version B, which is available in the SxS store but not on PATH.

Normally, python27.exe's side-by-side (SxS) manifest contains a description of *precisely* the correct version of msvcr90.dll to use, version B, so when python27.exe starts, the NT loader ignores msvcr90.dll version A and loads msvcr90.dll version B.

Everything works fine until somebody calls ctypes.CDLL("c"); uuid.py, which tries to find "uuid_generate_random" in libc on module load, is an example of a component that unexpectedly tries to load libc through ctypes.

Now, when someone tried to load "c", ctypes internally maps "c" to the C runtime library using ctypes.util.find_msvcrt, then calls _ctypes.LoadLibrary, which calls the Win32 API function LoadLibraryA. LoadLibraryA tries to find "msvcr90.dll", but WITHOUT CONSULTING THE SXS ACTIVATION CONTEXT, meaning that LoadLibrary finds msvcr90.dll version A, not version B. msvcr90.dll version A isn't loaded yet, so the NT loader does the usual loading and initialization; msvcr90.dll version A's DllMain runs, notices that it's not being loaded as part of an SxS manifest, and presents the user with an R6034 error message, "an application has made an attempt to laod the C runtime library incorrectly".

The overall result is that users of Python programs see error message popups from "Microsoft Visual C++ Runtime Library" that, in most cases, are completely benign. This problem doesn't occur if the correct version of msvcr90.dll happens to be in PATH.

One solution is to have _ctypes.LoadLibrary use the correct activation context; another is to use GetModuleHandleEx(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, (LPCTSTR) &fopen, &module) to retrieve a handle to the current C runtime library without having to go through LoadLibrary at all.

----------
components: ctypes
messages: 182212
nosy: dancol
priority: normal
severity: normal
status: open
title: ctypes loads wrong version of C runtime, leading to error message box from system
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17213>
_______________________________________

From report at bugs.python.org  Sat Feb 16 06:38:43 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Feb 2013 05:38:43 +0000
Subject: [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1360993123.59.0.346345866584.issue17188@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As Terry notes, the various pieces of "from None" documentation should also have a nearby directive like:

.. versionchanged: 3.3

   :const:`None` permitted as ``Y`` in ``raise X from Y`` 

.. versionadded: 3.3

   The ``__suppress_context__`` attribute to suppress automatic display of the exception context

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17188>
_______________________________________

From report at bugs.python.org  Sat Feb 16 07:25:52 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 06:25:52 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360995952.68.0.517455871822.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Added file: http://bugs.python.org/file29083/cleanup-test-collections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Sat Feb 16 07:29:13 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 06:29:13 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360996153.62.0.358213098696.issue16991@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file29083/cleanup-test-collections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Sat Feb 16 07:46:49 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 06:46:49 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1360997209.46.0.612551154755.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

I should clarify, odict.diff passes test_ordereddict.  Regardless, it's pretty close.  I'm going to figure out why the review link hates me on this issue, but until then any extra eyes here would be appreciated.  The memory-related issues are pushing well past my experience.

My goal is to get this in before PyCon and to have a reasonable plan at least for implementing **kwargs as OrderedDict.  My intuition is that writing OrderedDict in C is the hard part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Sat Feb 16 07:51:53 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Sat, 16 Feb 2013 06:51:53 +0000
Subject: [issue9856] Change object.__format__(s) where s is non-empty to a
	TypeError
In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za>
Message-ID: <1360997513.52.0.846633557596.issue9856@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
nosy: +Ankur.Ankan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9856>
_______________________________________

From report at bugs.python.org  Sat Feb 16 11:36:55 2013
From: report at bugs.python.org (Guido Reina)
Date: Sat, 16 Feb 2013 10:36:55 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1361011015.74.0.0305638366627.issue17183@psf.upfronthosting.co.za>


Guido Reina added the comment:

I am attaching a .tgz file with the tests I have performed.

The .tgz file contains also a README.txt file with more detailed information.

I have done the following test:
The script loads the HTML file 'search.html' in 'rawdata' and searches '>' in a loop from the position 'i', being i in: range(len(rawdata)).

with the three variants: "in" + "find" (test1.py), "find" (test2.py), "index" (test3.py).

Result:
Script          First run       Second run      Third run
---------------------------------------------------------
test1.py        2.33            2.32            2.33
test2.py        0.75            0.74            0.76
test3.py        0.75            0.74            0.74


I don't know if the test is representative and whether it helps.
If you think that the test could be improved/changed, just let me know, I will be happy to help.

----------
Added file: http://bugs.python.org/file29084/test.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Sat Feb 16 11:52:39 2013
From: report at bugs.python.org (Mi Zou)
Date: Sat, 16 Feb 2013 10:52:39 +0000
Subject: [issue17214] urllib.client.HTTPConnection.putrequest encode  error
Message-ID: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>


New submission from Mi Zou:

while urllib following the redirection(302):
urllib.client.HTTPConnection.putrequest raise an error:
#----------------------------------------------------------
  File "D:\Program Files\Python32\lib\http\client.py", line 1004, in _send_request
    self.putrequest(method, url, **skips)
  File "D:\Program Files\Python32\lib\http\client.py", line 868, in putrequest
    self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 108-111: ordinal not in range(128)
#----------------------------------------------------------
in the sourcode i found that:
at line 811
def putrequest(self, method, url, skip_host=0,skip_accept_encoding=0)...
the argument url may be a unicode,and it was unquoted..

i think we should replace:
request = '%s %s %s' (method,url,self._http_vsn_str)
with:
import urllib.parse
request = '%s %s %s' (method,urllib.parse.quote(url),self._http_vsn_str)

----------
components: Unicode
messages: 182216
nosy: Mi.Zou, ezio.melotti
priority: normal
severity: normal
status: open
title: urllib.client.HTTPConnection.putrequest encode  error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Feb 16 12:09:37 2013
From: report at bugs.python.org (Sebastian Kraft)
Date: Sat, 16 Feb 2013 11:09:37 +0000
Subject: [issue16525] wave file module does not support 32bit float format
In-Reply-To: <1353528827.37.0.543069044809.issue16525@psf.upfronthosting.co.za>
Message-ID: <1361012977.69.0.179946270358.issue16525@psf.upfronthosting.co.za>


Changes by Sebastian Kraft <sebastian_kraft at gmx.de>:


Removed file: http://bugs.python.org/file28122/wave_float_issue16525.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16525>
_______________________________________

From report at bugs.python.org  Sat Feb 16 12:15:54 2013
From: report at bugs.python.org (Sebastian Kraft)
Date: Sat, 16 Feb 2013 11:15:54 +0000
Subject: [issue16525] wave file module does not support 32bit float format
In-Reply-To: <1353528827.37.0.543069044809.issue16525@psf.upfronthosting.co.za>
Message-ID: <1361013354.5.0.110230499177.issue16525@psf.upfronthosting.co.za>


Sebastian Kraft added the comment:

Thanks for the hint Harvey!
I have updated my patch to include your changes, but only applied the second hunk for the following reasons:

Wave_read should not assume any wave format, as it is expected to open a file during initialization. So actually the only missing thing was the assignment of the wave format during the reading of the format chunk.

setparams() in Wave_write already sets the wavformat a few lines later together with the other parameters. So no need to set it twice...

Can you please check if the updated patch works for you?

----------
Added file: http://bugs.python.org/file29085/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16525>
_______________________________________

From report at bugs.python.org  Sat Feb 16 13:04:22 2013
From: report at bugs.python.org (Mi Zou)
Date: Sat, 16 Feb 2013 12:04:22 +0000
Subject: [issue17214] urllib.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1361016262.41.0.421133420088.issue17214@psf.upfronthosting.co.za>


Changes by Mi Zou <aaasuoliweng at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Feb 16 13:05:08 2013
From: report at bugs.python.org (Mi Zou)
Date: Sat, 16 Feb 2013 12:05:08 +0000
Subject: [issue17214] urllib.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1361016308.99.0.0790854810722.issue17214@psf.upfronthosting.co.za>


Changes by Mi Zou <aaasuoliweng at gmail.com>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Feb 16 13:05:56 2013
From: report at bugs.python.org (Mi Zou)
Date: Sat, 16 Feb 2013 12:05:56 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1361016356.02.0.0974279776123.issue17214@psf.upfronthosting.co.za>


Changes by Mi Zou <aaasuoliweng at gmail.com>:


----------
title: urllib.client.HTTPConnection.putrequest encode  error -> http.client.HTTPConnection.putrequest encode  error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Feb 16 13:30:44 2013
From: report at bugs.python.org (Mi Zou)
Date: Sat, 16 Feb 2013 12:30:44 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1361017844.78.0.75396894765.issue17214@psf.upfronthosting.co.za>


Mi Zou added the comment:

while urllib following the redirection(302):
http.client.HTTPConnection.putrequest raise an error:
#----------------------------------------------------------
...
  File "D:\Program Files\Python32\lib\http\client.py", line 1004, in _send_request
    self.putrequest(method, url, **skips)
  File "D:\Program Files\Python32\lib\http\client.py", line 868, in putrequest
    self._output(request.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 108-111: ordinal not in range(128)
#----------------------------------------------------------
in the sourcode i found that:
at line 811

def putrequest(self, method, url, skip_host=0,skip_accept_en...)
...

the argument url may be a unicode,and it was unquoted..
----------------------------note----------------------------------------
in my case:
...
purl="http://bbs.dospy.com/1111258attachdown.php?aid=14361277&bbsid=349"
req=urllib.request.Request(purl,headers=headers)
response=urllib.request.urlopen(req)
...

then,the http serve redirect me to a file download url...
and the url contains some Chinese word....
i have print out the argument url:

/f/1ba1f70606223af2aa5c3aeff6c6a46a/511f7b4c/day_111015/20111015_5949e996881b2e28403d26Ch6dOfj6LZ.rar/p/????03-08.part1.rar

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat Feb 16 13:59:18 2013
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 16 Feb 2013 12:59:18 +0000
Subject: [issue17215] documentation misprints
Message-ID: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>


New submission from July Tikhonov:

library/io.rst
io.open() signature lacks 'opener' argument.

library/importlib.rst
concreate -> concrete

----------
assignee: docs at python
components: Documentation
files: docs-misprint.diff
keywords: patch
messages: 182219
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: documentation misprints
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29086/docs-misprint.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17215>
_______________________________________

From report at bugs.python.org  Sat Feb 16 14:02:19 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Feb 2013 13:02:19 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <CADiSq7fH-CvFr84vmCmob=UrBGK29QKqrKoAN8HoSazOzPkaxw@mail.gmail.com>
Message-ID: <20130216130221.GA9107@sleipnir.bytereef.org>


Stefan Krah added the comment:

I would be willing to write an (alternative) PEP, but I'm not quite satisfied
with my own proposal yet. Also, I'd need to understand the positional-only
part better, but the _cursesmodule.c example does not seem to compile here. :)

So, *disregarding* the positional-only situation, I've been thinking about
the os.stat example and what I want from the DSL:

1) We already have a partial DSL, namely "O&|$O&p". This is concise,
   unambiguous and well understood.

2) "O&" denotes a custom converter function with a user specified type.
    For example, path_converter() has type [string, bytes, int] -> path_t,
    where [string, bytes, int] are the alternatives that path_converter()
    accepts.

   "p" can be seen as a default converter function with type bool -> int.

3) Specifying the kind (required, etc.) and the default values of arguments
   is most readable in the standard Python form:

     os.stat(path, *, dir_fd=None, follow_symlinks=True) -> stat_result

I've tried to come up with a declaration that merges 2) and 3), while
reusing the existing conversion specifiers. It emphasizes the converter
functions (which ultimately decide the static typing):

/*[preprocessor]
# Declaration
os.stat (
  { path, path_converter : [string, bytes, int] -> path_t },
  *,
  { dir_fd=None, OS_STAT_DIR_FD_CONVERTER : [int, None] -> int },
  { follow_symlinks=True, "p" : bool -> int }
) -> stat_result

# User code
path_t path = PATH_T_INITIALIZE("stat", 0, 1);
int dir_fd = DEFAULT_DIR_FD;
int follow_symlinks = 1;
[preprocessor]*/

The declaration should be read as follows:

Declare os.stat as a function ...

   1) taking the required argument "path", to which the user-supplied function
      path_converter() of type [string, bytes, int] -> path_t will be applied
      for conversion.

   2) taking a keyword-only argument "dir_fd" with the default value None,
      to which the user-supplied function OS_STAT_DIR_FD_CONVERTER() of
      type [int, None] -> int will be applied for conversion.

   3) taking a keyword-only argument "follow_symlinks" with the default
      value True, to which the default converter "p" of type bool -> int
      will be applied for conversion.

... returning stat_result.

The user code section could be type-checked against the declaration.

What are the advantages?

  1) The structure of the Python function is part of the declaration.

  2) AFAICS, using the conversion specifiers directly eliminates the
     need for these flags:

       encoding, length, zeroes, bitwise, nullable, types, keyword-only,
       required, default, converter.

  3) The converter-oriented statically typed spec forces the user to think
     about the types (a good thing IMO).

  4) Due to the rigid structure (better) error messages should be easier
     to produce.

If this sounds like a viable alternative, I can try to write a PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sat Feb 16 14:47:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Feb 2013 13:47:47 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361022467.42.0.394087911135.issue16612@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Stefan, that proposal definitely looks like it is worth writing up as a PEP to me. One thing that I particularly like about it is that it should be possible to pluck out the first element of the {} entries fairly easily in order to get the ordinary Python signature to feed to Cython or a "from string" constructor for signature objects.

As far as the "positional-only" parameters problem goes, at one point Guido was kicking around the idea of allowing "/" as a separator in Python function declarations to indicate positional only arguments. So the signature of a function that didn't accept keyword arguments at all would look like:

    def addch(x, y, ch, attr, /):
        ...

He eventually dropped it because positional only arguments (and the need to avoid colliding with arbitrary keyword arguments) are relatively rare in Python code, and using an inner function together with *args is a reasonable way to get decent error messages. However, as a way of concisely indicating positional-only arguments in the signature of *C* functions, the idea may be worth reconsidering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sat Feb 16 15:05:36 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 16 Feb 2013 14:05:36 +0000
Subject: [issue17215] documentation misprints
In-Reply-To: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>
Message-ID: <1361023536.42.0.62445750828.issue17215@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

LGTM.

----------
nosy: +Ramchandra.Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17215>
_______________________________________

From report at bugs.python.org  Sat Feb 16 15:22:01 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Feb 2013 14:22:01 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361024521.29.0.528229030398.issue16612@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sat Feb 16 15:57:05 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 16 Feb 2013 14:57:05 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
In-Reply-To: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>
Message-ID: <1361026625.63.0.415818854867.issue17211@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Attached is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file29087/issue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Sat Feb 16 15:59:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Feb 2013 14:59:41 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <3Z7ZHw6xCrzQj1@mail.python.org>


Roundup Robot added the comment:

New changeset c1b3d25882ca by Serhiy Storchaka in branch '2.7':
Issue #13169: The maximal repetition number in a regular expression has been
http://hg.python.org/cpython/rev/c1b3d25882ca

New changeset 472a7c652cbd by Serhiy Storchaka in branch '3.2':
Issue #13169: The maximal repetition number in a regular expression has been
http://hg.python.org/cpython/rev/472a7c652cbd

New changeset b78c321ee9a5 by Serhiy Storchaka in branch '3.3':
Issue #13169: The maximal repetition number in a regular expression has been
http://hg.python.org/cpython/rev/b78c321ee9a5

New changeset ca0307905cd7 by Serhiy Storchaka in branch 'default':
Issue #13169: The maximal repetition number in a regular expression has been
http://hg.python.org/cpython/rev/ca0307905cd7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:01:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Feb 2013 15:01:27 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
In-Reply-To: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>
Message-ID: <1361026887.38.0.256453669714.issue17211@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch needs tests.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:07:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 15:07:41 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1361027261.07.0.0255903271535.issue13169@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have committed simplified patches. They don't change an exception type from OverflowError to re.error (but an error message now is more helpful) and don't made the code clever enough to not raise an exception when a repetition number is exceeded sys.maxsize.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:10:32 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 16 Feb 2013 15:10:32 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
In-Reply-To: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>
Message-ID: <1361027432.15.0.16814517911.issue17211@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

I forget about that. Attached is a patch with tests.

----------
Added file: http://bugs.python.org/file29088/issue.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:31:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Feb 2013 15:31:36 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <3Z7b0l49dPzQj1@mail.python.org>


Roundup Robot added the comment:

New changeset c1f846a99c85 by Serhiy Storchaka in branch '3.3':
Issue #17193: Use binary prefixes (KiB, MiB, GiB) for memory units.
http://hg.python.org/cpython/rev/c1f846a99c85

New changeset 73a16d3c066a by Serhiy Storchaka in branch 'default':
Issue #17193: Use binary prefixes (KiB, MiB, GiB) for memory units.
http://hg.python.org/cpython/rev/73a16d3c066a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:34:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 15:34:01 +0000
Subject: [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1361028841.26.0.299851451078.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you, Ezio, for your comments.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17193>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:44:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Feb 2013 15:44:34 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <3Z7bHj3ClHzQlp@mail.python.org>


Roundup Robot added the comment:

New changeset 088a14031998 by Serhiy Storchaka in branch 'default':
Issue #8745: Small speed up zipimport on Windows. Patch by Catalin Iacob.
http://hg.python.org/cpython/rev/088a14031998

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Sat Feb 16 16:49:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 15:49:44 +0000
Subject: [issue17016] _sre: avoid relying on pointer overflow
In-Reply-To: <1358870068.45.0.162917053865.issue17016@psf.upfronthosting.co.za>
Message-ID: <1361029784.87.0.344623355297.issue17016@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nickolai, are you want to update your patch with fixes for other possible pointer overflows? Note, that the maximal repetition number has been increased now.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17016>
_______________________________________

From report at bugs.python.org  Sat Feb 16 17:02:30 2013
From: report at bugs.python.org (uservorname usernachname)
Date: Sat, 16 Feb 2013 16:02:30 +0000
Subject: [issue17216] Could not find platform dependent libraries <exec_prefix>
Message-ID: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>


New submission from uservorname usernachname:

Greetings,

make fails at:
ar rc libpython3.3m.a Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o
ar rc libpython3.3m.a Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o   Python/thread.o Python/frozen.o
ar rc libpython3.3m.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o
ar rc libpython3.3m.a Modules/_threadmodule.o  Modules/signalmodule.o  Modules/posixmodule.o  Modules/errnomodule.o  Modules/pwdmodule.o  Modules/_sre.o  Modules/_codecsmodule.o  Modules/_weakref.o  Modules/_functoolsmodule.o  Modules/operator.o  Modules/_collectionsmodule.o  Modules/itertoolsmodule.o  Modules/_localemodule.o  Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o  Modules/zipimport.o  Modules/faulthandler.o  Modules/symtablemodule.o  Modules/xxsubtype.o
ranlib libpython3.3m.a
gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.3m.a -lpthread -ldl  -lutil   -lm
./python -E -S -m sysconfig --generate-posix-vars
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Could not import runpy module
make: *** [Lib/_sysconfigdata.py] Error 1


What is wrong here? Do you need any other information?

best regards

----------
components: Build
files: config.log
messages: 182232
nosy: uservorname.usernachname
priority: normal
severity: normal
status: open
title: Could not find platform dependent libraries <exec_prefix>
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file29089/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17216>
_______________________________________

From report at bugs.python.org  Sat Feb 16 18:24:02 2013
From: report at bugs.python.org (Ed Campbell)
Date: Sat, 16 Feb 2013 17:24:02 +0000
Subject: [issue15730] Silence unused value warnings under Mac OS X 10.8/clang
In-Reply-To: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za>
Message-ID: <1361035442.43.0.0110774524145.issue15730@psf.upfronthosting.co.za>


Changes by Ed Campbell <drescampbell at gmail.com>:


----------
nosy: +esc24

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15730>
_______________________________________

From report at bugs.python.org  Sat Feb 16 18:33:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Feb 2013 17:33:05 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1361035985.09.0.549093313548.issue15438@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.
(Maybe build the doc and double check that all the links are correct before committing.)

----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sat Feb 16 18:36:03 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 16 Feb 2013 17:36:03 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1361022467.42.0.394087911135.issue16612@psf.upfronthosting.co.za>
Message-ID: <20130216173605.GA14144@sleipnir.bytereef.org>


Stefan Krah added the comment:

OK, I'll have a go at the PEP then. In addition to the proposed syntax
in my previous mail, I'm going to suggest this alternative:

/*[preprocessor]
# Declaration
os.stat [PyOs_Stat] (
  { path: [string, bytes, int] => path_converter => path_t },
  *,
  { dir_fd: [int, None] = None => OS_STAT_DIR_FD_CONVERTER => int },
  { follow_symlinks: bool = True => "p" => int }
) -> stat_result

# User code
path_t path = PATH_T_INITIALIZE("stat", 0, 1);
int dir_fd = DEFAULT_DIR_FD;
int follow_symlinks = 1;
[preprocessor]*/

It's a slight abuse of notation, since it looks like function composition.
The advantage is that the LHS of the first arrow is a complete legal Python
argument spec together with the type annotation.

The construct should be viewed like a Unix pipe and be read somewhat like:

Pass argument dir_fd of type [int, None], initialized to the default value
None to function OS_STAT_DIR_FD_CONVERTER, which yields a C int.

Both versions carry precisely the same amount of information. I have no strong
preference for either version, but perhaps other people do.

Regarding the positional arguments with groups, I'm suggesting this construct
for window.addch():

/*[preprocessor]
# Declaration
window.addch [addch] (
  { y: int => "i" => int },
  { x: int => "i" => int },
  { ch: int => "O" => PyObject * },
  { attr: int => "l" => long }
) -> None

WHERE groups = { [ch], [ch, attr], [y, x, ch], [y, x, ch, attr] }
[preprocessor]*/

The top part is largely the same as in the os.stat() example, the WHERE
clause means:

  - If you pass a single argument, it will be interpreted as "ch"

  - If you pass two arguments, they will be interpreted as "ch, attr"

  [and so forth ...]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sat Feb 16 19:11:25 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 16 Feb 2013 18:11:25 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1361038285.72.0.229884125561.issue16038@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Patch looks ok. Just add the new exception class to all_errors list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sat Feb 16 20:11:19 2013
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Jastrz=C4=99bski?=)
Date: Sat, 16 Feb 2013 19:11:19 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1361041879.74.0.499464911465.issue16038@psf.upfronthosting.co.za>


Micha? Jastrz?bski added the comment:

Thank you Giampaolo,

I'm attaching patch changed according to your suggestion.

----------
Added file: http://bugs.python.org/file29090/ftplib_maxline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sat Feb 16 20:28:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Feb 2013 19:28:50 +0000
Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL
In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za>
Message-ID: <3Z7hGV1SFCzQj1@mail.python.org>


Roundup Robot added the comment:

New changeset dc8a11c16021 by Serhiy Storchaka in branch '2.7':
Issue #9669: Protect re against infinite loops on zero-width matching in
http://hg.python.org/cpython/rev/dc8a11c16021

New changeset d40afd489b6a by Serhiy Storchaka in branch '3.2':
Issue #9669: Protect re against infinite loops on zero-width matching in
http://hg.python.org/cpython/rev/d40afd489b6a

New changeset 8f9b628593db by Serhiy Storchaka in branch '3.3':
Issue #9669: Protect re against infinite loops on zero-width matching in
http://hg.python.org/cpython/rev/8f9b628593db

New changeset aa17a0dab86a by Serhiy Storchaka in branch 'default':
Issue #9669: Protect re against infinite loops on zero-width matching in
http://hg.python.org/cpython/rev/aa17a0dab86a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9669>
_______________________________________

From report at bugs.python.org  Sat Feb 16 21:00:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 20:00:02 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361044802.24.0.0277404633973.issue16612@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>  { path: [string, bytes, int] => path_converter => path_t },
>  *,
>  { dir_fd: [int, None] = None => OS_STAT_DIR_FD_CONVERTER => int },
>  { follow_symlinks: bool = True => "p" => int }

Why not just:

  path: path_t
  *
  dir_fd: dir_fd_t = None => DEFAULT_DIR_FD
  follow_symlinks: bool = True => 1

?

And register types somewhere:

clinic.register('path_t', restype='path_t', converter='path_converter', signature='[string, bytes, int]')
clinic.register('dir_fd_t', restype='int', converter='OS_STAT_DIR_FD_CONVERTER', signature='[int, None]')
clinic.register('bool', restype='int', converter='_PyBool_Converter', signature='bool')
...
clinic.register('string', restype='PyObject *', converter='_PyUnicode_Converter', signature='string')
clinic.register('buffer', restype='PyBuffer', converter='_PyBuffer_Converter', signature='buffer')
...
clinic.register('int', restype='int', converter='_Py_int_Converter', signature='int')
clinic.register('unsigned long', restype='unsigned long', converter='_Py_long_Converter', signature='int')

If you use path_converter, then definitely input types are [string, bytes, int] and an output C type is path_t. You need only name all converters and register them.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sat Feb 16 21:30:09 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 20:30:09 +0000
Subject: [issue10965] dev task of documenting undocumented APIs
In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za>
Message-ID: <1361046609.7.0.616891207721.issue10965@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10965>
_______________________________________

From report at bugs.python.org  Sat Feb 16 21:48:42 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 20:48:42 +0000
Subject: [issue16276] OrderedDict constructor do not keep items order
In-Reply-To: <1350552813.45.0.500801824963.issue16276@psf.upfronthosting.co.za>
Message-ID: <1361047722.42.0.652373371675.issue16276@psf.upfronthosting.co.za>


Eric Snow added the comment:

FWIW, I'm working toward making **kwargs an OrderedDict.  First step: issue #16991

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16276>
_______________________________________

From report at bugs.python.org  Sat Feb 16 22:21:31 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 21:21:31 +0000
Subject: [issue15003] make PyNamespace_New() public
In-Reply-To: <1338864820.17.0.274736612168.issue15003@psf.upfronthosting.co.za>
Message-ID: <1361049691.53.0.148900201597.issue15003@psf.upfronthosting.co.za>


Eric Snow added the comment:

At present, I don't see a need to make the C API public.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15003>
_______________________________________

From report at bugs.python.org  Sat Feb 16 22:54:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 21:54:44 +0000
Subject: [issue8745] zipimport is a bit slow
In-Reply-To: <1274162892.24.0.612432614461.issue8745@psf.upfronthosting.co.za>
Message-ID: <1361051684.65.0.828428283727.issue8745@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for contribution.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8745>
_______________________________________

From report at bugs.python.org  Sat Feb 16 22:58:50 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Feb 2013 21:58:50 +0000
Subject: [issue17216] sparc linux build fails with "could not import runpy
	module"
In-Reply-To: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>
Message-ID: <1361051930.96.0.279517878333.issue17216@psf.upfronthosting.co.za>


Ned Deily added the comment:

For some reason in your build, the first bootstrap use of the compiler (to generate the sysconfig data) is failing because the runpy module can't be found.  Python should be able to find it in the source directory; the "Could not find platform dependent libraries <exec_prefix>" is normal at this point and can be ignored.  I see from your config.log that you do have a lot of configure options set, including some invalid ones (configure:16344: WARNING: unrecognized options: --enable-clocale, --enable-debug).  I suggest you try rebuilding from a freshly untarred source directory with as simple a ./configure as possible and as few environment variables set as possible and see what happens when you run make, something like:

./configure && make

If that fails similarly, please include that whole output from configure through make and the config.log output.

----------
nosy: +ned.deily
title: Could not find platform dependent libraries <exec_prefix> -> sparc linux build fails with "could not import runpy module"
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17216>
_______________________________________

From report at bugs.python.org  Sat Feb 16 22:58:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 21:58:55 +0000
Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL
In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za>
Message-ID: <1361051935.47.0.570188965394.issue9669@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed with a test. Thank you, Matthew.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9669>
_______________________________________

From report at bugs.python.org  Sat Feb 16 22:59:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 21:59:22 +0000
Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL
In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za>
Message-ID: <1361051962.4.0.962323330713.issue9669@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9669>
_______________________________________

From report at bugs.python.org  Sat Feb 16 23:14:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 22:14:01 +0000
Subject: [issue4972] context management support in imaplib, smtplib, ftplib
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1361052841.02.0.319783060725.issue4972@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. Updated documentation, added checks that logout executed after a with statement, now logout() can be called inside a with statement.

----------
Added file: http://bugs.python.org/file29091/imaplib_with_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Sat Feb 16 23:14:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2013 22:14:02 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361052842.08.0.0602893293351.issue14905@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon, ncoghlan
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Sat Feb 16 23:25:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 22:25:51 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361053551.72.0.544938025382.issue14905@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This can significant slowdown zipimport. I think we shouldn't support such broken zip files in zipimport.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Sat Feb 16 23:30:52 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Sat, 16 Feb 2013 22:30:52 +0000
Subject: [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <1361053852.38.0.802573501372.issue17203@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Hi, here's the patch. Should I provide patches for other branches?

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file29092/17203.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17203>
_______________________________________

From report at bugs.python.org  Sat Feb 16 23:48:35 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 16 Feb 2013 22:48:35 +0000
Subject: [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <1361054915.67.0.173382849113.issue17203@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, one patch should be fine, though the change should be applied to all branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17203>
_______________________________________

From report at bugs.python.org  Sun Feb 17 00:02:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 16 Feb 2013 23:02:28 +0000
Subject: [issue17217] Fix test discovery for test_format.py on Windows
Message-ID: <1361055748.87.0.775684522637.issue17217@psf.upfronthosting.co.za>


New submission from Zachary Ware:

test_format is an interesting case in the ongoing test discovery conversion.  It already uses unittest.main(), but still has test_main(), and discovery seems to work fine on Linux.  On Windows, however, test_format and test_non_ascii both fail with a UnicodeEncodeError.  Running under regrtest, this doesn't happen because of regrtest's replace_stdout() function.  Thus, running python -m test.test_format with the following patch works:

diff -r 168efd87e051 Lib/test/test_format.py
--- a/Lib/test/test_format.py   Fri Feb 15 23:38:23 2013 +0200
+++ b/Lib/test/test_format.py   Sat Feb 16 15:14:52 2013 -0600
@@ -325,9 +325,7 @@
         self.assertIs("{0:5s}".format(text), text)


-def test_main():
-    support.run_unittest(FormatTest)
-
-
 if __name__ == "__main__":
+    from test.regrtest import replace_stdout
+    replace_stdout()
     unittest.main()


Doing the same in a setUpModule function would work for both running the module and for a unittest discover command, but it would also cause replace_stdout() to be called twice when running under regrtest, which I don't think would be especially good.

The attached patch is one possible solution that I've come up with.  It moves replace_stdout from regrtest to support, and adds a "running_under_regrtest" flag to support that regrtest sets to True.  test_format then checks support.running_under_regrtest in setUpModule to determine whether to run support.replace_stdout.

----------
components: Tests
files: test_format_discovery.diff
keywords: patch
messages: 182248
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_format.py on Windows
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29093/test_format_discovery.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17217>
_______________________________________

From report at bugs.python.org  Sun Feb 17 00:42:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Feb 2013 23:42:25 +0000
Subject: [issue15022] types.SimpleNamespace needs to be picklable
In-Reply-To: <1339040260.61.0.109712226507.issue15022@psf.upfronthosting.co.za>
Message-ID: <3Z7nv44jhbzRdD@mail.python.org>


Roundup Robot added the comment:

New changeset 3b93ab8c9c20 by Eric Snow in branch 'default':
Issue #15022: Add pickle and comparison support to types.SimpleNamespace.
http://hg.python.org/cpython/rev/3b93ab8c9c20

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15022>
_______________________________________

From report at bugs.python.org  Sun Feb 17 00:46:37 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 16 Feb 2013 23:46:37 +0000
Subject: [issue15022] types.SimpleNamespace needs to be picklable
In-Reply-To: <1339040260.61.0.109712226507.issue15022@psf.upfronthosting.co.za>
Message-ID: <1361058397.9.0.549122200492.issue15022@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15022>
_______________________________________

From report at bugs.python.org  Sun Feb 17 01:09:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Feb 2013 00:09:16 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <3Z7pV33vTYzNbt@mail.python.org>


Roundup Robot added the comment:

New changeset 4e985a96a612 by Antoine Pitrou in branch 'default':
Issue #17170: speed up PyArg_ParseTuple[AndKeywords] a bit.
http://hg.python.org/cpython/rev/4e985a96a612

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Sun Feb 17 01:38:22 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 17 Feb 2013 00:38:22 +0000
Subject: [issue17218] support title and description in argparse
	add_mutually_exclusive_group
Message-ID: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to add to argparse's add_mutually_exclusive_group() method support for passing a title and description.  From the argparse docs:

"Note that currently mutually exclusive argument groups do not support the title and description arguments of add_argument_group()."

(from http://docs.python.org/dev/library/argparse.html#argparse.add_mutually_exclusive_group )

----------
components: Library (Lib)
messages: 182251
nosy: bethard, chris.jerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: support title and description in argparse add_mutually_exclusive_group
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17218>
_______________________________________

From report at bugs.python.org  Sun Feb 17 02:25:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Feb 2013 01:25:49 +0000
Subject: [issue15022] types.SimpleNamespace needs to be picklable
In-Reply-To: <1339040260.61.0.109712226507.issue15022@psf.upfronthosting.co.za>
Message-ID: <3Z7rBM3hMDzRd6@mail.python.org>


Roundup Robot added the comment:

New changeset e4c065b2db49 by Eric Snow in branch 'default':
Issue #15022: Ensure all pickle protocols are supported.
http://hg.python.org/cpython/rev/e4c065b2db49

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15022>
_______________________________________

From report at bugs.python.org  Sun Feb 17 03:08:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 02:08:18 +0000
Subject: [issue15004] add weakref support to types.SimpleNamespace
In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>
Message-ID: <1361066898.75.0.464576206432.issue15004@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've yanked the __weakref__ attr--apparently builtins don't have them.  I've also update the test.  Is the updated test sufficient?  I expect that if weakref.ref(ns) works, the rest of the weakref functionality works as well.

----------
Added file: http://bugs.python.org/file29094/simplenamespace-weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15004>
_______________________________________

From report at bugs.python.org  Sun Feb 17 03:29:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Feb 2013 02:29:44 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361068184.19.0.670872682922.issue14905@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

How common are such broken zip files? Like Serhiy, I'm concerned about the possible negative impact on the interpreter startup time as we try to second guess the contents of the zip file manifest.

It seems better to be explicit that we consider such zipfiles broken and they need to be regenerated with full manifests (perhaps providing a script in Tools that fixes them).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Sun Feb 17 03:31:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Feb 2013 02:31:36 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361068296.95.0.529773288549.issue14905@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OTOH, the scan time should be short relative to the time needed to read the manifest in the first place - an appropriate microbenchmark may also be adequate to address my concerns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Sun Feb 17 03:34:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Feb 2013 02:34:06 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1361068446.32.0.273648120868.issue16042@psf.upfronthosting.co.za>


R. David Murray added the comment:

I doubt that 2048 is safer than 1024 for any meaningful value of safer.  Either the sever respects the rfc limits or it does not.  If it does not,  it is likely to send very long text lines if the sending mua generates them, which I suspect happens.  However, there is no real reason not to arbitrarily pick 2048.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sun Feb 17 03:42:38 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 02:42:38 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1361068958.18.0.974181514073.issue13124@psf.upfronthosting.co.za>


Eric Snow added the comment:

Looking this over, it seems like there were outstanding objections to adding this to the devguide and to the content.  I still think the devguide is the right place and that something like my second patch would be appropriate.

Before I take any time to update the patch, does anyone object to the location or intent of the changes?

Also, I'm fine with adapting/incorporating or linking to Stefan's script.  The whole point is to make it as easy as possible to spin up and run a build slave. :)

----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Sun Feb 17 04:47:46 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 03:47:46 +0000
Subject: [issue16251] pickle special methods are looked up on the instance
	rather than the type
In-Reply-To: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za>
Message-ID: <1361072866.45.0.525145599626.issue16251@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've posted to python-dev about this:

http://mail.python.org/pipermail/python-dev/2013-February/124114.html

At the very least the pickle docs deserve some mention of the behavior.  That way people won't need to spend as much time trying to figure out why things aren't working the way they expect.

However, my preference is to fix pickle, though I readily concede that might not be possible.  And just to reiterate, I agree we shouldn't do anything here without a clear picture of the impact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16251>
_______________________________________

From report at bugs.python.org  Sun Feb 17 05:09:50 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 04:09:50 +0000
Subject: [issue12633] sys.modules doc entry should reflect restrictions
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1361074190.1.0.135459665141.issue12633@psf.upfronthosting.co.za>


Eric Snow added the comment:

One proposal would lead to the sys module growing descriptors:

http://mail.python.org/pipermail/python-ideas/2013-January/019075.html

In that case, sys.modules could update the underlying interp->modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12633>
_______________________________________

From report at bugs.python.org  Sun Feb 17 05:18:03 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 04:18:03 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361074683.31.0.132562644867.issue15767@psf.upfronthosting.co.za>


Eric Snow added the comment:

+1 on just getting it done with ModuleNotFoundError.  FWIW, I'd be glad to do it.  I'm taking a self-imposed break from the nearly finished C-OrderedDict!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Sun Feb 17 06:22:32 2013
From: report at bugs.python.org (David Lam)
Date: Sun, 17 Feb 2013 05:22:32 +0000
Subject: [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1361078552.22.0.320453579799.issue16954@psf.upfronthosting.co.za>


David Lam added the comment:

Here's a patch which converts all the Doxygen comments in ElementTree.py to docstrings!

Something I noticed was that the 

  from _elementtree import *

...at the bottom of ElementTree.py sort of overwrites the docstrings of the Python module.  So if you did...  `from xml.etree import ElementTree;  help(ElementTree)` from the interpreter, you'll see blank spots for a bunch of classes/methods like Element, ParseError, SubElement etc etc

maybe docstrings should be also added in Modules/_elementtree.c?  perhaps that would be too much copy and pastage, hmmm

----------
keywords: +patch
Added file: http://bugs.python.org/file29095/issue16954.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16954>
_______________________________________

From report at bugs.python.org  Sun Feb 17 06:59:38 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 17 Feb 2013 05:59:38 +0000
Subject: [issue17159] Remove explicit type check from
	inspect.Signature.from_function()
In-Reply-To: <1360336830.78.0.208941087191.issue17159@psf.upfronthosting.co.za>
Message-ID: <1361080778.22.0.19653238374.issue17159@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Updated patch to also fix a little typo in the docstring (lower case "python").

----------
Added file: http://bugs.python.org/file29096/inspect_sig_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17159>
_______________________________________

From report at bugs.python.org  Sun Feb 17 10:44:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 09:44:32 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361094272.62.0.236849632554.issue15767@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

from foo import bar

Here bar can be not module, but an attribute of foo (for example, os.path). What error will be raised in this case? Module or attribute - this is an implementation detail; why do we distinguish between these cases?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Sun Feb 17 11:45:49 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Feb 2013 10:45:49 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1361068958.18.0.974181514073.issue13124@psf.upfronthosting.co.za>
Message-ID: <20130217104549.GA31810@sleipnir.bytereef.org>


Stefan Krah added the comment:

Eric Snow <report at bugs.python.org> wrote:
> Looking this over, it seems like there were outstanding objections to adding this to the devguide and to the content.

I have no issues with the content of the second patch. However, snakebite
has changed the situation a little: We don't need more buildbots, we need
experts in AIX and HP-UX.

For DragonFlyBSD, NetBSD and OpenBSD we'd ideally need someone who reports the
OS bugs (there are a couple) upstream so that the bots finally turn green and
become useful.

So on fact the first paragraph of the patch is now a little outdated.

Given the current situation I think it would be more useful to add

http://mail.python.org/pipermail/python-dev/2012-September/121651.html

to the devguide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Sun Feb 17 11:50:40 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Feb 2013 10:50:40 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361098240.66.0.48128408359.issue17044@psf.upfronthosting.co.za>


Daniel Urban added the comment:

Thanks for the grammar correction, I've fixed it in the new patch.

The new patch also adds object.__init_class__ (which is a no-op), to support cooperative multiple inheritance of __init_class__. (Adding type.__init_class__ was mentioned in the python-dev discussion, but that is not sufficient, so I've added this method to object instead of type.)

Tests are also updated. I'll update the docs, if this change is OK.

----------
Added file: http://bugs.python.org/file29097/pep422_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 11:57:36 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Feb 2013 10:57:36 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361098656.65.0.0728053022536.issue17044@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


Removed file: http://bugs.python.org/file29097/pep422_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 11:58:17 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Feb 2013 10:58:17 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361098697.65.0.175131618462.issue17044@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


Added file: http://bugs.python.org/file29098/pep422_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 12:47:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Feb 2013 11:47:49 +0000
Subject: [issue15004] add weakref support to types.SimpleNamespace
In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>
Message-ID: <1361101669.11.0.568206344137.issue15004@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

No, you should also test the weakref returns None once the object is garbage collected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15004>
_______________________________________

From report at bugs.python.org  Sun Feb 17 12:50:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Feb 2013 11:50:24 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361101824.17.0.00808700693683.issue17044@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, I think I see your point - because __init_class__ is supposed to be a class method on instances of the metaclass, the anchor needs to be on object (the highest level instance of the default metaclass), not on type if we don't want super to behave strangely?

I think that's a valid conclusion (albeit a very subtle difference relative to an ordinary method on type), and compared to the tapdancing we do in __new__ and __init__ to help them be valid anchors for cooperative multiple inheritance, adding object.__init_class__ is a relatively minor thing.

If you wanted to propose a patch to the PEP as well, that would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 13:38:34 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Feb 2013 12:38:34 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1361044802.24.0.0277404633973.issue16612@psf.upfronthosting.co.za>
Message-ID: <20130217123835.GA32546@sleipnir.bytereef.org>


Stefan Krah added the comment:

Serhiy Storchaka <report at bugs.python.org> wrote:
> >  { path: [string, bytes, int] => path_converter => path_t },
>
> And register types somewhere:

I must admit that I had a similar thought when I first heard about the project:
If we're going through all this anyway, why not have a registry with signatures
and type annotations for all functions?

But since we're dealing with C files, intuitively I think it's better to stick
to C conventions.

Imagine that the preprocessor had full-blown C parser support, so we could
declare:

  static int
  path_converter(/* [string, bytes, int] */ PyObject *o, void *p) {

Later we tell the preprocessor to generate a function taking an argument "path"
of type [string, bytes, int] that will be passed on to path_converter().

In the absence of type inference, it feels natural to me to declare the
type in both places.

What *is* a problem is that we need some discipline in case the type of
path_converter() changes at some point, since the C compiler won't know
about [string, bytes, int].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sun Feb 17 14:59:26 2013
From: report at bugs.python.org (uservorname usernachname)
Date: Sun, 17 Feb 2013 13:59:26 +0000
Subject: [issue17216] sparc linux build fails with "could not import runpy
	module"
In-Reply-To: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>
Message-ID: <1361109566.8.0.342432630999.issue17216@psf.upfronthosting.co.za>


uservorname usernachname added the comment:

Thanks for your hint. I did:
./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --bindir=/usr  --sysconfdir=/etc --sbindir=/usr/sbin/ & make 2>&1 | tee build-log.txt

and get:

gcc -pthread -fPIC -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -I/c/backup/fes-a120d19nas/Python-3.3.0/Include -I/c/backup/fes-a120d19nas/Python-3.3.0 -c /c/backup/fes-a120d19nas/Python-3.3.0/Modules/_hashopenssl.c -o build/temp.linux-padre-3.3/c/backup/fes-a120d19nas/Python-3.3.0/Modules/_hashopenssl.o
gcc -pthread -shared build/temp.linux-padre-3.3/c/backup/fes-a120d19nas/Python-3.3.0/Modules/_hashopenssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-padre-3.3/_hashlib.cpython-33m.so
make: *** [sharedmods] Error 138

I also tried to compile with ./configure --build=sparc-linux but it results in getting the same make error.

Maybe it have to do something with uname --m
padre
?
When compiling other programs I have to set build=sparc-linux But as you can see its using here  linux-padre. Also gcc is using sparc-unkown-linux

If you need any other information let me know it.

----------
Added file: http://bugs.python.org/file29099/config.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17216>
_______________________________________

From report at bugs.python.org  Sun Feb 17 15:03:00 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 17 Feb 2013 14:03:00 +0000
Subject: [issue17191] pdb list shows unexpected code when stack frame includes
	a try / finally block
In-Reply-To: <1360666057.12.0.723928905172.issue17191@psf.upfronthosting.co.za>
Message-ID: <1361109780.62.0.777786996202.issue17191@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This is fixed in python 3.2 by changeset 670d4cbf1464, and indeed the
'>>' marker is shown at line 8 of pdb_list_bug_reproduce.py when
debugging this (modified for py3) script with python 3.2.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17191>
_______________________________________

From report at bugs.python.org  Sun Feb 17 15:43:55 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Feb 2013 14:43:55 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361112235.88.0.0382764795675.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Eric: knock yourself out. =)

Serhiy: What exception is raised in that situation is controlled by the eval loop, not importlib so that would be a separate change. But regardless, there is no way to infer whether you expected an attribute or module to be there, just that you were after something that didn't exist. But I would argue most people import at the module level and not the attribute level, and so raising an ModuleNotFoundError would be acceptable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Sun Feb 17 15:56:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Feb 2013 14:56:39 +0000
Subject: [issue17215] documentation misprints
In-Reply-To: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>
Message-ID: <3Z8B9y4qgBzSfT@mail.python.org>


Roundup Robot added the comment:

New changeset 8c7719b06ba6 by Andrew Svetlov in branch '3.3':
Issue #17215: Fix documentation misprints (patch by July Tikhonov)
http://hg.python.org/cpython/rev/8c7719b06ba6

New changeset 627ebd001708 by Andrew Svetlov in branch 'default':
Issue #17215: Fix documentation misprints (patch by July Tikhonov)
http://hg.python.org/cpython/rev/627ebd001708

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17215>
_______________________________________

From report at bugs.python.org  Sun Feb 17 15:58:29 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 17 Feb 2013 14:58:29 +0000
Subject: [issue17215] documentation misprints
In-Reply-To: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>
Message-ID: <1361113109.04.0.822619092148.issue17215@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. July, would you fill Licence agreement http://www.python.org/psf/contrib/?

----------
nosy: +asvetlov
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17215>
_______________________________________

From report at bugs.python.org  Sun Feb 17 16:27:27 2013
From: report at bugs.python.org (uservorname usernachname)
Date: Sun, 17 Feb 2013 15:27:27 +0000
Subject: [issue17216] sparc linux build fails with "could not import runpy
	module"
In-Reply-To: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>
Message-ID: <1361114847.17.0.708719091448.issue17216@psf.upfronthosting.co.za>


uservorname usernachname added the comment:

I also tried to compile with

./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --bindir=/usr  --sysconfdir=/etc --sbindir=/usr/sbin/ --build=sparc-linux --libdir=/usr/lib --includedir=/usr/include --datarootdir=/usr/share --localedir=/usr/local --host=sparc-linux
which results in the same error. Strange is that i set libdir but it seems that is using /usr/local/lib instead of /usr/lib

Attached you will find the output of make ( make 2>&1 | tee build-log.txt )

----------
Added file: http://bugs.python.org/file29100/build-log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17216>
_______________________________________

From report at bugs.python.org  Sun Feb 17 16:45:19 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Feb 2013 15:45:19 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361115919.16.0.540491416316.issue17044@psf.upfronthosting.co.za>


Daniel Urban added the comment:

Yes, if we would add a regular (instance) method __init_class__ to type, it could (probably) work for regular (non-meta) classes, but not for metaclasses.  If a metaclass Meta wouldn't define __init_class__ itself, calling Meta.__init_class__() in __build_class__ wouldn't work, since Meta would inherit the *instance* method from type (its superclass).  We might be able to make this work somehow (I'm not sure), but I think adding it to object as a classmethod works fine, and doesn't require special casing.

The attached patch documents, that object has an __init_class__ (and also adds some extra tests). I'll attach a patch to the PEP as well.

----------
Added file: http://bugs.python.org/file29101/pep422_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 16:46:17 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 17 Feb 2013 15:46:17 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361115977.58.0.673062954163.issue17044@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


Added file: http://bugs.python.org/file29102/pep422.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 16:52:37 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 17 Feb 2013 15:52:37 +0000
Subject: [issue17211] pkgutil.iter_modules and walk_packages should return a
	namedtuple
In-Reply-To: <1360935610.51.0.788015716935.issue17211@psf.upfronthosting.co.za>
Message-ID: <1361116357.14.0.504799272917.issue17211@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Please review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17211>
_______________________________________

From report at bugs.python.org  Sun Feb 17 17:31:31 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 17 Feb 2013 16:31:31 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1361118691.72.0.401892365095.issue12641@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

Hi Matthias,

This issue is only for windows.
In scope autotool based builds compiler customization is used to 'transfer' some build settings (flags, options)  to distutils. This include compiler set in make macro (variable) CC.

Transfer is not complete but this is distutils issue out of scope here.

P.S.
(uploaded a patch to avoid syntax warning)

----------
Added file: http://bugs.python.org/file29103/0001-MINGW-issue12641-avoid-syntax-warning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sun Feb 17 17:42:40 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 17 Feb 2013 16:42:40 +0000
Subject: [issue17219] cross add Python's library directory when building
	python standard extensions
Message-ID: <1361119360.59.0.341690353599.issue17219@psf.upfronthosting.co.za>


New submission from Roumen Petrov:

For native build distutils add current directory to library path. This is not activated in case of cross-build.

Before , as part of issue3871 and issue15483, was updated setup.py , but now I would like to propose a simple more general solution with attached patch.

----------
components: Build
files: 0001-cross-add-current-dir-in-library-path-if-building-py.patch
keywords: patch
messages: 182278
nosy: doko, rpetrov
priority: normal
severity: normal
status: open
title: cross add Python's library directory when building python standard extensions
versions: Python 3.4
Added file: http://bugs.python.org/file29104/0001-cross-add-current-dir-in-library-path-if-building-py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17219>
_______________________________________

From report at bugs.python.org  Sun Feb 17 17:48:07 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 17 Feb 2013 16:48:07 +0000
Subject: [issue17219] cross add Python's library directory when building
	python standard extensions
In-Reply-To: <1361119360.59.0.341690353599.issue17219@psf.upfronthosting.co.za>
Message-ID: <1361119687.8.0.517241730277.issue17219@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


----------
components: +Cross-Build -Build
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17219>
_______________________________________

From report at bugs.python.org  Sun Feb 17 18:26:09 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Feb 2013 17:26:09 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361121969.91.0.636539294066.issue14905@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I don't think such files are common: I've never seen such a file "in the wild". I created one, by accident, while testing PEP 420.

OTOH, it was surprisingly easy to create the malformed file with zipfile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Sun Feb 17 18:50:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 17:50:23 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
Message-ID: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch a little cleans and optimizes some bits of _bootstrap.py.

----------
components: Interpreter Core
files: _bootstrap.diff
keywords: patch
messages: 182280
nosy: brett.cannon, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Little enhancements of _bootstrap.py
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29105/_bootstrap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Sun Feb 17 19:50:04 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 17 Feb 2013 18:50:04 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>
Message-ID: <1361127004.81.0.0980379858569.issue17197@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Of course you're right. I didn't realize that.
How about this (in attachment)?

----------
keywords: +patch
Added file: http://bugs.python.org/file29106/profile-refactoring.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Sun Feb 17 21:57:13 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 20:57:13 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361134633.77.0.382722493004.issue17220@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Sun Feb 17 21:57:59 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 20:57:59 +0000
Subject: [issue17219] cross add Python's library directory when building
	python standard extensions
In-Reply-To: <1361119360.59.0.341690353599.issue17219@psf.upfronthosting.co.za>
Message-ID: <1361134679.63.0.602195428924.issue17219@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17219>
_______________________________________

From report at bugs.python.org  Sun Feb 17 21:59:31 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 20:59:31 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361134771.16.0.379365292032.issue17044@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17044>
_______________________________________

From report at bugs.python.org  Sun Feb 17 22:01:15 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 21:01:15 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361134875.96.0.862042720034.issue15767@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Sun Feb 17 22:15:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 21:15:42 +0000
Subject: [issue17221] Resort Misc/NEWS
Message-ID: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch moves some Misc/NEWS entities to more appropriate sections (IDLE, C-API, Tests, Documentation, Tools/Demos). Please review.

----------
assignee: docs at python
components: Documentation
files: NEWS-3.4.patch
keywords: patch
messages: 182282
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Resort Misc/NEWS
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29107/NEWS-3.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Sun Feb 17 22:23:44 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 21:23:44 +0000
Subject: [issue17222] py_compile.compile() replaces target files,
	breaking special files and symlinks
Message-ID: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Since d4eb02b6aac9 py_compile.compile() replaces target files, breaking special files and symlinks. Any custom permissions set on target files are also lost. This is a major regression.

# cd /tmp
# touch test.py
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 17 21:16 /dev/null
# python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="/dev/null")'
# ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Feb 17 21:16 /dev/null
# python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="/dev/null")'
# ls -l /dev/null
-rw-r----- 1 root root 102 Feb 17 21:53 /dev/null

----------
messages: 182283
nosy: Arfrever, brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
status: open
title: py_compile.compile() replaces target files, breaking special files and symlinks
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Sun Feb 17 22:27:54 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Feb 2013 21:27:54 +0000
Subject: [issue17216] sparc linux build fails with "could not import runpy
	module"
In-Reply-To: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>
Message-ID: <1361136474.0.0.450381334424.issue17216@psf.upfronthosting.co.za>


Ned Deily added the comment:

I'm glad you got a little further.  Now it seems the build is failing when trying to build the _ssl and _hashlib extension modules.

building '_ssl' extension
gcc -pthread -fPIC -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -I/c/backup/fes-a120d19nas/Python-3.3.0/Include -I/c/backup/fes-a120d19nas/Python-3.3.0 -c /c/backup/fes-a120d19nas/Python-3.3.0/Modules/_ssl.c -o build/temp.linux-padre-3.3/c/backup/fes-a120d19nas/Python-3.3.0/Modules/_ssl.o
gcc -pthread -shared build/temp.linux-padre-3.3/c/backup/fes-a120d19nas/Python-3.3.0/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-padre-3.3/_ssl.cpython-33m.so
*** WARNING: renaming "_ssl" since importing it failed: build/lib.linux-padre-3.3/_ssl.cpython-33m.so: undefined symbol: time, version key
building '_hashlib' extension
gcc -pthread -fPIC -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -I/c/backup/fes-a120d19nas/Python-3.3.0/Include -I/c/backup/fes-a120d19nas/Python-3.3.0 -c /c/backup/fes-a120d19nas/Python-3.3.0/Modules/_hashopenssl.c -o build/temp.linux-padre-3.3/c/backup/fes-a120d19nas/Python-3.3.0/Modules/_hashopenssl.o
gcc -pthread -shared build/temp.linux-padre-3.3/c/backup/fes-a120d19nas/Python-3.3.0/Modules/_hashopenssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.linux-padre-3.3/_hashlib.cpython-33m.so
make: *** [sharedmods] Error 138

Both of these modules are dependent on libssl and libcrypto, both normally supplied by openssl.  In the main setup.py file which is used to build the interpreter's extension modules, there are tests for the presence of these libs and their corresponding include files (setup.py line 759).  There are a list of locations that are searched including the standard system locations and /usr/local/ssl and /usr/contrib/ssl.  Apparently, setup.py is finding both includes and libs in one of those directories because otherwise it would skip attempting to build _ssl altogether.  But for some reason the link step fails with the undefined symbol message.  And then it seems that the _hashlib step fails altogether.  I have no personal experience with sparc linux installs, much less with the ReadyNAS (and I doubt anyone else here does either), so I can only speculate that the most likely cause of this failure is a broken openssl installation.  I'd check the above locations as well as under /usr/lib and /usr/include.  If you are using a package manager to install openssl, make sure it is a dev version with headers, like libssl-dev.  Good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17216>
_______________________________________

From report at bugs.python.org  Sun Feb 17 22:32:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 21:32:46 +0000
Subject: [issue17012] Differences between /usr/bin/which and shutil.which()
In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za>
Message-ID: <1361136766.16.0.923469007881.issue17012@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17012>
_______________________________________

From report at bugs.python.org  Sun Feb 17 22:34:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 21:34:45 +0000
Subject: [issue16551] Cleanup the pure Python pickle implementation
In-Reply-To: <1353845856.16.0.80578311869.issue16551@psf.upfronthosting.co.za>
Message-ID: <1361136885.65.0.252602606777.issue16551@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16551>
_______________________________________

From report at bugs.python.org  Sun Feb 17 23:07:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Feb 2013 22:07:38 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361138858.64.0.929200003262.issue17221@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

unittest is a library, not a part of the test suite, so its enhancements should remain in the library section.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Sun Feb 17 23:08:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Feb 2013 22:08:20 +0000
Subject: [issue17212] os.path.isfile() in Python 3.3 sometimes fails
In-Reply-To: <1360968598.97.0.73683430526.issue17212@psf.upfronthosting.co.za>
Message-ID: <1361138900.94.0.659698208577.issue17212@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17212>
_______________________________________

From report at bugs.python.org  Sun Feb 17 23:24:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Feb 2013 22:24:16 +0000
Subject: [issue17212] os.path.isfile() in Python 3.3 sometimes fails
In-Reply-To: <1361138900.96.0.899859641524.issue17212@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYLU1kvL2cSRRJZh59bKLrTFkVXkaSvfvaKbT2io--6xQ@mail.gmail.com>


STINNER Victor added the comment:

Looks like a duplicate of issue #17137.
Le 17 f?vr. 2013 23:08, "Antoine Pitrou" <report at bugs.python.org> a ?crit :

>
> Changes by Antoine Pitrou <pitrou at free.fr>:
>
>
> ----------
> nosy: +haypo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17212>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17212>
_______________________________________

From report at bugs.python.org  Sun Feb 17 23:27:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 22:27:33 +0000
Subject: [issue12596] cPickle - stored data differ for same dictionary
In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za>
Message-ID: <1361140053.47.0.872513736116.issue12596@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a minimal reproducer. Results:

pickle.dumps('spam', 2)
    0: \x80 PROTO      2
    2: U    SHORT_BINSTRING 'spam'
    8: q    BINPUT     0
   10: .    STOP
highest protocol among opcodes = 2

pickle.dumps('spam1'[:-1], 2)
    0: \x80 PROTO      2
    2: U    SHORT_BINSTRING 'spam'
    8: q    BINPUT     0
   10: .    STOP
highest protocol among opcodes = 2

cPickle.dumps('spam', 2)
    0: \x80 PROTO      2
    2: U    SHORT_BINSTRING 'spam'
    8: q    BINPUT     1
   10: .    STOP
highest protocol among opcodes = 2

cPickle.dumps('spam1'[:-1], 2)
    0: \x80 PROTO      2
    2: U    SHORT_BINSTRING 'spam'
    8: .    STOP
highest protocol among opcodes = 2

The difference between 3rd and 4th examples is "BINPUT 1". In the last case the string has refcount=1 and BINPUT doesn't emitted due to optimization. Note that Python implementation emits BINPUT with different number.

----------
Added file: http://bugs.python.org/file29108/cPickletest2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12596>
_______________________________________

From report at bugs.python.org  Sun Feb 17 23:30:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 22:30:24 +0000
Subject: [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1361140224.93.0.944144187459.issue17047@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17047>
_______________________________________

From report at bugs.python.org  Mon Feb 18 00:44:39 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 17 Feb 2013 23:44:39 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1361144679.1.0.975731627878.issue13169@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Some third-party modules (e.g. epydoc) refer to sre_constants.MAXREPEAT.
Please add 'from _sre import MAXREPEAT' to Lib/sre_constants.py for compatibility.

----------
nosy: +Arfrever
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Mon Feb 18 00:45:05 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Sun, 17 Feb 2013 23:45:05 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
Message-ID: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>


New submission from Manuel Jacob:

>>> from array import array
>>> str(array('u', b'asdf'))
[1]    19411 segmentation fault (core dumped)  python

This error occures with Python 3.3 and hg tip but not with Python 3.2.

----------
components: Library (Lib), Unicode
messages: 182291
nosy: ezio.melotti, mjacob
priority: normal
severity: normal
status: open
title: Initializing array.array with unicode type code and buffer segfaults
type: crash
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 01:55:22 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Mon, 18 Feb 2013 00:55:22 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361148922.84.0.597866709805.issue17223@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

The attached patch fixes the crash.

Output:
>>> from array import array
>>> str(array('u', b'asdf'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: character U+66647361 is not in range [U+0000; U+10ffff]

----------
keywords: +patch
Added file: http://bugs.python.org/file29109/issue17223.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 02:02:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Feb 2013 01:02:43 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361149363.28.0.86551956254.issue17223@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 02:04:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Feb 2013 01:04:56 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361149496.39.0.869409015837.issue17223@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the report and the patch.
Could you also include a test for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 02:33:16 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Mon, 18 Feb 2013 01:33:16 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361151196.58.0.842150610711.issue17223@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

I've attached a new patch with a test that segfaults on Python 3.3 and passes on hg tip with the patch applied.

----------
Added file: http://bugs.python.org/file29110/issue17223_with_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 05:18:29 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 04:18:29 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361161109.86.0.357258510375.issue17221@psf.upfronthosting.co.za>


Ned Deily added the comment:

kbk has requested in the past that IDLE News items be put in Lib/idlelib/News.txt because it is installed with IDLE and there is a button to display it included in the "About IDLE" window.  I know we've not been diligent about doing that, at least, I haven't.  I suppose the items could continue to be put in Misc/NEWS and, prior to each release, copied into the News.txt.  That step could be added to the release manager's checklist.  But, if there are IDLE items in Misc/NEWS, whether duplicated or not, I agree it would be better to have them in their own section.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 05:46:15 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 18 Feb 2013 04:46:15 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361162775.95.0.275897891419.issue6975@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

The above revisions have broken handling of arguments with >=2 "..".

Before these revisions:

$ cd /usr/bin
$ python3.2 -c 'import os; print(os.path.realpath(".."))'
/usr
$ python3.2 -c 'import os; print(os.path.realpath("../.."))'
/
$ python3.2 -c 'import os; print(os.path.realpath("../../.."))'
/
$ python3.2 -c 'import os; print(os.path.realpath("../../../.."))'

After these revisions:

$ cd /usr/bin
$ python3.2 -c 'import os; print(os.path.realpath(".."))'
/usr
$ python3.2 -c 'import os; print(os.path.realpath("../.."))'
/usr/bin
$ python3.2 -c 'import os; print(os.path.realpath("../../.."))'
/usr
$ python3.2 -c 'import os; print(os.path.realpath("../../../.."))'
/usr/bin

----------
nosy: +Arfrever, benjamin.peterson, larry
priority: normal -> release blocker
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Mon Feb 18 05:48:57 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 18 Feb 2013 04:48:57 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361162937.99.0.666360539792.issue6975@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

The actual output of last command in "Before these revisions:" is: /

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Mon Feb 18 05:59:11 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Feb 2013 04:59:11 +0000
Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361163550.99.0.11745719749.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Actually, I have an objection myself.  In merging this patch with another I'm working on, I noticed that I failed to include the new 'idledoc' target in the Makefile usage message.  The attached patch fixes that oversight.

----------
Added file: http://bugs.python.org/file29111/issue16893_makefiles.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16893>
_______________________________________

From report at bugs.python.org  Mon Feb 18 07:13:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Feb 2013 06:13:58 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361168038.85.0.583135653542.issue17223@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 07:15:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Feb 2013 06:15:45 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361168145.13.0.645621498613.issue17223@psf.upfronthosting.co.za>


STINNER Victor added the comment:

issue17223_with_test.diff looks good to me (we may just drop {...} around return NULL).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 08:04:24 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 07:04:24 +0000
Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361171064.28.0.872634240334.issue16893@psf.upfronthosting.co.za>


Ned Deily added the comment:

There are a few problems with the proposed patch (v2).  I commented on those in Rietveld.  But, beyond that, I'm not convinced that the generated help.txt is an improvement over the original help.txt.  While it is formatted more consistently (a good thing), it is significantly longer (547 lines vs 369).  Some info is lost in the translation, for one, the menu div bars (---).  Some of the markup looks odd to me as plain text, for example:

    Upon startup with the ``-s`` option, IDLE will execute the file
    referenced by the environment variables ``IDLESTARTUP`` or
    ``PYTHONSTARTUP``. IDLE first checks for ``IDLESTARTUP``; if
    ``IDLESTARTUP`` is present the file referenced is run.  If 
    ``IDLESTARTUP`` is not present, IDLE checks for ``PYTHONSTARTUP``.

Also, I noticed that the deprecation notice, about running without a subprocess, near the end of the help text seems to be missing from the .rst.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16893>
_______________________________________

From report at bugs.python.org  Mon Feb 18 08:06:37 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 07:06:37 +0000
Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361171197.42.0.148509169189.issue16893@psf.upfronthosting.co.za>


Ned Deily added the comment:

For comparison, here's a copy of the new rendered help.txt.

----------
Added file: http://bugs.python.org/file29112/help.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16893>
_______________________________________

From report at bugs.python.org  Mon Feb 18 08:52:37 2013
From: report at bugs.python.org (Yariv)
Date: Mon, 18 Feb 2013 07:52:37 +0000
Subject: [issue15435] Strange behavior when AttributeError raise inside a
	property get function
In-Reply-To: <1343060813.45.0.564529215103.issue15435@psf.upfronthosting.co.za>
Message-ID: <1361173957.81.0.775672152861.issue15435@psf.upfronthosting.co.za>


Yariv added the comment:

Duplicate of http://bugs.python.org/issue1615 , which is open.

----------
nosy: +Yariv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15435>
_______________________________________

From report at bugs.python.org  Mon Feb 18 09:06:39 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 08:06:39 +0000
Subject: [issue17012] Differences between /usr/bin/which and shutil.which()
In-Reply-To: <1358856840.71.0.975366262743.issue17012@psf.upfronthosting.co.za>
Message-ID: <1361174799.14.0.608178568402.issue17012@psf.upfronthosting.co.za>


Ned Deily added the comment:

The result of PATH= is also platform dependent. Testing on OS X which has a BSD heritage rather a Linux one:

$ PATH= /usr/bin/which python
./python

# without patch
$ PATH= ./python -c 'import shutil; print(shutil.which("python"))'
python
$ ./python -c 'import shutil; print(shutil.which("python", path=""))'
/usr/bin/python

# with the patch:
$ PATH= ./python -c 'import shutil; print(shutil.which("python"))'
None
$ ./python -c 'import shutil; print(shutil.which("python", path=""))'
None

So, for OS X, shutil.which doesn't match /usr/bin/which behavior for the PATH= case either with or without the patch.  FreeBSD (8.2) /usr/bin/which is the same.  The other cases are the same as Linux.

I suppose the patched behavior is preferable, though.

In any case, the shutil.which docs also need to be updated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17012>
_______________________________________

From report at bugs.python.org  Mon Feb 18 09:14:21 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 18 Feb 2013 08:14:21 +0000
Subject: [issue17179] Misleading error from type() when passing unknown
	keyword argument
In-Reply-To: <1360991112.28.0.120316277499.issue17179@psf.upfronthosting.co.za>
Message-ID: <5121D8AD.7010506@simplistix.co.uk>


Chris Withers added the comment:

Some background: I hit this problem when adding Python 3 compatibility 
to one of my libraries, where I had the following code:

from types import ClassType
...
class_ = ClassType(n, (sometype, ), dict(class_attr1='foo', 
class_attr2='bar')

It wasn't at all clear how to port this to Python 3, given that 
ClassType was gone.

types.new_class looks fair game, but the help is not exactly helpful:

new_class(name, bases=(), kwds=None, exec_body=None)
     Create a class object dynamically using the appropriate metaclass.

No indication there as to what type should be passed for kwds or exec_body.

I guessed and, by the sound of it, guessed wrong.
I'd certainly agree that the error message is very misleading.

cheers,

Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Mon Feb 18 09:30:08 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 08:30:08 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1361176208.61.0.271588001339.issue13153@psf.upfronthosting.co.za>


Ned Deily added the comment:

Serhiy, I think your patch is ready to commit and close this issue as it prevents the crash.  A test would be nice if a reliable test could be devised without too much effort but it's not mandatory, IMO.  Any tangential issues or more complex solutions can be pursued in other issues.

----------
stage: test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Mon Feb 18 09:32:56 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 18 Feb 2013 08:32:56 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361176376.86.0.114115679792.issue17223@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/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 18 09:40:30 2013
From: report at bugs.python.org (william wu)
Date: Mon, 18 Feb 2013 08:40:30 +0000
Subject: [issue17224] can not open idle in python 2.7.3
Message-ID: <1361176830.93.0.935966223453.issue17224@psf.upfronthosting.co.za>


New submission from william wu:

I install python 2.7 in windows xp 32bit. 
I try to open idle using "C:\Python27>python.exe Lib\idlelib\idle.py", But return error as following:

Traceback (most recent call last):
  File "Lib\idlelib\idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "C:\Python27\Lib\idlelib\PyShell.py", line 1421, in main
    shell = flist.open_shell()
  File "C:\Python27\Lib\idlelib\PyShell.py", line 289, in open_shell
    if not self.pyshell.begin():
  File "C:\Python27\Lib\idlelib\PyShell.py", line 1009, in begin
    client = self.interp.start_subprocess()
  File "C:\Python27\Lib\idlelib\PyShell.py", line 402, in start_subprocess
    self.port = self.rpcclt.listening_sock.getsockname()[1]
  File "C:\Python27\Lib\socket.py", line 224, in meth
    return getattr(self._sock,name)(*args)
socket.gaierror: [Errno 10104] getaddrinfo failed
it's fine if using "C:\Python27>python.exe Lib\idlelib\idle.py -n". it doesn't work after i try to close firewall.

----------
components: Windows
messages: 182306
nosy: hayeswu
priority: normal
severity: normal
status: open
title: can not open idle in python 2.7.3
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17224>
_______________________________________

From report at bugs.python.org  Mon Feb 18 09:53:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 08:53:24 +0000
Subject: [issue17224] can not open idle in python 2.7.3
In-Reply-To: <1361176830.93.0.935966223453.issue17224@psf.upfronthosting.co.za>
Message-ID: <1361177604.56.0.112888705898.issue17224@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +IDLE
nosy: +kbk
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17224>
_______________________________________

From report at bugs.python.org  Mon Feb 18 10:00:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 09:00:04 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1361178004.12.0.286567676541.issue13169@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for report, Arfrever. I'll see how epydoc uses MAXREPEAT. Maybe it requires larger changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Mon Feb 18 10:30:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Feb 2013 09:30:43 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <3Z8fvQ5h5MzPfX@mail.python.org>


Roundup Robot added the comment:

New changeset a80ea934da9a by Serhiy Storchaka in branch '2.7':
Fix issue #13169: Reimport MAXREPEAT into sre_constants.py.
http://hg.python.org/cpython/rev/a80ea934da9a

New changeset a6231ed7bff4 by Serhiy Storchaka in branch '3.2':
Fix issue #13169: Reimport MAXREPEAT into sre_constants.py.
http://hg.python.org/cpython/rev/a6231ed7bff4

New changeset 88c04657c9f1 by Serhiy Storchaka in branch '3.3':
Fix issue #13169: Reimport MAXREPEAT into sre_constants.py.
http://hg.python.org/cpython/rev/88c04657c9f1

New changeset 3dd5be5c4794 by Serhiy Storchaka in branch 'default':
Fix issue #13169: Reimport MAXREPEAT into sre_constants.py.
http://hg.python.org/cpython/rev/3dd5be5c4794

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Mon Feb 18 10:52:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 09:52:47 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361181167.88.0.0983413394454.issue6975@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the report. I'm surprised that the tests are not caught it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Mon Feb 18 10:53:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Feb 2013 09:53:40 +0000
Subject: [issue17179] Misleading error from type() when passing unknown
	keyword argument
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1361181220.21.0.873212552502.issue17179@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For the simple case where you don't need to provide a metaclass hint, the simplest conversion is actually directly to the 3-argument form of type().

As far as the docstring goes, I don't want to make it as long as the full docs, but it could probably stand to be longer than it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17179>
_______________________________________

From report at bugs.python.org  Mon Feb 18 11:24:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Feb 2013 10:24:39 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <3Z8h5f3tx0zPl5@mail.python.org>


Roundup Robot added the comment:

New changeset 50ed06b3d419 by Serhiy Storchaka in branch '2.7':
Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
http://hg.python.org/cpython/rev/50ed06b3d419

New changeset cb3fbadb65aa by Serhiy Storchaka in branch '3.2':
Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
http://hg.python.org/cpython/rev/cb3fbadb65aa

New changeset aad7e68eff0a by Serhiy Storchaka in branch '3.3':
Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
http://hg.python.org/cpython/rev/aad7e68eff0a

New changeset f99ff3b01fab by Serhiy Storchaka in branch 'default':
Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).
http://hg.python.org/cpython/rev/f99ff3b01fab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:07:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Feb 2013 11:07:07 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <3Z8j2f57kDzPtr@mail.python.org>


Roundup Robot added the comment:

New changeset bb5a8564e186 by Serhiy Storchaka in branch '2.7':
Issue #13153: Tkinter functions now raise TclError instead of ValueError when
http://hg.python.org/cpython/rev/bb5a8564e186

New changeset 9904f245c3f0 by Serhiy Storchaka in branch '3.2':
Issue #13153: Tkinter functions now raise TclError instead of ValueError when
http://hg.python.org/cpython/rev/9904f245c3f0

New changeset 38bb2a46692e by Serhiy Storchaka in branch '3.3':
Issue #13153: Tkinter functions now raise TclError instead of ValueError when
http://hg.python.org/cpython/rev/38bb2a46692e

New changeset 61993bb9ab0e by Serhiy Storchaka in branch 'default':
Issue #13153: Tkinter functions now raise TclError instead of ValueError when
http://hg.python.org/cpython/rev/61993bb9ab0e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:08:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 11:08:48 +0000
Subject: [issue13153] IDLE crashes when pasting non-BMP unicode char on Py3
In-Reply-To: <1318363292.9.0.682519731008.issue13153@psf.upfronthosting.co.za>
Message-ID: <1361185728.13.0.112239754353.issue13153@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: asvetlov -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13153>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:09:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 11:09:31 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361185771.09.0.662090461586.issue6975@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:16:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 11:16:11 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361186171.12.0.249607158968.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. Changes for unittest and doctest reverted.

----------
Added file: http://bugs.python.org/file29113/NEWS-3.4_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:28:46 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Mon, 18 Feb 2013 11:28:46 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1361186926.61.0.50985323929.issue11949@psf.upfronthosting.co.za>


Marc Schlaich added the comment:

I'm +1 for a warning. The current behavior is really unexpectable:

In [6]: sorted([nan, 0, 1, -1])
Out[6]: [nan, -1, 0, 1]

In [7]: sorted([0, 1, -1, nan])
Out[7]: [-1, 0, 1, nan]

In [8]: sorted([0, nan, 1, -1])
Out[8]: [0, nan, -1, 1]

----------
nosy: +schlamar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:36:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Feb 2013 11:36:00 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <3Z8jgz4wGnzMxh@mail.python.org>


Roundup Robot added the comment:

New changeset 3c5517c4fa5d by Serhiy Storchaka in branch '2.7':
Disable posixpath.realpath() tests on Windows (fix for issue #6975).
http://hg.python.org/cpython/rev/3c5517c4fa5d

New changeset 0bbf7cdea551 by Serhiy Storchaka in branch '3.2':
Disable posixpath.realpath() tests on Windows (fix for issue #6975).
http://hg.python.org/cpython/rev/0bbf7cdea551

New changeset 79ea59b394bf by Serhiy Storchaka in branch '3.3':
Disable posixpath.realpath() tests on Windows (fix for issue #6975).
http://hg.python.org/cpython/rev/79ea59b394bf

New changeset aa77f7eb2bf1 by Serhiy Storchaka in branch 'default':
Disable posixpath.realpath() tests on Windows (fix for issue #6975).
http://hg.python.org/cpython/rev/aa77f7eb2bf1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Mon Feb 18 12:48:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 11:48:10 +0000
Subject: [issue13169] Regular expressions with 0 to 65536 repetitions raises
	OverflowError
In-Reply-To: <1318523427.81.0.476768111228.issue13169@psf.upfronthosting.co.za>
Message-ID: <1361188090.5.0.306703075599.issue13169@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13169>
_______________________________________

From report at bugs.python.org  Mon Feb 18 13:10:55 2013
From: report at bugs.python.org (Harvey Ormston)
Date: Mon, 18 Feb 2013 12:10:55 +0000
Subject: [issue16525] wave file module does not support 32bit float format
In-Reply-To: <1353528827.37.0.543069044809.issue16525@psf.upfronthosting.co.za>
Message-ID: <1361189455.68.0.821466175945.issue16525@psf.upfronthosting.co.za>


Harvey Ormston added the comment:

Thanks Sebastian. That makes sense. I've tried the updated patch and it works just fine for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16525>
_______________________________________

From report at bugs.python.org  Mon Feb 18 13:14:53 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 18 Feb 2013 12:14:53 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361189693.07.0.204388911426.issue17221@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I did not realize there was a 'Extension Modules' section.  I have been putting changes to C extensions in the 'Library' section instead.  It looks like most people do the same as me.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 13:47:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2013 12:47:41 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361189693.07.0.204388911426.issue17221@psf.upfronthosting.co.za>
Message-ID: <689107390.44662973.1361191655667.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I did not realize there was a 'Extension Modules' section.  I have
> been putting changes to C extensions in the 'Library' section
> instead.  It looks like most people do the same as me.

I prefer "Library" as well. I think the "Extension Modules" section
should be yanked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 14:11:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 13:11:01 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361193061.14.0.927077767993.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Was not it be yanked in 1fabff717ef4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 14:19:26 2013
From: report at bugs.python.org (Ferdinand Beyer)
Date: Mon, 18 Feb 2013 13:19:26 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
Message-ID: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>


New submission from Ferdinand Beyer:

The linecol() function in json/decoder.py computes the line and column numbers for a byte offset in a string.  Both numbers are expected to start with 1 (as in text editors).

If the position is in the first line, the returned column is off by one (or starting with zero):

    >>> from json.decoder import linecol
    >>> linecol('spam', 0)  # Should be (1, 1)
    (1, 0)
    >>> linecol('\nspam', 1)
    (2, 1)

The problem is the line:

    if lineno == 1:
        colno = pos

that should read

    if lineno == 1:
        colno = pos + 1

----------
components: Library (Lib)
messages: 182320
nosy: fbeyer
priority: normal
severity: normal
status: open
title: JSON decoder reports wrong column number on first line
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Mon Feb 18 14:32:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 13:32:02 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361194322.14.0.692164764185.issue17225@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +ezio.melotti, pitrou, rhettinger, serhiy.storchaka
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Mon Feb 18 14:40:10 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 18 Feb 2013 13:40:10 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1361194810.42.0.409764751675.issue11816@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Updated version of the patch.

Changed from review:
- Included test.bytecode_helper module used by some tests
- Updated docs to indicate that the changes are new in 3.4
- ByteCode -> Bytecode
- Added meaningful repr for Bytecode

Still to do:
- ? Re-expose attributes from code object on Bytecode instance
- Tests & documentation for Bytecode class
- Split changes into multiple patches

----------
Added file: http://bugs.python.org/file29114/dis_api2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11816>
_______________________________________

From report at bugs.python.org  Mon Feb 18 14:48:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2013 13:48:06 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361195286.94.0.0278490173031.issue15767@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've lost track of why this new exception was needed. Could someone provide a summary? Thanks :-)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 18 15:39:04 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Feb 2013 14:39:04 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1361198344.09.0.735278539958.issue12014@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This actually came up on the core-mentorship list (someone was trying to translate old mod-formatting code that used a colon in the lookup names and discovered this odd behaviour)

My own preference is to let this quote from PEP 3101 dominate the behaviour: "The rules for parsing an item key are very simple. If it starts with a digit, then it is treated as a number, otherwise it is used as a string."

That means Petri's suggested solution (allowing any character except a closing square bracket and braces in the item key) sounds good to me.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Mon Feb 18 15:59:27 2013
From: report at bugs.python.org (uservorname usernachname)
Date: Mon, 18 Feb 2013 14:59:27 +0000
Subject: [issue17216] sparc linux build fails with "could not import runpy
	module"
In-Reply-To: <1361030549.85.0.142057307455.issue17216@psf.upfronthosting.co.za>
Message-ID: <1361199567.12.0.398113045798.issue17216@psf.upfronthosting.co.za>


uservorname usernachname added the comment:

Thanks for your hints.

I got installed openssl-1.0.1d and ssl in 
fes-a120d19nas:/backup/fes-a120d19nas/Python-3.3.0# whereis openssl
openssl: /usr/bin/openssl /usr/include/openssl
fes-a120d19nas:/backup/fes-a120d19nas/Python-3.3.0# whereis ssl
ssl: /etc/ssl /usr/lib/ssl

I compiled openssl-1.0.1d and gnutls-3.1.7 by my self. Package manager doesn't work at this machine. But anyway because I compiled this libaries all header files should be avaibel.

I also recognized that setup.py line 759 searches in /usr/local/lib instead of /usr/lib.

So I changed the setup lines regarding 759 to :

     # Detect SSL support for the socket module (via _ssl)
        search_for_ssl_incs_in = [
                              '/usr/ssl/include',
                              '/usr/contrib/ssl/include/'
                             ]
        ssl_incs = find_file('openssl/ssl.h', inc_dirs,
                             search_for_ssl_incs_in
                             )
        if ssl_incs is not None:
            krb5_h = find_file('krb5.h', inc_dirs,
                               ['/usr/kerberos/include'])
            if krb5_h:
                ssl_incs += krb5_h
        ssl_libs = find_library_file(self.compiler, 'ssl',lib_dirs,
                                     ['/usr/lib/ssl',
                                      '/usr/contrib/ssl/lib/'
                                     ] )
and executed again make. 

Which now results in

fes-a120d19nas:/backup/fes-a120d19nas/Python-3.3.0# make
case $MAKEFLAGS in *s*) quiet=-q; esac; \
 CC='sparc-linux-gcc -pthread' LDSHARED='sparc-linux-gcc -pthread -shared  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' \
        ./python -E ./setup.py $quiet build
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
make: *** [sharedmods] Error 139

So now I'm compiling Tcl from source, and hope this will have some positive effects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17216>
_______________________________________

From report at bugs.python.org  Mon Feb 18 16:01:00 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 18 Feb 2013 15:01:00 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361199660.27.0.0523938648548.issue17221@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Was not it be yanked in 1fabff717ef4?

Looks like it was reintroduced by this merge changeset:

    http://hg.python.org/cpython/rev/30fc620e240e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 16:04:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 15:04:57 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361199897.98.0.544311688126.issue17221@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 16:33:24 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 18 Feb 2013 15:33:24 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361201604.66.0.604633235214.issue14905@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Why are zipfiles without entries for directories broken? When you don't care about directory permissions (such as when the zipfile won't be extracted at all) the entries for directories are not necessary. Also, AFAIK the zipfile specification <http://www.pkware.com/documents/casestudies/APPNOTE.TXT> does not require adding directory entries to the zipfile.

FWIW: the zipfiles created by py2app do no contain entries for directories at the moment.  I'll probably add entries for directories in the next update to work around this issue.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14905>
_______________________________________

From report at bugs.python.org  Mon Feb 18 17:00:07 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 18 Feb 2013 16:00:07 +0000
Subject: [issue17226] libintl should also check for libiconv
Message-ID: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

The configure.ac script detects libintl but can depend on libiconv.

I added this to force it and to demonstrate, but I think this is not 100% correct and should be massaged into the libintl tests.

--- configure.ac.old    2013-02-16 09:34:55.000000000 +0000
+++ configure.ac        2013-02-16 09:43:22.000000000 +0000
@@ -2122,6 +2122,15 @@
                                                # pthread (first!) on Linux
 fi
 
+# Check iconv
+AC_CHECK_LIB([iconv], [iconv_open], , [ac_found_iconf=no])
+if test "x$ac_found_iconf" = "xno"; then
+  AC_CHECK_LIB([iconv], [libiconv_open], , [ac_found_iconf=no])
+fi
+if test "x$ac_found_iconf" = "xyes"; then
+  LIBS="-liconv $LIBS"
+fi
+
 # check if we need libintl for locale functions
 AC_CHECK_LIB(intl, textdomain,
        [AC_DEFINE(WITH_LIBINTL, 1,

----------
components: Build
messages: 182327
nosy: alanh
priority: normal
severity: normal
status: open
title: libintl should also check for libiconv
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Mon Feb 18 17:08:58 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 18 Feb 2013 16:08:58 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1361203738.63.0.545244881841.issue17170@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/issue17170>
_______________________________________

From report at bugs.python.org  Mon Feb 18 17:09:09 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 18 Feb 2013 16:09:09 +0000
Subject: [issue16061] performance regression in string replace for 3.3
In-Reply-To: <1348761787.62.0.977797373088.issue16061@psf.upfronthosting.co.za>
Message-ID: <1361203749.4.0.928032785048.issue16061@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/issue16061>
_______________________________________

From report at bugs.python.org  Mon Feb 18 17:57:12 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Mon, 18 Feb 2013 16:57:12 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361206632.65.0.978416364031.issue15767@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy:  -maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 18 18:03:58 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Feb 2013 17:03:58 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361207038.57.0.580900112342.issue17221@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

re-yank it.  that was unintentional.  less sections == better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 18:05:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 17:05:25 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361207125.86.0.864108455359.issue17225@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch. This change breaks tests, but unlikely anything except tests depends on exact error message.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file29115/json_first_line_columns.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Mon Feb 18 18:19:11 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 18 Feb 2013 17:19:11 +0000
Subject: [issue17044] Implement PEP 422: Simple class initialisation hook
In-Reply-To: <1359235758.38.0.556194565574.issue17044@psf.upfronthosting.co.za>
Message-ID: <1361207951.82.0.734794170527.issue17044@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/issue17044>
_______________________________________

From report at bugs.python.org  Mon Feb 18 18:32:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 17:32:19 +0000
Subject: [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361208739.6.0.958133959821.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. Re-yanked "Extension Modules" section. Changes for 3.4 sorted in chronological order.

----------
Added file: http://bugs.python.org/file29116/NEWS-3.4_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17221>
_______________________________________

From report at bugs.python.org  Mon Feb 18 19:33:13 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Feb 2013 18:33:13 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361212393.77.0.579432450955.issue17220@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It all LGTM. Nice cleanup! Totally didn't remember about to_bytes and from_bytes.

If you are feeling adventurous you can look at possibly porting the changes you made to _path_join() and _path_split() to os.py since I mostly copied them.

----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 18 19:33:44 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Feb 2013 18:33:44 +0000
Subject: [issue14905] zipimport.c needs to support namespace packages when no
	'directory' entry exists
In-Reply-To: <1337905627.12.0.841961188355.issue14905@psf.upfronthosting.co.za>
Message-ID: <1361212424.57.0.0822425218481.issue14905@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/issue14905>
_______________________________________

From report at bugs.python.org  Mon Feb 18 19:36:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Feb 2013 18:36:53 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361212613.24.0.558769014844.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

TL;DR for Antoine: when using a fromlist, import failures from that list are silently ignored. Because ImportError is overloaded in terms of what it means (e.g. bag magic number, module not found) there needs to be a clean way to tell the import failed because the module wasn't found so other ImportError reasons can properly propagate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 18 19:47:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 18:47:52 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361213272.38.0.0176107312327.issue17220@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

_path_join() and _path_split() do not look as join() and split() from ntpath or posixpath. They rather look as very simplified and limited versions of join() and split(). Perhaps they are enough for _bootstrap.py, but real os.path functions are more complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 18 20:02:17 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 18 Feb 2013 19:02:17 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361214137.85.0.384747833016.issue17222@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So py_compile always replaced the file, even in Python 3.3: http://hg.python.org/cpython/file/79ea59b394bf/Lib/py_compile.py#l141 (this is why I changed the title of the bug). What did change, though, is that py_compile now writes bytecode files just as import does, which means copying the file permissions of the source file for the bytecode file. E.g. if you listed the permissions for test.py in your example output I bet it's -rw-r----- just like what /dev/null ended up with.

I'm not going to change this as this is very much on purpose for security reasons; it's more of a long-standing bug that py_compile never used the proper permissions than it is changing the semantics to what they are today. Since py_compile is for compiling and writing out source code it should match what import does (if you are doing this to verify the file will parse properly, which is what writing to /dev/null suggests, it would be more accurate to just pass the raw source code through the AST module and make sure no exceptions are raised, else just write into the /tmp directory and let the OS clean up).

What I will do, though, it document this fact in the docs with a "Changed in Python 3.4" note and in What's New since people should be aware of it.

----------
assignee:  -> brett.cannon
components: +Documentation
keywords: +easy
priority: high -> normal
stage:  -> needs patch
title: py_compile.compile() replaces target files, breaking special files and symlinks -> py_compile.compile() explicitly sets st_mode for written files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Mon Feb 18 20:24:10 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 18 Feb 2013 19:24:10 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361215450.56.0.0732448890596.issue17222@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

In case of /dev/null, the main problem is that it became a regular file. It was previously a character device. Writing to character devices should not replace them.

What about problem with symlinks?:
$ cd /tmp
$ touch test.py
$ ln -s target.pyc test.pyc
$ python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="test.pyc")'
$ ls -l test.py test.pyc target.pyc
-rw-r--r-- 1 Arfrever Arfrever 102 02-18 20:20 target.pyc
-rw-r--r-- 1 Arfrever Arfrever   0 02-18 20:20 test.py
lrwxrwxrwx 1 Arfrever Arfrever  10 02-18 20:20 test.pyc -> target.pyc
$ python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="test.pyc")'
$ ls -l test.py test.pyc target.pyc
-rw-r--r-- 1 Arfrever Arfrever 102 02-18 20:20 target.pyc
-rw-r--r-- 1 Arfrever Arfrever   0 02-18 20:20 test.py
-rw-r--r-- 1 Arfrever Arfrever 102 02-18 20:21 test.pyc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Mon Feb 18 20:25:35 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Feb 2013 19:25:35 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1361215535.27.0.2638054103.issue1100942@psf.upfronthosting.co.za>


Berker Peksag added the comment:

New patch attached.

Changes:

* Addressed msg107402. I will update the C code if this implementation
  is correct.
* Added more tests
* Converted classmethods to staticmethods
* Removed doctests
* Updated documentation

----------
nosy: +berker.peksag
Added file: http://bugs.python.org/file29117/issue1100942_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Mon Feb 18 20:34:33 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 18 Feb 2013 19:34:33 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361216072.99.0.454315860253.issue17222@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

py_compile.compile() was always replacing contents of target file, but was not causing that a given link name would refer to a different inode. builtins.open() has correct behavior:

# stat /dev/null
  File: ?/dev/null?
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 5h/5d   Inode: 3242180     Links: 1     Device type: 1,3
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-02-18 20:11:07.883986147 +0100
Modify: 2013-02-18 20:11:07.883986147 +0100
Change: 2013-02-18 20:11:07.883986147 +0100
 Birth: -
# python3.4 -c 'null = open("/dev/null", "wb"); null.write(b"abc"); null.close()'
# stat /dev/null
  File: ?/dev/null?
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 5h/5d   Inode: 3242180     Links: 1     Device type: 1,3
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-02-18 20:11:07.883986147 +0100
Modify: 2013-02-18 20:11:07.883986147 +0100
Change: 2013-02-18 20:11:07.883986147 +0100
 Birth: -

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Mon Feb 18 20:50:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2013 19:50:02 +0000
Subject: [issue17227] devguide: buggy heading numbers
Message-ID: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you look e.g. here:
http://docs.python.org/devguide/faq.html#communications

you'll see that all questions are numbered "25", while the upper headings are numbered "25.1", "25.2", etc.

Other places in the devguide seem fine, e.g. http://docs.python.org/devguide/stdlibchanges.html

----------
components: Devguide
messages: 182338
nosy: eric.araujo, ezio.melotti, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: devguide: buggy heading numbers
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Mon Feb 18 21:10:46 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 18 Feb 2013 20:10:46 +0000
Subject: [issue15767] add ModuleNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361218246.77.0.617797593094.issue15767@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

>> from foo import bar
>> Here bar can be not module, but an attribute of foo (for example, os.path).
> Serhiy: What exception is raised in that situation is controlled by the eval loop, not importlib so that would be a separate change.

Just to clarify from this exchange, is there a chance we will use this same exception type (perhaps in a later change) in cases where bar is not found?  If so, I think it's worth considering something like "NotFoundImportError" or "ImportNotFoundError" that doesn't single out module.  Importing classes, etc. is quite a common pattern (e.g. examples appear in PEP 8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Mon Feb 18 21:26:17 2013
From: report at bugs.python.org (Richard Yao)
Date: Mon, 18 Feb 2013 20:26:17 +0000
Subject: [issue17228] Building without PYMALLOC fails
Message-ID: <1361219177.62.0.296828194519.issue17228@psf.upfronthosting.co.za>


New submission from Richard Yao:

The preprocessor definition for uint is only defined when building with PYMALLOC, which breaks builds without PYMALLOC. There is a Gentoo bug report on this issue:

https://bugs.gentoo.org/show_bug.cgi?id=458168

I have attached a patch that I wrote that resolves this.

----------
components: Build
files: python-3.3.0-rename-uint.patch
keywords: patch
messages: 182340
nosy: ryao
priority: normal
severity: normal
status: open
title: Building without PYMALLOC fails
type: compile error
versions: Python 3.3
Added file: http://bugs.python.org/file29118/python-3.3.0-rename-uint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17228>
_______________________________________

From report at bugs.python.org  Mon Feb 18 21:31:30 2013
From: report at bugs.python.org (Julian Scheid)
Date: Mon, 18 Feb 2013 20:31:30 +0000
Subject: [issue13829] exception error in _scproxy.so
In-Reply-To: <1326998522.6.0.790472668429.issue13829@psf.upfronthosting.co.za>
Message-ID: <1361219490.96.0.15900027341.issue13829@psf.upfronthosting.co.za>


Julian Scheid added the comment:

FWIW, I've run into the same issue in a homegrown application with 2.6.8, 2.7.2 and 2.7.3 (these were the only versions I've tested).

Looking around a little bit, I suspect this might be a bug in SCDynamicStoreCopyProxies that's only present on OS X 10.7 and only triggered when invoked in a forked child (?) [1][2].

I've tried working around it by invoking SCDynamicStoreCopyProxies with a non-NULL SCDynamicStoreRef but to no avail. Since I don't need this Python application to use HTTP proxies, I'm working around it now like this:

                proxy_handler = urllib2.ProxyHandler({})
                opener = urllib2.build_opener(proxy_handler)
                request = urllib2.Request(...)
                response = opener.open(request)

[1] http://forums.macrumors.com/archive/index.php/t-1295113.html
[2] https://github.com/suminb/spider/issues/7

----------
nosy: +Julian.Scheid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13829>
_______________________________________

From report at bugs.python.org  Mon Feb 18 22:03:26 2013
From: report at bugs.python.org (Muflone)
Date: Mon, 18 Feb 2013 21:03:26 +0000
Subject: [issue15976] Inconsistent behavior of search_for_exec_prefix()
	results in startup failure in certain cases
In-Reply-To: <1348084661.36.0.682682476046.issue15976@psf.upfronthosting.co.za>
Message-ID: <1361221406.67.0.975183367027.issue15976@psf.upfronthosting.co.za>


Muflone added the comment:

Confirmed for Arch Linux x86_64 with python version 2.7.3

----------
nosy: +Muflone
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15976>
_______________________________________

From report at bugs.python.org  Mon Feb 18 22:21:11 2013
From: report at bugs.python.org (Samwyse)
Date: Mon, 18 Feb 2013 21:21:11 +0000
Subject: [issue17229] unable to discover preferred HTTPConnection class
Message-ID: <1361222471.81.0.536204108906.issue17229@psf.upfronthosting.co.za>


New submission from Samwyse:

When a URL is opened, the opener-director is responsible for locating the proper handler for the specified protocol. Frequently, an existing protocol handler will be subclassed and then added to the collection maintained by the director. When urlopen is called, the specified request is immediately handed off to the director's "open" method which finds the correct handler and invokes the protocol-specific XXX_open method. At least in the case of the HTTP protocols, if an error occurs then the director is called again to find and invoke a handler for the error; these handlers generally open a new connection after adding headers to avoid the error going forward. Finally, it is important to note that at the present time, the HTTP handlers in urllib2 are built using a class (infourl) that isn't prepared to deal with a persistent connection, so they always add a "Connection: close" header to the request.
    
Unfortunately, NTLM only certifies the current connection, meaning that a "Connection: keep-alive" header must be used to keep it open throughout the authentication process. Furthermore, because the opener director only provides a do_open method, there is no way to discover the type of connection without also opening it. This means that the HTTPNtlmAuthHandler cannot use the normal HTTPHandler and must therefore must hardcode the HTTPConnection class. If a custom class is required for whatever reason, the only way to cause it to be used is to monkey-patch the code. For an example, see http://code.google.com/p/python-ntlm/source/browse/trunk/python26/ntlm_examples/test_ntlmauth.py

This can be avoided if, instead of putting the instantiation of the desired HTTP connection class inline, the HTTPHandler classes used a class instance variable. Something like the following should work without breaking any existing code:

class HTTPHandler(AbstractHTTPHandler):

    _connection = httplib.HTTPConnection
    
    @property
    def connection(self):
        """Returns the class of connection being handled."""
        return self._connection

    def http_open(self, req):
        return self.do_open(_connection, req)

    http_request = AbstractHTTPHandler.do_request_

----------
components: Library (Lib)
messages: 182343
nosy: samwyse
priority: normal
severity: normal
status: open
title: unable to discover preferred HTTPConnection class
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17229>
_______________________________________

From report at bugs.python.org  Mon Feb 18 22:57:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 21:57:07 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <1361224627.48.0.544285618101.issue15301@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Mon Feb 18 22:58:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 21:58:01 +0000
Subject: [issue17119] Integer overflow when passing large string to Tkinter
In-Reply-To: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>
Message-ID: <1361224681.44.0.307148913981.issue17119@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17119>
_______________________________________

From report at bugs.python.org  Mon Feb 18 23:45:20 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Feb 2013 22:45:20 +0000
Subject: [issue13512] ~/.pypirc created insecurely
In-Reply-To: <1322695403.24.0.389183798564.issue13512@psf.upfronthosting.co.za>
Message-ID: <1361227520.81.0.56680010462.issue13512@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

CVE-2011-4944

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13512>
_______________________________________

From report at bugs.python.org  Mon Feb 18 23:52:49 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 22:52:49 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1361227969.6.0.230507678644.issue17226@psf.upfronthosting.co.za>


Ned Deily added the comment:

Do you have a use case where this is needed?  As far as I know, Python itself doesn't reference libiconv directly.  libintl may but we're not building it, merely using it.  If libintl does reference it, the linker in use should try to satisfy the dependency for it.  We shouldn't have to specify the transitive closure of all dependent libraries.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Tue Feb 19 00:09:52 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 18 Feb 2013 23:09:52 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361228992.0.0.839879982543.issue17227@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Tue Feb 19 00:12:53 2013
From: report at bugs.python.org (jort bloem)
Date: Mon, 18 Feb 2013 23:12:53 +0000
Subject: [issue17230] when forking without tty, code is run from start
Message-ID: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>


New submission from jort bloem:

When calling os.fork() without a tty, a process reporting the parent's pid runs code BEFORE the fork().

When running on a tty, it behaves as expected: both parent and child continue running from statement immediately after os.fork()

See attached test.py, compare running it with tty vs. without.

to run without tty: ssh localhost `pwd`/test.py

----------
components: None
messages: 182346
nosy: jort.bloem
priority: normal
severity: normal
status: open
title: when forking without tty, code is run from start
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 00:15:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Feb 2013 23:15:18 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361229318.71.0.727103595276.issue17230@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is no attached file.

I don't think that it's a bug that the child starts before the parent. It depends on the OS, OS version and many other things. You should use a synchronization mechanism to ensure the execution order.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 00:24:55 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 18 Feb 2013 23:24:55 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1361229895.29.0.374730805504.issue17226@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

Hi Yes, when Python is built as static only, on a system when no dynamic loading is available. You have to explicitly link libiconv when libintl references it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:14:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 00:14:43 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361232883.79.0.212540302883.issue17230@psf.upfronthosting.co.za>


R. David Murray added the comment:

Haypo: I think he's saying that a statement in the source before the os.fork call is executed in the child, which seem rather unlikely.  Your suggestion may be what is happening to confuse him into thinking that, but without the sample program we can't evaluate this any further.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:24:48 2013
From: report at bugs.python.org (jort bloem)
Date: Tue, 19 Feb 2013 00:24:48 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361233488.28.0.107699740145.issue17230@psf.upfronthosting.co.za>


jort bloem added the comment:

Try attachment again.

----------
Added file: http://bugs.python.org/file29119/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:30:22 2013
From: report at bugs.python.org (jort bloem)
Date: Tue, 19 Feb 2013 00:30:22 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361233822.0.0.323452330914.issue17230@psf.upfronthosting.co.za>


jort bloem added the comment:

haypo: I understand that, after a fork, parent and child instructions are run in parallel; which one prints first is a matter of chance.

However, commands BEFORE THE FORK should not be re-run.

See test script. I would expect one "Start <pid>", followed by a "parent <pid>" and a "child <pid>". I would not expect to see (as I do) a second "Start <pid>".

(The original program was long and complex, with numerous forks; this is the smallest program I could write to show the problem).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:30:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 00:30:34 +0000
Subject: [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1361233834.36.0.652205098876.issue7063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Stefan, IIRC you reworked some of the buffer/memoryview code.  Do you know if what is reported here is still an issue, and if so if it is worth fixing?

----------
nosy: +r.david.murray, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7063>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:41:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 00:41:03 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361234463.17.0.487670896544.issue17230@psf.upfronthosting.co.za>


R. David Murray added the comment:

I only see Start printed once (on linux).  What OS are you running this on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:49:11 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Feb 2013 00:49:11 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361234951.2.0.363897679769.issue17230@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I can reproduce the issue using "python test.py|cat". The problem is that sys.stdout is buffered and the buffer is flushed twice: once in the parent, once in the child. Just call sys.stdout.flush() before os.fork() should fix your issue.

I don't think that Python should flush buffers of all streams before fork, so I propose to close this issue. Except if you see something interesting to add to Python documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 01:51:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Feb 2013 00:51:50 +0000
Subject: [issue17119] Integer overflow when passing large string to Tkinter
In-Reply-To: <1359920139.05.0.774798858282.issue17119@psf.upfronthosting.co.za>
Message-ID: <1361235110.41.0.822181495863.issue17119@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17119>
_______________________________________

From report at bugs.python.org  Tue Feb 19 02:02:56 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 19 Feb 2013 01:02:56 +0000
Subject: [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1361235776.18.0.848038206981.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Over the weekend I caught this terrible cold and have not been able to work on this issue much.  Hopefully I can complete by next weekend 2/25/2013 thanks for your understanding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16278>
_______________________________________

From report at bugs.python.org  Tue Feb 19 02:17:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 01:17:00 +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: <1361236620.48.0.200142084279.issue6962@psf.upfronthosting.co.za>


R. David Murray added the comment:

This appears to be out of date.  The output matches that of the interpreter (no extra newline) for 2.6.8, 2.7.3 and 3.2.1.  The carrot in this particular example points to the ) and not the newline; I'm not sure if that is ideal, but it is consistent and, as Amaury said, currently tested for.  

Closing this as out of date; if someone wants to analyze the ^/newline position issue and open a new bug if it seems appropriate, please do.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6962>
_______________________________________

From report at bugs.python.org  Tue Feb 19 02:34:22 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Feb 2013 01:34:22 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1361237662.99.0.94904037146.issue17226@psf.upfronthosting.co.za>


Ned Deily added the comment:

That helps a bit but, to be able to even test this, we would still need a specific example of a platform and a configuration where this is the case.  It's not necessary or desirable to add on most platforms, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Tue Feb 19 02:51:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 01:51:07 +0000
Subject: [issue7469] Design and History FAQ entry on Floating Point does not
	mention short repr.
In-Reply-To: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
Message-ID: <1361238667.03.0.984152261644.issue7469@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've reviewed these docs again, and I don't see anything left to update (everything in the current 2.7 tutorial appears to be accurate).  I also did a grep on the FAQs, and don't see any prints that are statements, so those must have gotten fixed as part of other issues.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7469>
_______________________________________

From report at bugs.python.org  Tue Feb 19 03:44:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Feb 2013 02:44:38 +0000
Subject: [issue7963] Misleading error message from object(arg)
In-Reply-To: <1266534865.21.0.144393400814.issue7963@psf.upfronthosting.co.za>
Message-ID: <3Z95rP2zpnzMVj@mail.python.org>


Roundup Robot added the comment:

New changeset b5adf2a30b73 by R David Murray in branch '3.2':
#7963: fix error message when 'object' called with arguments.
http://hg.python.org/cpython/rev/b5adf2a30b73

New changeset 0e438442fddf by R David Murray in branch '3.3':
#7963: fix error message when 'object' called with arguments.
http://hg.python.org/cpython/rev/0e438442fddf

New changeset 1f3ce7ba410b by R David Murray in branch 'default':
Merge: #7963: fix error message when 'object' called with arguments.
http://hg.python.org/cpython/rev/1f3ce7ba410b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7963>
_______________________________________

From report at bugs.python.org  Tue Feb 19 04:05:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Feb 2013 03:05:12 +0000
Subject: [issue7963] Misleading error message from object(arg)
In-Reply-To: <1266534865.21.0.144393400814.issue7963@psf.upfronthosting.co.za>
Message-ID: <3Z96J73VkYzMDp@mail.python.org>


Roundup Robot added the comment:

New changeset 0082b7bf9501 by R David Murray in branch '2.7':
#7963: fix error message when 'object' called with arguments.
http://hg.python.org/cpython/rev/0082b7bf9501

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7963>
_______________________________________

From report at bugs.python.org  Tue Feb 19 04:12:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 03:12:18 +0000
Subject: [issue7963] Misleading error message from object(arg)
In-Reply-To: <1266534865.21.0.144393400814.issue7963@psf.upfronthosting.co.za>
Message-ID: <1361243538.54.0.349990283386.issue7963@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've applied this.  Note that this makes the object.__new__ message consistent with, say, str.__new__.  That is, 'str.__new__(str, 2, 3)' results in the message "TypeError: str() argument 2 must be str, not int".  So the new object error message is consistent with that convention:  object.__new__(object, 1) now gives "TypeError: object() takes no parameters"

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7963>
_______________________________________

From report at bugs.python.org  Tue Feb 19 06:54:37 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Feb 2013 05:54:37 +0000
Subject: [issue11949] Make float('nan') unorderable
In-Reply-To: <1304017739.89.0.82559951904.issue11949@psf.upfronthosting.co.za>
Message-ID: <1361253277.89.0.0280393275116.issue11949@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

-1 for a warning.  A should really have *no* expectations about a NaNs sort order.  For the most part, Python does not get into warnings business for every possible weird thing you could tell it to do (especially something as harmless as this).

Also warnings are a bit of PITA to shut-off.  For something like NaN ordering, a warning is likely to inflict more harm on the users than the NaN ordering issue itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________

From report at bugs.python.org  Tue Feb 19 07:03:15 2013
From: report at bugs.python.org (jort bloem)
Date: Tue, 19 Feb 2013 06:03:15 +0000
Subject: [issue17230] when forking without tty, code is run from start
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361253795.37.0.322079982635.issue17230@psf.upfronthosting.co.za>


jort bloem added the comment:

I agree that it is reasonable NOT to flush stdout on fork().

I don't think the outcome is reasonable. 

What about voiding all buffers after the fork for the child?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 07:22:52 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 06:22:52 +0000
Subject: [issue17231] Mark __del__ not being called in cycles as an impl detail
Message-ID: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

Here: http://docs.python.org/2/reference/datamodel.html, as per python-dev discussion

----------
assignee: docs at python
components: Documentation
messages: 182364
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Mark __del__ not being called in cycles as an impl detail
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17231>
_______________________________________

From report at bugs.python.org  Tue Feb 19 07:25:01 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 06:25:01 +0000
Subject: [issue17232] Improve -O docs
Message-ID: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

This is what the current documentation says:

-O
Turn on basic optimizations. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE.

-OO
Discard docstrings in addition to the -O optimizations.

As far as I know, the only "optimization" that's done is removal of __debug__ sections and assert statements and has been like this for years. Maybe it should say so "-O does not do any optimizations, only removes assert statement" or so.

----------
assignee: docs at python
components: Documentation
messages: 182365
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Improve -O docs
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Tue Feb 19 07:37:50 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Feb 2013 06:37:50 +0000
Subject: [issue17230] when forking, buffered output is not flushed first.
In-Reply-To: <1361229173.49.0.760112952716.issue17230@psf.upfronthosting.co.za>
Message-ID: <1361255870.5.0.548505683516.issue17230@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

os.fork() is a low level system call wrapper.  Anyone using it needs to deal with flushing whatever buffers their application has before forking among many many other things.  There is a reason it lives in the os module.

It is already a dangerous system call to use from Python (ie: your child is likely to lock up if your parent had any threads).  There really is nothing we can or should do to make it better.

----------
nosy: +gregory.p.smith
resolution:  -> wont fix
status: open -> closed
title: when forking without tty, code is run from start -> when forking, buffered output is not flushed first.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17230>
_______________________________________

From report at bugs.python.org  Tue Feb 19 07:52:54 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Tue, 19 Feb 2013 06:52:54 +0000
Subject: [issue17233] http.client header debug output format
Message-ID: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>


New submission from Kim Gr?sman:

Python 3.2.3 on 64-bit Windows 7.

When I set debuglevel on HTTPConnection to 1, the output seems jumbled, and I'm having trouble interpreting it.

Attached is a full, anonymized log from a conversation I was troubleshooting.

Here's an excerpt:

 send: b'GET /a HTTP/1.1\r\nHost: localhost:55380\r\nAccept-Encoding: identity\r\n\r\n'
 reply: 'HTTP/1.1 503 Service unavailable\r\n'
 header: Connection header: Content-Length header: Content-Type header: Date send: b'GET /a HTTP/1.1\r\nHost: localhost:55380\r\nAccept-Encoding: identity\r\n\r\n'
 reply: 'HTTP/1.1 503 Service unavailable\r\n'

- Does line 3, starting with header:, show headers for the request or response? I'm guessing response, but it didn't occur to me until just now, after a full day of looking at it.
- It would be nice if the header dump showed both header key and value
- There's a trailing "send:" at the end of the header: line, shouldn't that be on its own line?

Overall, not printing a newline after these debug statements makes it really hard to combine with other print debugging, as unrelated prints show up at the end of every line of httpclient's debug output.

I find "header" a bit confusing as a prefix, as it doesn't say whether it's request or response headers. Maybe change the prefix to "response-headers:" and also add "request-headers:", even if those are visible in the "send:" lines? Alternatively, why not show the response headers in the "reply:" dump?

Would you consider patches to address these concerns?

Thank you!

----------
components: Library (Lib)
files: httpclient.debuglevel.txt
messages: 182367
nosy: Kim.Gr?sman
priority: normal
severity: normal
status: open
title: http.client header debug output format
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file29120/httpclient.debuglevel.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Tue Feb 19 09:01:57 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 08:01:57 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1361260917.35.0.942276700284.issue17226@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

Sure this is on an Atari m68k platform called FreeMiNT.

Traditionally in configure scripts you'll see it checked as *-mint*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Tue Feb 19 09:36:12 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 19 Feb 2013 08:36:12 +0000
Subject: [issue17228] Building without PYMALLOC fails
In-Reply-To: <1361219177.62.0.296828194519.issue17228@psf.upfronthosting.co.za>
Message-ID: <1361262972.84.0.953605910845.issue17228@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +hynek, ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17228>
_______________________________________

From report at bugs.python.org  Tue Feb 19 09:36:25 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 19 Feb 2013 08:36:25 +0000
Subject: [issue17228] Building without PYMALLOC fails
In-Reply-To: <1361219177.62.0.296828194519.issue17228@psf.upfronthosting.co.za>
Message-ID: <1361262985.33.0.412306061251.issue17228@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17228>
_______________________________________

From report at bugs.python.org  Tue Feb 19 09:44:25 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Feb 2013 08:44:25 +0000
Subject: [issue7469] Design and History FAQ entry on Floating Point does not
	mention short repr.
In-Reply-To: <1260446144.09.0.566145697146.issue7469@psf.upfronthosting.co.za>
Message-ID: <1361263465.65.0.784467745417.issue7469@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Agreed;  I think this did all get updated at one point or another.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7469>
_______________________________________

From report at bugs.python.org  Tue Feb 19 09:47:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Feb 2013 08:47:45 +0000
Subject: [issue17231] Mark __del__ not being called in cycles as an impl detail
In-Reply-To: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>
Message-ID: <1361263665.4.0.102109600643.issue17231@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Just for the record, the python-dev discussion starts here: http://mail.python.org/pipermail/python-dev/2013-February/124044.html

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17231>
_______________________________________

From report at bugs.python.org  Tue Feb 19 10:35:44 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Tue, 19 Feb 2013 09:35:44 +0000
Subject: [issue17234] python-2.7.3-r3: crash in visit_decref()
Message-ID: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>


New submission from Martin Mokrejs:

Hi,
  I do see relatively often a crash in python. Here is one stacktrace from my Gentoo Linux running 3.7.4 kernel:

(gdb) where
#0  0x00007f624f340f08 in visit_decref () from /usr/lib64/libpython2.7.so.1.0
#1  0x00007f624f2a455a in list_traverse () from /usr/lib64/libpython2.7.so.1.0
#2  0x00007f624f3412c7 in collect () from /usr/lib64/libpython2.7.so.1.0
#3  0x00007f624f341f11 in _PyObject_GC_Malloc () from /usr/lib64/libpython2.7.so.1.0
#4  0x00007f624f2cdd59 in PyType_GenericAlloc () from /usr/lib64/libpython2.7.so.1.0
#5  0x00007f624f2d09c3 in type_call () from /usr/lib64/libpython2.7.so.1.0
#6  0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#8  0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#9  0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#11 0x00007f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0
#12 0x00007f624f32e53d in PyRun_StringFlags () from /usr/lib64/libpython2.7.so.1.0
#13 0x00007f624f30a44e in builtin_eval () from /usr/lib64/libpython2.7.so.1.0
#14 0x00007f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#15 0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#16 0x00007f624f2a104c in function_call () from /usr/lib64/libpython2.7.so.1.0
#17 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#18 0x00007f624f28a82f in instancemethod_call () from /usr/lib64/libpython2.7.so.1.0
#19 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#20 0x00007f624f30c9b7 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.7.so.1.0
#21 0x00007f624612f807 in call_with_frame.isra.9 () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#22 0x00007f6246132080 in my_StartElementHandler () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#23 0x00007f6245ed0fb0 in doContent () from /usr/lib64/libexpat.so.1
#24 0x00007f6245ed21b4 in contentProcessor () from /usr/lib64/libexpat.so.1
#25 0x00007f6245ecce2a in XML_ParseBuffer () from /usr/lib64/libexpat.so.1
#26 0x00007f6246132d5b in xmlparse_Parse () from /usr/lib64/python2.7/lib-dynload/pyexpat.so
#27 0x00007f624f312456 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#28 0x00007f624f296379 in gen_send_ex.isra.1 () from /usr/lib64/libpython2.7.so.1.0
#29 0x00007f624f2ce40f in wrap_next () from /usr/lib64/libpython2.7.so.1.0
#30 0x00007f624f27bdc3 in PyObject_Call () from /usr/lib64/libpython2.7.so.1.0
#31 0x00007f624f310d76 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#32 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#33 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#34 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#35 0x00007f624f31285e in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#36 0x00007f624f313905 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#37 0x00007f624f313a32 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#38 0x00007f624f32d97c in run_mod () from /usr/lib64/libpython2.7.so.1.0
#39 0x00007f624f32e750 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0
#40 0x00007f624f32f1cf in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#41 0x00007f624f3407e2 in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#42 0x00007f624ec8f91d in __libc_start_main () from /lib64/libc.so.6
#43 0x000000000040094d in _start ()
(gdb)

----------
messages: 182371
nosy: mmokrejs
priority: normal
severity: normal
status: open
title: python-2.7.3-r3: crash in visit_decref()
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17234>
_______________________________________

From report at bugs.python.org  Tue Feb 19 11:20:25 2013
From: report at bugs.python.org (Michael Kuhn)
Date: Tue, 19 Feb 2013 10:20:25 +0000
Subject: [issue17235] "make sharedinstall" ignores ./configure settings
Message-ID: <1361269225.76.0.790784107865.issue17235@psf.upfronthosting.co.za>


New submission from Michael Kuhn:

I need to install Python 2.7 in two architectures, but under one file system. I thus configure:

/home/cellnet/michaelk/SRC/Python-2.7.3> ./configure --prefix=/home/cellnet/michaelk/biocluster --exec-prefix=/home/cellnet/michaelk/biocluster -q

When I compile and then run "make install", it will try to copy libraries to "/home/cellnet/michaelk/lib64/python", i.e. it will try to copy files outside the specified prefixes. The step is "make sharedinstall", which fails because I've temporarily made the lib64 directory read-only: 

[michaelk at biocluster2] /home/cellnet/michaelk/SRC/Python-2.7.3> make sharedinstall
running build
running build_ext
building dbm using bdb

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
./python -E ./setup.py install \
                --prefix=/home/cellnet/michaelk/biocluster \
                --install-scripts=/home/cellnet/michaelk/biocluster/bin \
                --install-platlib=/home/cellnet/michaelk/biocluster/lib/python2.7/lib-dynload \
                --root=/
running install
running build
running build_ext
building dbm using bdb

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 gdbm            
imageop            sunaudiodev                        
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
running install_lib
copying build/lib.linux-x86_64-2.7/_ctypes.so -> /home/cellnet/michaelk/lib64/python
error: could not delete '/home/cellnet/michaelk/lib64/python/_ctypes.so': Permission denied
make: *** [sharedinstall] Error 1

----------
components: Build
messages: 182372
nosy: Michael.Kuhn
priority: normal
severity: normal
status: open
title: "make sharedinstall" ignores ./configure settings
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17235>
_______________________________________

From report at bugs.python.org  Tue Feb 19 13:34:30 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 12:34:30 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361277270.2.0.338875119363.issue17232@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

It should also add that in the future, more optimizations may be added i.e. a peephole optimizer, etc.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Tue Feb 19 13:36:54 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 12:36:54 +0000
Subject: [issue17234] python-2.7.3-r3: crash in visit_decref()
In-Reply-To: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>
Message-ID: <1361277414.11.0.496770604565.issue17234@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Sorry, but this doesn't give enough information to fix it, nevertheless reproduce it. Please tell us what Python was running. Also run python with -X faulthandler and give the results.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17234>
_______________________________________

From report at bugs.python.org  Tue Feb 19 13:39:41 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 12:39:41 +0000
Subject: [issue17234] python-2.7.3-r3: crash in visit_decref()
In-Reply-To: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>
Message-ID: <1361277581.65.0.634339627478.issue17234@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Oops. Please ignore the sentence about adding -X faulthandler. Please install the faulthandler module [0] and run "import faulthandler;faulthandler.enable()", and then reproduce the bug.

^0 https://pypi.python.org/pypi/faulthandler/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17234>
_______________________________________

From report at bugs.python.org  Tue Feb 19 13:40:02 2013
From: report at bugs.python.org (Tobia Conforto)
Date: Tue, 19 Feb 2013 12:40:02 +0000
Subject: [issue17236] format_spec for sequence joining
Message-ID: <1361277602.96.0.470418082316.issue17236@psf.upfronthosting.co.za>


New submission from Tobia Conforto:

The format specification mini-language (format_spec) supported by format() and str.format() is a feature that allows passing short options to the classes of the values being formatted, to drive their string representation (__format__ method)

The most common operation done to sequences (lists, tuples, sets...) during conversion to string is arguably the string join operation, possibly coupled with a "nested" string formatting of the sequence items.

I propose the addition of a custom format_spec for sequences, that allows to easily specify a string for the join operation and optionally a nested format_spec to be passed along to format the sequence items.

Here is the proposed addition:

  seq_format_spec  ::= join_string [":" item_format_spec] | format_spec
  join_string      ::= '"' join_string_char* '"' | "'" join_string_char* "'"
  join_string_char ::= <any character except "{", "}", newline, or the quote>
  item_format_spec ::= format_spec

In words, if the format_spec for a sequence starts with a single or double quote, it will be interpreted as a join operation, optionally followed by another colon and the format_spec for the sequnce items.

If the format_spec does not start with ' or ", of if the quote is not balanced (does not appear again in the format_spec), then it's assumed to be a generic format string and the implementation would call super(). This ensures backwards compatibility with existing code that may be using object's __format__ implementation on various sequence objects.

Please note I'm NOT proposing a change in the language or in the implementation of format() and str.format(). This is just the addition of a __format__ method to lists, tuples, sets and other sequence classes. The choice of whether to do that in all those sequence classes or as an addition to object's __format__ is an implementation detail.

Examples:

Basic usage: either {0:", "} or {0:', '} when used in a format operation will do this: ", ".join(str(x) for x in argument_0) in a more compact, possibly more efficient, and arguably easier to read syntax.

Nested (regular) format_spec: {0:", ":.1f} will join a list of floats using ", " as the separator and .1f as the format_spec for each float.

Nested join format_spec: {0:"\n":", "} will join a list of lists, using "\n" as the outer separator and ", " as the inner separator. This could go on indefinitely (but will rarely need to do so.)

I do not have a patch ready, but I can work on it and submit it for evaluation, if this enhancement is accepted.

----------
messages: 182376
nosy: tobia
priority: normal
severity: normal
status: open
title: format_spec for sequence joining
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17236>
_______________________________________

From report at bugs.python.org  Tue Feb 19 13:40:48 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 12:40:48 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361277648.6.0.0873018267082.issue17232@psf.upfronthosting.co.za>


Maciej Fijalkowski added the comment:

There were not for at least 10 years. I would also be the first one to strongly object adding optimizations only under -O, because that already changes semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Tue Feb 19 13:59:17 2013
From: report at bugs.python.org (alef)
Date: Tue, 19 Feb 2013 12:59:17 +0000
Subject: [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1361278757.42.0.673275369856.issue11215@psf.upfronthosting.co.za>


Changes by alef <Alessandro.Foresi at eumetsat.int>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11215>
_______________________________________

From report at bugs.python.org  Tue Feb 19 14:27:57 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 Feb 2013 13:27:57 +0000
Subject: [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1361280477.9.0.860097434081.issue7063@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think msg93598 sums it up: array_ass_slice() is only called with
v==NULL, so the issue can't be triggered.

However, it's pretty dirty to leave the code as is (IIRC Coverity
also had some complaints), so Chuck's suggestion to rewrite the
function as array_del_slice() seems good to me.

----------
priority: normal -> low
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7063>
_______________________________________

From report at bugs.python.org  Tue Feb 19 14:30:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 13:30:21 +0000
Subject: [issue17236] format_spec for sequence joining
In-Reply-To: <1361277602.96.0.470418082316.issue17236@psf.upfronthosting.co.za>
Message-ID: <1361280621.23.0.0548136518391.issue17236@psf.upfronthosting.co.za>


R. David Murray added the comment:

IMO, this is a python-ideas level suggestion.  Please propose it on that mailing list.  You can reopen the issue if you get a positive response there.

----------
nosy: +eric.smith, r.david.murray
resolution:  -> later
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17236>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:12:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Feb 2013 14:12:03 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361283123.37.0.525237678201.issue17232@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ramchandra, as it turns out, if we deem an optimization semantically safe, we do it without -O, it we deem it unsafe, we don't do it at all.

Thus, the real effect is to remove assert statements and optimise code as if "__debug__" was replaced by a literal zero (effectively).

So a more meaningful description would be:

-O
Removes assert statements and any code conditional on the value of __debug__. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:31:48 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 14:31:48 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
Message-ID: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>


New submission from Alan Hourihane:

On m68k this assert triggers in Python/unicodeobject.c:4658 because m68k architectures can align on 16bit boundaries.

assert(!((size_t) dest & LONG_PTR_MASK));

I'm not sure of the wider implications in Python as to how to rectify.

----------
components: Build
messages: 182381
nosy: alanh
priority: normal
severity: normal
status: open
title: m68k aligns on 16bit boundaries.
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:36:04 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 14:36:04 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361284564.08.0.455298481754.issue17237@psf.upfronthosting.co.za>


Christian Heimes added the comment:

We don't have a m86k test box and I don't think we support this platform either.

----------
nosy: +christian.heimes, trent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:36:25 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:36:25 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361284585.19.0.641407954663.issue17222@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So that all happens because importlib does an atomic write of the file which uses os.replace(): http://hg.python.org/cpython/file/83d70dd58fef/Lib/importlib/_bootstrap.py#l121 .

Unless there is some way that I can't think of to have the atomic write still exist but not change the type of file it replaces I am still not willing to revert my change just for this use case. There should be a single implementation of bytecode file generation and py_compile (along with compileall) should be nothing more than convenience modules for forcing the generation of those files under the same semantics as if they were done as a side-effect of importing some source code.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:42:49 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Tue, 19 Feb 2013 14:42:49 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1361284969.38.0.282028179234.issue17099@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
nosy: +Ankur.Ankan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17099>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:46:23 2013
From: report at bugs.python.org (Chuck)
Date: Tue, 19 Feb 2013 14:46:23 +0000
Subject: [issue7063] Memory errors in array.array
In-Reply-To: <1254730349.27.0.71088310024.issue7063@psf.upfronthosting.co.za>
Message-ID: <1361285183.25.0.702879804444.issue7063@psf.upfronthosting.co.za>


Chuck added the comment:

I attached a patch, in which I removed v and all code having to do with inserting elements. In particular, I changed the value of b to being positive, since there is no distinction between increasing and decreasing size anymore.

----------
keywords: +patch
nosy: +Chuck
Added file: http://bugs.python.org/file29121/array_del_slice.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7063>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:52:13 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:52:13 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361285533.09.0.360596306948.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The original need was for internal importlib usage, but upon reflection it could also be used by the eval loop for that (http://hg.python.org/cpython/file/83d70dd58fef/Python/ceval.c#l4560), so I'm fine with changing the name to ImportNotFoundError.

----------
title: add ModuleNotFoundError -> add ImportNotFoundError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:53:24 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 14:53:24 +0000
Subject: [issue15976] Inconsistent behavior of search_for_exec_prefix()
	results in startup failure in certain cases
In-Reply-To: <1348084661.36.0.682682476046.issue15976@psf.upfronthosting.co.za>
Message-ID: <1361285604.59.0.997229714457.issue15976@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +loewis, ncoghlan
stage:  -> needs patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15976>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:54:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:54:54 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361285694.07.0.198690704059.issue17232@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/issue17232>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:56:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:56:08 +0000
Subject: [issue17228] Building without PYMALLOC fails
In-Reply-To: <1361219177.62.0.296828194519.issue17228@psf.upfronthosting.co.za>
Message-ID: <1361285768.51.0.169673699301.issue17228@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Why not define uint for the whole file regardless of PYMALLOC?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17228>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:56:16 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:56:16 +0000
Subject: [issue17231] Mark __del__ not being called in cycles as an impl detail
In-Reply-To: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>
Message-ID: <1361285776.47.0.430443712731.issue17231@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/issue17231>
_______________________________________

From report at bugs.python.org  Tue Feb 19 15:59:24 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 14:59:24 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361285964.38.0.217654035343.issue17237@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

I'm willing to help fix, but there are m68k emulators out there which I guess suffice for a test box.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:06:01 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 Feb 2013 15:06:01 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361286361.75.0.250011844544.issue17237@psf.upfronthosting.co.za>


Stefan Krah added the comment:

TBH, I don't think we should support this platform officially.
Is that processor still in use (e.g. in embedded systems)?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:09:15 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 15:09:15 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361286555.29.0.51373598622.issue17237@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Wikipedia says "derivative processors are still widely used in embedded applications." in m68k article.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:15:12 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Feb 2013 15:15:12 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361286912.3.0.521736078211.issue17237@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Freescale (ex-Motorola) ColdFire architecture is alive and doing well. And I know people still running Motorola 68040 Apple machines.

The problem is not a m68k emulator, but to build all the needed environment on it: OS, compilers, network, etc.

If the original submitter is willing to help...

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:24:09 2013
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 19 Feb 2013 15:24:09 +0000
Subject: [issue13700] imaplib.IMAP4.authenticate authobject does not work
	correctly in python3
In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za>
Message-ID: <1361287449.13.0.80264471983.issue13700@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Has there been any further work/review done on this issue? I just ran into the problem myself on 3.4(dev) and can verify that the patch (imaplib_authenticate_v.patch) fixes the issue.

----------
nosy: +dbrecht
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13700>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:32:51 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 15:32:51 +0000
Subject: [issue17238] Enhance import statement completion
Message-ID: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

[patch under development]
I propose to add completions for 
import <tab>
from <tab>
from x import <tab>

Also, if one types imp.<tab> , IDLE should import the module and list dir(module).
(There will be an option to disable/enable the last two completion cases as some users object to it importing modules for completion)

----------
components: IDLE
messages: 182392
nosy: Ramchandra Apte, terry.reedy
priority: normal
severity: normal
status: open
title: Enhance import statement completion
type: enhancement
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17238>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:35:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 15:35:42 +0000
Subject: [issue17239] XML vulnerabilities in Python
Message-ID: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Experimental fix for XML vulnerabilities against default. It's NOT ready and needs lots of polishing.

https://pypi.python.org/pypi/defusedxml contains explanations of all issues
https://pypi.python.org/pypi/defusedexpat is a standalone version of part of the patches for Python 2.6 to 3.3

----------
components: Extension Modules, Library (Lib), XML
files: xmlbomb_20130219.patch
keywords: patch
messages: 182393
nosy: barry, benjamin.peterson, christian.heimes, georg.brandl, larry
priority: release blocker
severity: normal
stage: needs patch
status: open
title: XML vulnerabilities in Python
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29122/xmlbomb_20130219.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:35:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 15:35:51 +0000
Subject: [issue17238] Enhance import statement completion
In-Reply-To: <1361287971.25.0.643782901011.issue17238@psf.upfronthosting.co.za>
Message-ID: <1361288151.6.0.946341403615.issue17238@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17238>
_______________________________________

From report at bugs.python.org  Tue Feb 19 16:37:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 15:37:13 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1361288233.43.0.476629807396.issue17239@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +eli.bendersky, ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Feb 19 17:15:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 16:15:03 +0000
Subject: [issue13719] bdist_msi upload fails
In-Reply-To: <1325855918.9.0.207720990162.issue13719@psf.upfronthosting.co.za>
Message-ID: <1361290503.55.0.351016854791.issue13719@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have been bitten by the bug today, too.

----------
nosy: +christian.heimes
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13719>
_______________________________________

From report at bugs.python.org  Tue Feb 19 17:51:08 2013
From: report at bugs.python.org (Thibault Kruse)
Date: Tue, 19 Feb 2013 16:51:08 +0000
Subject: [issue17240] argparse: subcommand name and arity
Message-ID: <1361292668.26.0.464460633083.issue17240@psf.upfronthosting.co.za>


New submission from Thibault Kruse:

I realize there have been several suggestions around argparse subcommands. Mine is related to this isse:
http://bugs.python.org/issue9253

In short, I suggest that the add_subparsers() function take an argument like nargs that determines how many times user may or have to use a subcommand. E.g. ?, 1, +, *. The multiples are useful for things like "setup.py build bist upload" or "make build test doc". I notice currently the subparsers object created by add_subparsers() has this:
>>> subparsers.nargs
'A...'
Does anyone know what that notation implies?

The default for nargs can be whatever it currently is, though issue9253 makes me wonder whether there currently is any default behavior over different argparse versions.

Also, I believe subcommands should have a name by which the choice of the subcommands ends up in the arg namespace.

E.g.:
import argparse
argparser = argparse.ArgumentParser()
subparsers = argparser.add_subparsers()
subparser1 = subparsers.add_parser('foo')
subparser1.add_argument('--fooopt')
subparser2 = subparsers.add_parser('bar')
subparser2.add_argument('--baropt')
argparser.parse_args(['foo'])
Namespace(fooopt=None)

This is not satisfactory. I would prefer:
import argparse
argparser = argparse.ArgumentParser()
subparsers = argparser.add_subparsers('cmd1') % name here

subparser1 = subparsers.add_parser('foo')
subparser1.add_argument('--fooopt')
subparser2 = subparsers.add_parser('bar')
subparser2.add_argument('--baropt')
argparser.parse_args(['foo'])
Namespace(fooopt=None, cmd1='foo') % value here


The dest member of subparsers already seems to work as intended:
subparsers.dest='cmd1'; but users should not have to set it like that, to improve early error checking.

----------
components: Library (Lib)
messages: 182395
nosy: Thibault.Kruse
priority: normal
severity: normal
status: open
title: argparse: subcommand name and arity
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17240>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:02:43 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 17:02:43 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1361285533.09.0.360596306948.issue15767@psf.upfronthosting.co.za>
Message-ID: <633821489.47946837.1361293357910.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> The original need was for internal importlib usage, but upon
> reflection it could also be used by the eval loop for that
> (http://hg.python.org/cpython/file/83d70dd58fef/Python/ceval.c#l4560),
> so I'm fine with changing the name to ImportNotFoundError.

I don't understand what ImportNotFoundError means: an import was
not found? ModuleNotFoundError was obvious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:05:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 17:05:26 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361293526.65.0.320614827817.issue17222@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Unless there is some way that I can't think of to have the atomic write 
> still exist but not change the type of file it replaces

How about using the `mode` to write_atomic?
(which, incidentally, is already used to mirror the .py file's permissions in SourceFileLoader._cache_bytecode)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:21:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Feb 2013 17:21:07 +0000
Subject: [issue13700] imaplib.IMAP4.authenticate authobject does not work
	correctly in python3
In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za>
Message-ID: <3Z9THk3TKRzSsL@mail.python.org>


Roundup Robot added the comment:

New changeset 3d4302718e7c by R David Murray in branch '3.2':
#13700: Make imap.authenticate with authobject work.
http://hg.python.org/cpython/rev/3d4302718e7c

New changeset b21f955b8ba2 by R David Murray in branch '3.3':
Merge: #13700: Make imap.authenticate with authobject work.
http://hg.python.org/cpython/rev/b21f955b8ba2

New changeset d404d33a999c by R David Murray in branch 'default':
Merge: #13700: Make imap.authenticate with authobject work.
http://hg.python.org/cpython/rev/d404d33a999c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13700>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:22:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 17:22:45 +0000
Subject: [issue13700] imaplib.IMAP4.authenticate authobject does not work
	correctly in python3
In-Reply-To: <1325553089.14.0.504978991098.issue13700@psf.upfronthosting.co.za>
Message-ID: <1361294565.58.0.743927844954.issue13700@psf.upfronthosting.co.za>


R. David Murray added the comment:

Demian: thanks for the reminder, and the confirmation that it works on a real server.

Erno: thanks for the test fix.  That was a pretty stupid mistake on my part :)

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13700>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:26:29 2013
From: report at bugs.python.org (Franck Michea)
Date: Tue, 19 Feb 2013 17:26:29 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1361294789.32.0.726719943013.issue17239@psf.upfronthosting.co.za>


Changes by Franck Michea <franck.michea at gmail.com>:


----------
nosy: +kushou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:31:36 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 17:31:36 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361295096.9.0.822082428648.issue17222@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Use the mode how exactly? I mean isn't the problem the os.replace() call and not os.open() on the source file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 18:33:32 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 17:33:32 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361295212.0.0.922028929143.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Technically it should be ModuleOrSomeObjectNotFoundBecauseFromListIsTheBaneOfMyExistenceError, but we might be starting to mix paints for paints a shed shortly.

Fine, that's 1 to 1 for ModuleNotFoundError vs. ImportNotFoundError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 19:17:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 18:17:39 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361295096.9.0.822082428648.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361297657.3423.2.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Use the mode how exactly? I mean isn't the problem the os.replace()
> call and not os.open() on the source file?

If you want to reproduce the original file's access rights, you have to
pass the right mode flags to os.open().
Of course, this won't recreate symlinks and the like. But I don't think
we can do something for that anyway, since we want to replace to happen
automatically. People who like to have symlinks for their pyc files
probably have their own custom scripts to create pyc files, so they
should just re-use them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 19:19:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 18:19:12 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361297657.3423.2.camel@localhost.localdomain>
Message-ID: <1361297750.3423.3.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Of course, this won't recreate symlinks and the like. But I don't think
> we can do something for that anyway, since we want to replace to happen
> automatically.

I meant: we want the replace to happen atomically :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 19:28:16 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 19 Feb 2013 18:28:16 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361298496.6.0.978687758066.issue15767@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

If we can promise not to use it in the from-import case :) I'm okay with the more specific name (in fact it is preferable).  From Brett's response, it sounds like we have flexibility there and don't need it to be the same?  For from-import I would prefer the generic ImportError or adding a new type between ImportError and ModuleNotFoundError (like ImportNotFoundError) over using a name that is not entirely correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 19:42:12 2013
From: report at bugs.python.org (Jeff Mansfield)
Date: Tue, 19 Feb 2013 18:42:12 +0000
Subject: [issue17241] Python-2.3.5.exe file possibly corrupt
Message-ID: <1361299332.57.0.860667306426.issue17241@psf.upfronthosting.co.za>


New submission from Jeff Mansfield:

Python-2.3.5.exe seems to be corrupt.
I?ve tried downloading Python-2.3.5.exe a number of times in the past week, and so have a few of my colleagues. It always transfers in an incomplete manner, resulting in only 4.7 out of 9.1 MB. I have tried from several different Windows 7 boxes, with the same results.

Perhaps something in my environment is messed up, but it may be that the file is corrupt on your server.

----------
messages: 182405
nosy: jeff_mansfield
priority: normal
severity: normal
status: open
title: Python-2.3.5.exe file possibly corrupt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17241>
_______________________________________

From report at bugs.python.org  Tue Feb 19 19:45:20 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 19 Feb 2013 18:45:20 +0000
Subject: [issue17240] argparse: subcommand name and arity
In-Reply-To: <1361292668.26.0.464460633083.issue17240@psf.upfronthosting.co.za>
Message-ID: <1361299520.14.0.530630532732.issue17240@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> This is not satisfactory. I would prefer:
> import argparse
> argparser = argparse.ArgumentParser()
> subparsers = argparser.add_subparsers('cmd1') % name here

Have you tried passing by keyword?

subparsers = argparser.add_subparsers(dest='cmd1')

It seems to work.  I observed something similar for the metavar parameter on issue 14039.

> 'A...'
> Does anyone know what that notation implies?

I could be wrong, but I think this is just an arbitrary string for internal use.

----------
nosy: +chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17240>
_______________________________________

From report at bugs.python.org  Tue Feb 19 19:58:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 18:58:49 +0000
Subject: [issue17241] Python-2.3.5.exe file possibly corrupt
In-Reply-To: <1361299332.57.0.860667306426.issue17241@psf.upfronthosting.co.za>
Message-ID: <1361300329.27.0.0109879925902.issue17241@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tried to download it on a win xp machine and I succeeded at the first attempt (even thought it seemed to be stuck for a few seconds before reaching 100%).  I was also able to start the installer, even thought I didn't install it.
This is the version I downloaded: http://www.python.org/ftp/python/2.3.5/Python-2.3.5.exe

May I ask you why you are attempting to download such an old release, and not even the latest 2.3 (there's 2.3.7 available, that also includes some security fixes)?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17241>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:04:48 2013
From: report at bugs.python.org (Jeff Mansfield)
Date: Tue, 19 Feb 2013 19:04:48 +0000
Subject: [issue17241] Python-2.3.5.exe file possibly corrupt
In-Reply-To: <1361300329.27.0.0109879925902.issue17241@psf.upfronthosting.co.za>
Message-ID: <FB76F7F991CE194B8F8907DD6C0231A03C8845CBA8@AUSX7MCPC105.AMER.DELL.COM>


Jeff Mansfield added the comment:

Ezio,

It is what was in use on my old machine, and I don't want to move versions.

Thanks,
Jeff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17241>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:06:37 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 19 Feb 2013 19:06:37 +0000
Subject: [issue14219] make the Classes tutorial more gentle
In-Reply-To: <1331111619.2.0.272575522063.issue14219@psf.upfronthosting.co.za>
Message-ID: <1361300797.18.0.0376049115003.issue14219@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
title: start the Class tutorial in a more gentle manner -> make the Classes tutorial more gentle
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14219>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:24:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Feb 2013 19:24:21 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1361285533.09.0.360596306948.issue15767@psf.upfronthosting.co.za>
Message-ID: <201302192124.05401.storchaka@gmail.com>


Serhiy Storchaka added the comment:

Can this be the same ImportError but with special flag?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:44:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 19:44:08 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361303048.97.0.704037001318.issue17237@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Which branch or version of Python is that?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:44:30 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Feb 2013 19:44:30 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <201302192124.05401.storchaka@gmail.com>
Message-ID: <20130219144427.507611c1@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On Feb 19, 2013, at 07:24 PM, Serhiy Storchaka wrote:

>Can this be the same ImportError but with special flag?

Like an attribute on the exception?  +1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:45:41 2013
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 19 Feb 2013 19:45:41 +0000
Subject: [issue17242] Fix code highlight in devguide/docquality.rst
Message-ID: <1361303141.51.0.673359773941.issue17242@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the current version:

http://docs.python.org/devguide/docquality.html#helping-with-the-developer-s-guide

----------
components: Devguide
files: devguide-highlight.diff
keywords: patch
messages: 182412
nosy: berker.peksag, ezio.melotti
priority: normal
severity: normal
status: open
title: Fix code highlight in devguide/docquality.rst
Added file: http://bugs.python.org/file29123/devguide-highlight.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17242>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:48:31 2013
From: report at bugs.python.org (Taavi Burns)
Date: Tue, 19 Feb 2013 19:48:31 +0000
Subject: [issue17033] RPM spec file has old config_binsuffix value
In-Reply-To: <1359129213.62.0.851750342405.issue17033@psf.upfronthosting.co.za>
Message-ID: <1361303311.6.0.00283563585191.issue17033@psf.upfronthosting.co.za>


Taavi Burns added the comment:

I'm not sure my vote means much, but the spec file didn't work for me on CentOS 5 anyway (weird issue with the -dev RPM trying to find "python2.72.7"). I think I'd prefer a README with suggested places to look for a working spec file than have this "blessed"-but-broken one in the source tree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17033>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:49:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 19:49:23 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <20130219144427.507611c1@anarchist.wooz.org>
Message-ID: <1361303161.19503.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> >Can this be the same ImportError but with special flag?
> 
> Like an attribute on the exception?  +1

ImportError.has_different_meaning_but_too_lazy_to_create_a_distinct_exception_class_for_it ?

(or perhaps you would prefer the camelCase version :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:49:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Feb 2013 19:49:24 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1361303364.9.0.902326190387.issue17239@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:49:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 19:49:38 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361303378.21.0.285956953726.issue15767@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Chris: Having a more generic name for import-from at the eval loop level on top of NoModuleFoundError is breaking the "practicality over purity" rule. ImportSearchFailed might be the closest we can come to a generic name for what occurred.

Serihy & Barry: no. We do that now and it's already a nasty little hack. It would be better to let people catch an exception signaling that an import didn't happen because some module is missing than require introspection on a caught ImportError to tell what is going on (there's a reason why Antoine went to all of that trouble to add new exceptions so we don't have to look at the errno attribute on OSError). Exceptions are structured to work off of inheritance hierarchies (says the man who co-wrote the PEP to make all PEPs inherit from BaseException).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:51:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 19:51:33 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361303493.45.0.449438698647.issue17222@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think Arfever is more frustrated by the os.replace() call than the permissions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:52:00 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 19:52:00 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361303520.61.0.46617709882.issue17237@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

As mention in the versions. It is Python 3.3.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:52:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Feb 2013 19:52:47 +0000
Subject: [issue17242] Fix code highlight in devguide/docquality.rst
In-Reply-To: <1361303141.51.0.673359773941.issue17242@psf.upfronthosting.co.za>
Message-ID: <3Z9Xfk3vSwzSn4@mail.python.org>


Roundup Robot added the comment:

New changeset 6015789cbce0 by Ezio Melotti in branch 'default':
#17242: fix code highlight.  Patch by Berker Peksag.
http://hg.python.org/devguide/rev/6015789cbce0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17242>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:52:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 19:52:58 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361303578.39.0.202409308112.issue17222@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, right. Well, there would be an argument not to use os.replace() in py_compile, since it's an offline processing step which generally shouldn't race with another (online) processing step.

Still, I wonder what the use case is (apart from the /dev/null case for which the answer is simply "don't do it" :-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:53:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 19:53:16 +0000
Subject: [issue17242] Fix code highlight in devguide/docquality.rst
In-Reply-To: <1361303141.51.0.673359773941.issue17242@psf.upfronthosting.co.za>
Message-ID: <1361303596.27.0.229738208065.issue17242@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17242>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:57:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 19:57:07 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361303827.89.0.123660875278.issue17237@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, could you post the whole C stack trace? (using e.g. gdb)

By the way, this is not about the alignment of m68k architectures: x86 can align on a byte boundary and doesn't trigger the assert.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 20:58:40 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 19:58:40 +0000
Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written
	files
In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za>
Message-ID: <1361303920.23.0.473630626721.issue17222@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Exactly, and I don't want to have to slice up the internal API anymore in order to support this edge case which I don't think is important enough to support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:03:47 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 20:03:47 +0000
Subject: [issue17242] Fix code highlight in devguide/docquality.rst
In-Reply-To: <1361303141.51.0.673359773941.issue17242@psf.upfronthosting.co.za>
Message-ID: <1361304227.97.0.939534857972.issue17242@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17242>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:06:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 20:06:56 +0000
Subject: [issue11763] assertEqual memory issues with large text inputs
In-Reply-To: <1301948164.44.0.0206798295308.issue11763@psf.upfronthosting.co.za>
Message-ID: <1361304416.66.0.711926967843.issue11763@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

There are some tests in the issue11763-2.diff patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11763>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:10:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 20:10:23 +0000
Subject: [issue12869] PyOS_StdioReadline is printing the prompt on stderr
In-Reply-To: <1314801518.5.0.445361297153.issue12869@psf.upfronthosting.co.za>
Message-ID: <1361304623.3.0.345706911865.issue12869@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Extension Modules
type:  -> behavior
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12869>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:20:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 20:20:39 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1361305239.2.0.203844225629.issue17032@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

GLOBAL_NAME_ERROR_MSG has been introduced in fd8c7203251f as part of PEP 227 by Jeremy Hylton, so I'm adding him to the nosy to see if he agrees with the change (also adding a couple more devs to see if they have any comments).

There's also a typo in the last chunk of the patch.

----------
nosy: +Jeremy.Hylton, ncoghlan, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:24:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 20:24:47 +0000
Subject: [issue17243] The changes made for issue 4074 should be documented
Message-ID: <1361305487.48.0.247163585293.issue17243@psf.upfronthosting.co.za>


New submission from R. David Murray:

The section of the reference on the gc module goes into some detail on what the thresholds control and when collections are run, but does not currently document the backoff algorithm used when deciding whether or not to collect generation 2.  This should presumably be documented.

----------
messages: 182425
nosy: pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The changes made for issue 4074 should be documented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17243>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:39:59 2013
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 19 Feb 2013 20:39:59 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1361306399.77.0.961567048306.issue17032@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:47:16 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 19 Feb 2013 20:47:16 +0000
Subject: [issue17244] py_compile.compile() fails to raise exceptions when
	writing of target file fails
Message-ID: <1361306836.21.0.240059339462.issue17244@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Since d4eb02b6aac9 py_compile.compile() fails to raise exceptions when writing of target file fails.

$ cd /tmp
$ touch test.py
$ mkdir dir
$ chmod a-w dir
mode of ?dir? changed from 0755 (rwxr-xr-x) to 0555 (r-xr-xr-x)
$ python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir/test.pyc")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.3/py_compile.py", line 141, in compile
    with open(cfile, 'wb') as fc:
PermissionError: [Errno 13] Permission denied: '/tmp/dir/test.pyc'
$ python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir/test.pyc")'
$ python3.3 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.3/py_compile.py", line 141, in compile
    with open(cfile, 'wb') as fc:
IsADirectoryError: [Errno 21] Is a directory: '/tmp/dir'
$ python3.4 -c 'import py_compile; py_compile.compile("test.py", cfile="/tmp/dir")'
$ ls -l dir
total 0
$

----------
components: Library (Lib)
messages: 182426
nosy: Arfrever, brett.cannon, eric.snow, ncoghlan, pitrou
priority: normal
severity: normal
status: open
title: py_compile.compile() fails to raise exceptions when writing of target file fails
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17244>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:51:21 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 19 Feb 2013 20:51:21 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361307081.63.0.806548429556.issue6975@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

You could probably test '.\\.' and '..\\..' etc. in these tests on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:54:55 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 20:54:55 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361307295.81.0.25108877408.issue17237@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

It must be about pointer alignment, because that's the whole point of the ASSERT.

As for the backtrace, the gdb support on the platform isn't great yet, but here it is....

Breakpoint 1, ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", 
    dest=0x1a6d592 "???????") at Objects/unicodeobject.c:4658
4658	    assert(!((size_t) dest & LONG_PTR_MASK));
(gdb) bt
#0  ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", dest=0x1a6d592 "???????")
    at Objects/unicodeobject.c:4658
#1  0x030595a6 in .L4737 () at Objects/unicodeobject.c:4741
#2  0x03044dba in .L2648 () at Objects/unicodeobject.c:1806
#3  0x03096f54 in PyUnicode_InternFromString (cp=0x30c5b04 "__len__")
    at Objects/unicodeobject.c:14284
#4  0x030c69f6 in .L1892 () at Objects/typeobject.c:6090
#5  0x030c6dc8 in add_operators (type=0x33507c8) at Objects/typeobject.c:6244
#6  0x030bfc66 in .L1249 () at Objects/typeobject.c:4182
#7  0x030bfbae in .L1241 () at Objects/typeobject.c:4146
#8  0x02ff62a8 in _Py_ReadyTypes () at Objects/object.c:1576
#9  0x0300e688 in .L60 () at Python/pythonrun.c:301
#10 0x0300ea5c in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401
#11 0x0300ea6e in Py_Initialize () at Python/pythonrun.c:407
#12 0x02ff9fca in .L135 () at Modules/main.c:657
#13 0x02ff24be in .L6 () at ./Modules/python.c:90
#14 0x03329d5a in .L76 ()
#15 0x0331731e in .L69 ()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:56:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Feb 2013 20:56:54 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361307414.68.0.77433974536.issue17237@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What will happened if you just remove this line?

----------
nosy: +serhiy.storchaka
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 21:57:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Feb 2013 20:57:28 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361307448.34.0.478820800897.issue17237@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Unicode -Build
nosy: +ezio.melotti
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:02:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 21:02:21 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361307295.81.0.25108877408.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361307538.19503.6.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> It must be about pointer alignment, because that's the whole point of
> the ASSERT.

Indeed, it's about pointer alignment, but it's not about the CPU. It's
about the compiler (or the platform's C ABI).

Apparently the compiler doesn't align struct fields to natural
boundaries like most other compilers do, which means the size of the
PyASCIIObject struct (in unicodeobject.h) ends up not being a multiple
of 4, which in turn means the "dest" pointer (allocated from the end of
that structure) is not 4 byte-aligned either.

However, you can probably safely remove the assert(), since it is there
to warn about misalignment on platforms which *are* alignment-sensitive.
There is another assert() of the same kind in unicodeobject.c, which you
can remove too.

It would be nice if the C source could be improved here, but it's not
obvious which rule to enforce exactly. We want to be lenient if the
misalignment is a product of the compiler's alignment rules, but not if
it's a mistake on our part.

Which compiler is it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:05:05 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 21:05:05 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361307905.12.0.760382657147.issue17237@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

It's GCC 4.6.3.

GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used.

----------
components: +Build -Unicode
type: crash -> 
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:07:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 21:07:09 +0000
Subject: [issue17244] py_compile.compile() fails to raise exceptions when
	writing of target file fails
In-Reply-To: <1361306836.21.0.240059339462.issue17244@psf.upfronthosting.co.za>
Message-ID: <1361308029.28.0.402211459924.issue17244@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It's because of this try/except to silence failed bytecode creation: http://hg.python.org/cpython/file/d404d33a999c/Lib/importlib/_bootstrap.py#l1105

I hate the py_compile module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17244>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:08:00 2013
From: report at bugs.python.org (Alan Hourihane)
Date: Tue, 19 Feb 2013 21:08:00 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361308080.03.0.726152659286.issue17237@psf.upfronthosting.co.za>


Alan Hourihane added the comment:

Oh, and as for pointer alignment, I probably just wasn't clear in the initial report. But we agree on m68k C ABI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:20:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 21:20:09 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361308809.1.0.315197953252.issue17237@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, so we could simply disable the assert on m68k, if you can confirm it works. Do you want to provide a patch? I don't know what the preprocessor conditional should look like.

----------
components: +Interpreter Core -Build
stage:  -> needs patch
type:  -> crash
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:36:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Feb 2013 21:36:38 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361309797.99.0.264311283285.issue17237@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps we should disable not only assert, but all optimized code inside #if SIZEOF_LONG <= SIZEOF_VOID_P / #endif block. Benchmarks needed to measure either unaligned writing speedup or slowdown decoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:45:35 2013
From: report at bugs.python.org (mirabilos)
Date: Tue, 19 Feb 2013 21:45:35 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361310335.15.0.349002542146.issue17237@psf.upfronthosting.co.za>


mirabilos added the comment:

@skrah: ?I don't think we should support this platform officially.?

Please don?t break what works. We have almost complete (about three quarters of roughly 10'000 source packages) Debian unstable working on m68k, with several versions of Python in use. Thanks!

@pitrou: ?x86 can align on a byte boundary and doesn't trigger the assert.?

That?s because most compilers on i386 do ?natural alignment? ? in fact, most compilers on most platforms do. ?natural alignment? means 4-byte quantities get aligned on 4-byte boundaries, 8-byte quantities on 8-byte boundaries, etc.

On m68k, the lowest alignment for almost all larger-than-a-byte data types is 2 byte, even though that one is strict. This means that, for example, an int is often only 2-byte aligned.

@alanh: ?GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used.?

Indeed, because that would break the C and kernel/syscall ABI.

@all: what _precisely_ is the assertion needed to check for?

@pitrou: ?since it is there to warn about misalignment on platforms which *are* alignment-sensitive?

Well, m68k is. Just the numbers differ. (It also has int, long and pointer at 32 bit.)

We had a similar issue in the Linux kernel, where it used the lower two bits of an address for flags (urgh?) which could only be solved by using GCC?s __attribute__((__aligned__(4))) on the quantities in question, but that may or may not be the required case here, which is why I?m asking.

I can test any trees on my VMs, but that takes a day or two, of course, at 50-200 BogoMIPS. You can do that yourself by running a VM as well, the Debian Wiki has instructions, if anyone is interested.

Otherwise, it?ll just get tested as soon as it hits Debian (unstable, usually we don?t build experimental packages except on explicit request by the packagers, due to lack of time / horsepower)?

Thanks doko for linking this issue!

----------
nosy: +mirabilos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 22:56:19 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Feb 2013 21:56:19 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1361303378.21.0.285956953726.issue15767@psf.upfronthosting.co.za>
Message-ID: <20130219165616.67b577c1@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On Feb 19, 2013, at 07:49 PM, Brett Cannon wrote:

>Serihy & Barry: no. We do that now and it's already a nasty little hack. It
>would be better to let people catch an exception signaling that an import
>didn't happen because some module is missing than require introspection on a
>caught ImportError to tell what is going on (there's a reason why Antoine
>went to all of that trouble to add new exceptions so we don't have to look at
>the errno attribute on OSError). Exceptions are structured to work off of
>inheritance hierarchies (says the man who co-wrote the PEP to make all PEPs
>inherit from BaseException).

The difference being that checking errno on OSError/IOError is essentially
required to do anything useful with it, while this one seems like a rare
corner case (we've been doing pretty well without it so far).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:00:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Feb 2013 22:00:04 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361310335.15.0.349002542146.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361311002.19503.11.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> We had a similar issue in the Linux kernel, where it used the lower
> two bits of an address for flags (urgh?) which could only be solved by
> using GCC?s __attribute__((__aligned__(4))) on the quantities in
> question, but that may or may not be the required case here, which is
> why I?m asking.

It is not required since, as you say, m68k only requires 2-byte
alignment. However, as Serhiy said, it may (or may not) be better for
performance. At this point, only people with access to a m68k machine or
VM (and motivated enough :-)) can do the necessary tests and propose a
way forward.

(but, performance notwithstanding, fixing the build should be a simple
matter of silencing the assert with an appropriate #if line)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:01:01 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 Feb 2013 22:01:01 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361310335.15.0.349002542146.issue17237@psf.upfronthosting.co.za>
Message-ID: <20130219220103.GA31853@sleipnir.bytereef.org>


Stefan Krah added the comment:

mirabilos <report at bugs.python.org> wrote:
> Please dont break what works. We have almost complete (about three quarters
> of roughly 10'000 source packages) Debian unstable working on m68k, with
> several versions of Python in use. Thanks!

Are you saying that the complete test suite works on m68k except for this
assert?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:05:17 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Feb 2013 22:05:17 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1361311517.51.0.183195200063.issue17192@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

An update to libffi is needed for all maintained versions of Python.

In 2.7, we're running into the stack being misaligned in 32-bit x86 code which is something a libffi update fixes.  It is a simple patch:

 http://patchwork.ozlabs.org/patch/58128/

which comes to the official libffi releases via https://github.com/atgreen/libffi/commit/3f5b1375ab1e2b8e3d593e21b27097a4a50f9b83#src/x86/sysv.S.

The problem: without the stack being 16-byte aligned, code generated by modern compilers like recent gcc/g++ or clang assumed that the stack is 16 byte aligned and uses SSE instructions in some circumstances that require this.  Without this fix, any ctypes call into such code will crash.

Sure, that tiny patch could be cherry picked into our libffi, but we IMNSHO may as well just update the entire thing given that we embed a very old copy rather than use it as an external dependency.

----------
nosy: +benjamin.peterson, georg.brandl, gregory.p.smith, larry
priority: normal -> release blocker
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:05:49 2013
From: report at bugs.python.org (mirabilos)
Date: Tue, 19 Feb 2013 22:05:49 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361311549.45.0.524601629537.issue17237@psf.upfronthosting.co.za>


mirabilos added the comment:

@pitrou: As for performance, 2-byte and 4-byte are the same on m68k, given that they usually have RAM which doesn?t benefit from that kind of alignment, and systems that are structured accordingly.

The ?best? cpp define I don?t know, but my system defines __m68k__ and Alan would probably be able to say whether this is defined on ColdFire, too.

@skrah: No, I specifically did not say that ?

But it works pretty damn well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:11:10 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Feb 2013 22:11:10 +0000
Subject: [issue17245] ctypes libffi needs to align the x86 stack to 16 bytes
Message-ID: <1361311870.54.0.433200596703.issue17245@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The problem: without the stack being 16-byte aligned, code generated by modern compilers like recent gcc/g++ or clang assumed that the stack is 16 byte aligned and uses SSE instructions in some circumstances that require this.  Without this fix, any ctypes call into such code will crash.

I mentioned this in the comment on issue17192 which seeks to update our ancient copy of libffi but we may want to do this independently of that.

In 2.7, we're running into the stack being misaligned in 32-bit x86 code which is something a libffi update fixes.  It is a trivial patch:

 http://patchwork.ozlabs.org/patch/58128/

which made it into the official libffi releases in 2010 via https://github.com/atgreen/libffi/commit/3f5b1375ab1e2b8e3d593e21b27097a4a50f9b83#src/x86/sysv.S.

patch against 2.7 attached.  it should apply to any tree easily enough.

----------
assignee: gregory.p.smith
files: fix_libffi_x86_stack_align.gps01.diff
keywords: patch
messages: 182442
nosy: benjamin.peterson, georg.brandl, gregory.p.smith, larry
priority: release blocker
severity: normal
stage: patch review
status: open
title: ctypes libffi needs to align the x86 stack to 16 bytes
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29124/fix_libffi_x86_stack_align.gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17245>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:11:59 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 19 Feb 2013 22:11:59 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1361311919.26.0.759327825417.issue17192@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

http://bugs.python.org/issue17245 filed to track the stack alignment issue.  The only reason i set this as release blocker is to let a release manager decide which of these two issues to proceed with for 2.7.4 and 3.2.4 (and 3.3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:12:40 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Feb 2013 22:12:40 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1361311960.3.0.821950107145.issue17192@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

By all means, upgrade it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:17:27 2013
From: report at bugs.python.org (Ben Wolfson)
Date: Tue, 19 Feb 2013 22:17:27 +0000
Subject: [issue12014] str.format parses replacement field incorrectly
In-Reply-To: <1304646359.82.0.599761597998.issue12014@psf.upfronthosting.co.za>
Message-ID: <1361312247.96.0.614582160962.issue12014@psf.upfronthosting.co.za>


Ben Wolfson added the comment:

"My own preference is to let this quote from PEP 3101 dominate the behaviour: "The rules for parsing an item key are very simple. If it starts with a digit, then it is treated as a number, otherwise it is used as a string."

That means Petri's suggested solution (allowing any character except a closing square bracket and braces in the item key) sounds good to me."

But ... that isn't what the quotation from the PEP says, since it doesn't exclude braces. I also don't really see why the PEP should be given much authority in this issue, since it pays extremely cursory attention to this part of the format.

In any case, judging by the filename and description (god knows I can't remember, having written it nine months ago), strformat-no-braces.diff implements that behavior. (Oh, now I see from an earlier comment of mine that that is, in fact, what it does.)

Meanwhile, it was five months ago that Eric Smith said "It's on my list of things to look at. I have a project due next week, then I'll have some time."

I understand that this is not the biggest deal, but the patch is also pretty compact and (I think) easily understood. Petri seemed to think it was mostly ok in May 2012, when, IIRC, several people on python-dev agreed that the current behavior should be changed. God only knows how unicode_format.h has changed in the interim. Peer review for academic papers moves substantially faster than this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12014>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:22:36 2013
From: report at bugs.python.org (Andrew Lutomirski)
Date: Tue, 19 Feb 2013 22:22:36 +0000
Subject: [issue17246] cgitb fails when frame arguments are deleted (due to
	inspect bug I think)
Message-ID: <1361312556.73.0.83895942435.issue17246@psf.upfronthosting.co.za>


New submission from Andrew Lutomirski:

inspect.formatargvalues assumes (incorrectly) that every argument in args is a key in values.  This isn't very hard to break -- see the attachment for a complete example.

----------
components: Library (Lib)
files: test_cgitb.py
messages: 182446
nosy: Andrew.Lutomirski
priority: normal
severity: normal
status: open
title: cgitb fails when frame arguments are deleted (due to inspect bug I think)
versions: Python 2.7
Added file: http://bugs.python.org/file29125/test_cgitb.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17246>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:24:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 22:24:53 +0000
Subject: [issue17247] Decimal doesn't support aligned fill
Message-ID: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>


New submission from Christian Heimes:

>>> "{:<06}".format(1.2)
'1.2000'
>>> "{:<06}".format(decimal.Decimal(1.2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid format string

----------
assignee: skrah
messages: 182447
nosy: christian.heimes, skrah
priority: normal
severity: normal
status: open
title: Decimal doesn't support aligned fill
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:26:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Feb 2013 22:26:59 +0000
Subject: [issue17247] Decimal doesn't support aligned fill
In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>
Message-ID: <1361312819.33.0.619787092481.issue17247@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, mark.dickinson
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:29:51 2013
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 19 Feb 2013 22:29:51 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1361312991.58.0.612618296685.issue17192@psf.upfronthosting.co.za>


Matthias Klose added the comment:

before the updates, ... there seem to be two test failures on sparc solaris. the local libffi/src/sparc/v8.S change was integrated upstream, so I don't yet what could cause these failures. or did they fail before too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:34:53 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 Feb 2013 22:34:53 +0000
Subject: [issue17247] Decimal doesn't support aligned fill
In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>
Message-ID: <1361313293.88.0.93102551456.issue17247@psf.upfronthosting.co.za>


Stefan Krah added the comment:

3.2 has a better error message:

>>> "{:<06}".format(Decimal("1.2"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/decimal.py", line 3632, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/usr/lib/python3.2/decimal.py", line 5600, in _parse_format_specifier
    "format specifier: " + format_spec)
ValueError: Alignment conflicts with '0' in format specifier: <06


That's because '0' already has a special meaning:

"Preceding the width field by a zero ('0') character enables sign-aware zero-padding for numeric types. This is equivalent to a fill character of '0' with an alignment type of '='."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:36:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2013 22:36:36 +0000
Subject: [issue17247] Decimal doesn't support aligned fill
In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>
Message-ID: <1361313396.75.0.00349079358128.issue17247@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The output is from Python 3.3. Why has Python 3.3 a less informative error message than 3.2?

I also wonder why it works with floats if it has a special meaning? Either float or Decimal is broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Tue Feb 19 23:50:00 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 Feb 2013 22:50:00 +0000
Subject: [issue17247] Decimal doesn't support aligned fill
In-Reply-To: <1361313396.75.0.00349079358128.issue17247@psf.upfronthosting.co.za>
Message-ID: <20130219225002.GA32532@sleipnir.bytereef.org>


Stefan Krah added the comment:

Christian Heimes <report at bugs.python.org> wrote:
> The output is from Python 3.3. Why has Python 3.3 a less informative error message than 3.2?

Because the error is discovered in libmpdec and it would require a significant
amount of work to provide fine-grained error messages.

> I also wonder why it works with floats if it has a special meaning?
> Either float or Decimal is broken.

Yes, IMO float should detect the ambiguity. You see that the zero implies left
padding:

>>> "{:06}".format(1.2)
'0001.2'

And in case of a conflict right padding wins:

>>> "{:<06}".format(1.2)
'1.2000'

The unambiguous way to get right padding is:

>>> "{:0<6}".format(Decimal("1.2"))
'1.2000'

>>> "{:X<6}".format(Decimal("1.2"))
'1.2XXX'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Wed Feb 20 00:26:09 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 Feb 2013 23:26:09 +0000
Subject: [issue17247] int and float should detect inconsistent format strings
In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>
Message-ID: <1361316369.47.0.0899286589763.issue17247@psf.upfronthosting.co.za>


Stefan Krah added the comment:

With int and float it's also possible to specify both conflicting
alignments and fill characters:


 >>> "{:x<06}".format(1.2)
'1.2xxx'


So I really think that the builtins should be changed to detect
the conflict.

----------
assignee: skrah -> 
components: +Interpreter Core
title: Decimal doesn't support aligned fill -> int and float should detect inconsistent format strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Wed Feb 20 00:33:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Feb 2013 23:33:46 +0000
Subject: [issue6623] Lib/ftplib.py netrc class parsing problem
In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>
Message-ID: <3Z9dYj5jY6zSpX@mail.python.org>


Roundup Robot added the comment:

New changeset acf247d25f17 by R David Murray in branch 'default':
#6623: Add explicit deprecation warning for ftplib.Netrc.
http://hg.python.org/cpython/rev/acf247d25f17

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________

From report at bugs.python.org  Wed Feb 20 00:40:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Feb 2013 23:40:46 +0000
Subject: [issue6623] Lib/ftplib.py Netrc class should be removed.
In-Reply-To: <1249165781.68.0.418938928921.issue6623@psf.upfronthosting.co.za>
Message-ID: <1361317246.26.0.103546581182.issue6623@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the report.

ftplib.Netrc has been deprecated (via its doc string) since at least Python 2.4, and is no longer documented in the library reference.  I've added an explicit DeprecationWarning in Python 3.4, and have altered this issue to call for its complete removal in Python 3.5.

I am not planning to fix the existing code, because IMO with deprecated code this old the chance of breaking something exceeds the chance that the bad code will do harm.

----------
nosy: +r.david.murray
priority: normal -> release blocker
stage:  -> needs patch
title: Lib/ftplib.py netrc class parsing problem -> Lib/ftplib.py Netrc class should be removed.
type:  -> enhancement
versions: +Python 3.5 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6623>
_______________________________________

From report at bugs.python.org  Wed Feb 20 01:25:08 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Feb 2013 00:25:08 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361319908.42.0.758692422717.issue15767@psf.upfronthosting.co.za>


Eric Snow added the comment:

The common case for catching ImportError is exactly what ModuleNotFoundError represents.  If people are already going to change their code to handle just this special case, I'd think having the subclass would be the better route.  I find it simpler (both to update existing code and to read:

    try:
        from _thread import _local as local
    except ModuleNotFoundError:
        from _threading_local import local

vs.

    try:
        from _thread import _local as local
    except ImportError as e:
        if e.not_found:
            from _threading_local import local
        else:
            raise

And for the broader case:

    try:
        import breakfast
    except ModuleNotFoundError:
        class breakfast:
            spam = 0
            eggs = 1
            ham = 2
    except ImportError as e:
        log_some_message("uh oh: {}".format(e))
        raise

vs.

    try:
        import breakfast
    except ImportError as e:
        if e.not_found:
            class breakfast:
                spam = 0
                eggs = 1
                ham = 2
        else:
            log_some_message("uh oh: {}".format(e))
            raise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Wed Feb 20 01:41:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 00:41:55 +0000
Subject: [issue6541] SpooledTemporaryFile breakages
In-Reply-To: <1248227663.52.0.385641131196.issue6541@psf.upfronthosting.co.za>
Message-ID: <1361320915.3.0.760737713675.issue6541@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the report, and sorry we didn't handle it when you reported it.  This issue was re-reported and fixed in issue #10355.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> SpooledTemporaryFile's name property is broken

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6541>
_______________________________________

From report at bugs.python.org  Wed Feb 20 01:55:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Feb 2013 00:55:05 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <3Z9gMX6mJfzSy0@mail.python.org>


Roundup Robot added the comment:

New changeset 662f97427acf by Ezio Melotti in branch '3.3':
#17143: fix buildbot failures on Windows.
http://hg.python.org/cpython/rev/662f97427acf

New changeset 1bf0ff7db856 by Ezio Melotti in branch 'default':
#17143: merge with 3.3.
http://hg.python.org/cpython/rev/1bf0ff7db856

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Wed Feb 20 02:01:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Feb 2013 01:01:15 +0000
Subject: [issue7842] py_compile.compile SyntaxError output
In-Reply-To: <1265151004.56.0.531784942224.issue7842@psf.upfronthosting.co.za>
Message-ID: <3Z9gVf65S5zRdZ@mail.python.org>


Roundup Robot added the comment:

New changeset c7f04c09dc56 by R David Murray in branch '2.7':
#7842: backport fix for py_compile.compile syntax error message handling.
http://hg.python.org/cpython/rev/c7f04c09dc56

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7842>
_______________________________________

From report at bugs.python.org  Wed Feb 20 02:02:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 01:02:13 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361322133.07.0.124284379163.issue15767@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why not just

    try:
        from _thread import _local as local
    except ImportError:
        from _threading_local import local

?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Wed Feb 20 02:03:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 01:03:32 +0000
Subject: [issue7842] py_compile.compile SyntaxError output
In-Reply-To: <1265151004.56.0.531784942224.issue7842@psf.upfronthosting.co.za>
Message-ID: <1361322212.91.0.98878736458.issue7842@psf.upfronthosting.co.za>


R. David Murray added the comment:

Better late than never.  Be nice if someone would contribute a test, but I'm not going let that hold things up for such a simple patch that is already in default with no test.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7842>
_______________________________________

From report at bugs.python.org  Wed Feb 20 02:23:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 01:23:11 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
Message-ID: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>


New submission from R. David Murray:

I'm a member of group root, and the _test_all_chown_common tests that use -1, 0 fail for me, because I'm allowed to set group root on a file.

----------
components: Tests
messages: 182461
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posix chown -1, 0 tests fail if user has group root
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 02:31:08 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 20 Feb 2013 01:31:08 +0000
Subject: [issue17247] int and float should detect inconsistent format strings
In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za>
Message-ID: <1361323868.53.0.246064160074.issue17247@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17247>
_______________________________________

From report at bugs.python.org  Wed Feb 20 02:51:31 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 01:51:31 +0000
Subject: [issue17143] trace.py uses _warn without importing it
In-Reply-To: <1360163681.51.0.340414481892.issue17143@psf.upfronthosting.co.za>
Message-ID: <1361325091.91.0.72267683744.issue17143@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This should be fixed now.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17143>
_______________________________________

From report at bugs.python.org  Wed Feb 20 04:01:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 03:01:29 +0000
Subject: [issue17249] reap threads in test_capi
Message-ID: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The attached patch fixes the following warning:

$ ./python -m test test_capi
[1/1] test_capi
Warning -- threading._dangling was modified by test_capi
1 test altered the execution environment:
    test_capi

This test was introduced in f7993dc6bf26, and it seems to predate unittest.  Maybe it should be moved outside test_main while we are at it.

----------
components: Tests
files: reap_threads.diff
keywords: patch
messages: 182463
nosy: ezio.melotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: reap threads in test_capi
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29126/reap_threads.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Wed Feb 20 04:06:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 03:06:32 +0000
Subject: [issue7981] False failure with doctest NORMALIZE_WHITESPACE in 3.1.1
In-Reply-To: <1266843664.38.0.930233999383.issue7981@psf.upfronthosting.co.za>
Message-ID: <1361329592.35.0.0641522530036.issue7981@psf.upfronthosting.co.za>


R. David Murray added the comment:

This doesn't have anything to do with NORMALIZE_WHITESPACE.

In python3, <file>.write returns the number of bytes written, instead of None.  If you add the 38 to the end of your test line, the test will pass.

This is not a bug in doctest, but a difference in 'write' behavior between Python2 and Python3.  You can write doctests that will pass on both by explicitly discarding the return value:

    >>> _ = sys.stdout.write("xxxx").
    xxxx

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7981>
_______________________________________

From report at bugs.python.org  Wed Feb 20 04:38:28 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 03:38:28 +0000
Subject: [issue4963] mimetypes.guess_extension result changes after
	mimetypes.init()
In-Reply-To: <1232107494.83.0.0570958889295.issue4963@psf.upfronthosting.co.za>
Message-ID: <1361331508.93.0.611495763075.issue4963@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'd forgotten about this issue.  I wonder if the dictionary randomization makes the problem worse.

----------
components: +email
nosy: +barry
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4963>
_______________________________________

From report at bugs.python.org  Wed Feb 20 04:50:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Feb 2013 03:50:35 +0000
Subject: [issue15767] add ImportNotFoundError
In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>
Message-ID: <1361332235.14.0.811034069491.issue15767@psf.upfronthosting.co.za>


Eric Snow added the comment:

Right.  Sorry I wasn't more clear.  Existing code will continue to work either way.  The point is in exposing the distinct module/name-not-found case, which I consider to be the common case for catching ImportError.  My examples cover the case where you want to handle the module-not-found case specifically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15767>
_______________________________________

From report at bugs.python.org  Wed Feb 20 05:26:23 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Feb 2013 04:26:23 +0000
Subject: [issue15004] add weakref support to types.SimpleNamespace
In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>
Message-ID: <1361334383.37.0.872035396695.issue15004@psf.upfronthosting.co.za>


Eric Snow added the comment:

Good point.  Thanks.  I've updated the test.  Does that cover it?

----------
Added file: http://bugs.python.org/file29127/simplenamespace-weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15004>
_______________________________________

From report at bugs.python.org  Wed Feb 20 05:26:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 20 Feb 2013 04:26:39 +0000
Subject: [issue15004] add weakref support to types.SimpleNamespace
In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>
Message-ID: <1361334399.62.0.581671336651.issue15004@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file29094/simplenamespace-weakref.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15004>
_______________________________________

From report at bugs.python.org  Wed Feb 20 05:40:26 2013
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 20 Feb 2013 04:40:26 +0000
Subject: [issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
In-Reply-To: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za>
Message-ID: <1361335226.08.0.345170541032.issue15587@psf.upfronthosting.co.za>


Tyler Crompton added the comment:

I will gladly test the changes. Where would I find these to download?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15587>
_______________________________________

From report at bugs.python.org  Wed Feb 20 05:58:17 2013
From: report at bugs.python.org (paul j3)
Date: Wed, 20 Feb 2013 04:58:17 +0000
Subject: [issue17250] argparse: Issue 15906 patch;
	positional with nargs='*' and string default
Message-ID: <1361336297.12.0.955168493515.issue17250@psf.upfronthosting.co.za>


New submission from paul j3:

The production argparse applies the type conversion to a string default whether it is needed or not.  With the 12776 and 15906 patch, that conversion is postponed, so that it is applied only once.  However, for a positional argument with nargs='*', that conversion is never applied.

For example, with:
add_argument('foo', type=FileType('r'), default='anyfile', nargs='*')

the development version, with parse_args([]) produces
Namespace(foo='anyfile')

The previous code tested this default, raising an error if there was an IOError.  But even if it successfully opened the file, the namespace
 would get the string value, not the opened file.

With nargs = '?', the result is an IOError, or an opened file.

It is evident from the code (but not the documentation) that the best
default for the '*' positional is a list of appropriate type of objects.
In the case of FileTypes, about the only choices, without opening a
file, are: [] and [sys.stdin].

----------
components: Library (Lib)
messages: 182469
nosy: paul.j3
priority: normal
severity: normal
status: open
title: argparse: Issue 15906 patch; positional with nargs='*' and string default
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17250>
_______________________________________

From report at bugs.python.org  Wed Feb 20 06:04:05 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 20 Feb 2013 05:04:05 +0000
Subject: [issue17250] argparse: Issue 15906 patch;
	positional with nargs='*' and string default
In-Reply-To: <1361336297.12.0.955168493515.issue17250@psf.upfronthosting.co.za>
Message-ID: <1361336645.14.0.949240673708.issue17250@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
nosy: +bethard, chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17250>
_______________________________________

From report at bugs.python.org  Wed Feb 20 06:08:56 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Feb 2013 05:08:56 +0000
Subject: [issue17032] Misleading error message: global name 'X' is not defined
In-Reply-To: <1359124974.58.0.158587338796.issue17032@psf.upfronthosting.co.za>
Message-ID: <1361336936.74.0.896434742429.issue17032@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

+    NAME_ERROR_MSGy, name);
will give a NameError ;-).

The patch undoes the change from 'name' to 'global name'. Skimming the PEP, I do not see this change mandated or justified by the PEP. So my current view: while it is true that it is the final, global name lookup that fails, I agree with Ram that it is not necessarily a global name that was mistyped or is missing. So in absence of better justification of the status quo, I would apply the patch. Backport to 3.3 would be ok but not necessary, as the message is not nearly as wrong as some have been.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17032>
_______________________________________

From report at bugs.python.org  Wed Feb 20 06:41:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 05:41:38 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1361338898.44.0.243684187865.issue9116@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Vinay commit made the test pass, but the popup is still present.
Removing the popup is discussed in #11732.

----------
nosy: +ezio.melotti
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Wed Feb 20 06:45:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Feb 2013 05:45:42 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1361339142.57.0.936266588276.issue17145@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am looking at this as a naive user, and can only assume that the claims are correct.

+The new C-level buffer API has been backported to Python 2.6 and the
+Python-level :class:`memoryview` object has been backported to Python 2.7.
+To be clear, in Python 2.6 and 2.7, there are two C-level interfaces, both
+exposed by the :ctype:`PyBufferProcs` interface: the new buffer API and the
+old buffer API. The :class:`memoryview` object is the product of the new API
+while :class:`buffer` is the product of the old API (the former of which is
+only available in 2.7+).

This part strikes me as a bit jumbled. Is it necessary to discuss 2.6 in 2.7 docs? the last parenthetical comment repeats what was said in an earlier sentence.

Benjamin, I am adding you because you are listed as an author of the section being revised.

----------
nosy: +benjamin.peterson, terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17145>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:21:24 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 20 Feb 2013 06:21:24 +0000
Subject: [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1361341284.96.0.780415416545.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Yes, I agree that passage is a little garbled. I've reworked that particular paragraph in the new patch.

I had included a little information about 2.6 as it was in the revision prior to my patch (and there was also some historical context back to 1.6). I think that 2.6-specific information is irrelevant in this particular doc (after all, it's 2.7-specific and not a change log ;)) and therefore have removed it.

----------
Added file: http://bugs.python.org/file29128/buffer.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17145>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:24:40 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 06:24:40 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1361341480.6.0.265819723263.issue11732@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here is a proof of concept patch that defines a context manager that disables the crash popups using SetErrorMode [0].  I tested it only on Windows 7 (and Linux, where it's a no-op).  As an example, the patch fixes the crash popup caused by test_capi.

[0]: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680621%28v=vs.85%29.aspx

FWIW I attempted to use WerRegisterRuntimeExceptionModule too, and I was able to access it from ctypes.windll.kernel32.WerRegisterRuntimeExceptionModule on Win7, but then it wanted me to define a DLL with 3 functions, so I tried to find a simpler solution.

----------
nosy: +ezio.melotti
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:25:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 06:25:45 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1361341545.7.0.334403301011.issue11732@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29129/nopopup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:26:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 06:26:13 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1361341573.61.0.377136752128.issue11732@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file29129/nopopup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:26:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 06:26:51 +0000
Subject: [issue11732] Skip decorator for tests requiring manual intervention
	on Windows
In-Reply-To: <1301604811.48.0.519862680053.issue11732@psf.upfronthosting.co.za>
Message-ID: <1361341611.22.0.938852546492.issue11732@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29130/nopopup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11732>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:43:41 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Feb 2013 06:43:41 +0000
Subject: [issue15587] IDLE is pixelated on the Macbook Pro with Retina Display
In-Reply-To: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za>
Message-ID: <1361342621.87.0.753032499029.issue15587@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks, Tyler.  The 2.7.4 and 3.2.4 maintenance releases have been delayed due to some critical issues and so we don't have a new availability date for the first release candidates.  I'll try to remember to ping here when that happens.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15587>
_______________________________________

From report at bugs.python.org  Wed Feb 20 07:48:33 2013
From: report at bugs.python.org (B. Kyven)
Date: Wed, 20 Feb 2013 06:48:33 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
Message-ID: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>


New submission from B. Kyven:

Hello,

I am using LWPCookieJar to store cookies. But I am having trouble.
Saving is fine, load is wrong. I use Cookie.domain_specified to judge if domain exist.

save the following to test.lwp
-----------------
#LWP-Cookies-2.0
Set-Cookie3: name=value; path="/ddd/"; domain=".domain.com"; path_spec; domain_dot; secure; expires="2030-05-09 14:25:11Z"; version=0
Set-Cookie3: name=value; path="/ddd/"; domain="www.domain.com"; path_spec; secure; expires="2030-05-09 14:25:11Z"; version=0
-----------------

>cj = LWPCookieJar('test.lwp').load()
>for c in cj:
>    print c.domain, c.domain_specified, c.domain_initial_dot

output:
.domain.com       True      True
www.domain.com  **False**   True

If understood correctly, domain_specified should equal bool(c.domain ="").

This is seen on 2.7 and 2.6.

----------
components: Library (Lib)
messages: 182476
nosy: B. Kyven
priority: normal
severity: normal
status: open
title: LWPCookieJar load() set domain_specifed wrong
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Wed Feb 20 08:40:04 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 20 Feb 2013 07:40:04 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361346004.46.0.215280641072.issue17227@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I noticed this before and wasn't able to fix it after trying a few things.  I wonder if this is a limitation or bug in Sphinx.  At the top, the FAQ page has--

:tocdepth: 2

Levels beyond 2 are getting numbered 25 (the number of the top level) instead of having their numbering suppressed (as I would expect it to).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Wed Feb 20 08:47:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 07:47:45 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361346465.98.0.682563561651.issue17227@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Georg, do you know how to fix this?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Wed Feb 20 08:52:57 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Feb 2013 07:52:57 +0000
Subject: [issue17241] Python-2.3.5.exe file possibly corrupt
In-Reply-To: <1361299332.57.0.860667306426.issue17241@psf.upfronthosting.co.za>
Message-ID: <1361346777.82.0.65089057216.issue17241@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I'm getting the complete file here, too.

----------
nosy: +skrah
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17241>
_______________________________________

From report at bugs.python.org  Wed Feb 20 08:56:21 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 20 Feb 2013 07:56:21 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361346981.63.0.702663217911.issue17227@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Levels beyond 2 are getting numbered 25 (the number of the top level) instead of having their numbering suppressed (as I would expect it to).

Actually, what I meant to say is that I would expect the "tocdepth" to affect only the level of the table of contents that is displayed (which it does), but not suppress or otherwise affect the numbering of the sections in the actual text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Wed Feb 20 09:50:44 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Feb 2013 08:50:44 +0000
Subject: [issue17235] "make sharedinstall" ignores ./configure settings
In-Reply-To: <1361269225.76.0.790784107865.issue17235@psf.upfronthosting.co.za>
Message-ID: <1361350244.33.0.74178035435.issue17235@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry, I'm unable to reproduce your results and they look rather suspicious.  Keep in mind that the Python build uses its copy of Distutils to build and install the interpreter's shared extension modules, like _ctypes.so.  My guess is that your "make install" is being influenced by settings in a Distutils configuration file, such as ~/.pydistutils.cfg.  If so, this is a duplicate of Issue4655.

http://docs.python.org/2/install/index.html#distutils-configuration-files

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> pending
superseder:  -> during Python installation, setup.py should not use .pydistutils.cfg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17235>
_______________________________________

From report at bugs.python.org  Wed Feb 20 09:53:50 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Feb 2013 08:53:50 +0000
Subject: [issue6138] './configure;
	make install' fails in setup.py step if .pydistutils.cfg specifies
	'home'
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1361350430.78.0.0615688977482.issue6138@psf.upfronthosting.co.za>


Ned Deily added the comment:

Let's consolidate these.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> during Python installation, setup.py should not use .pydistutils.cfg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Wed Feb 20 09:55:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Feb 2013 08:55:51 +0000
Subject: [issue4655] during Python installation,
	setup.py should not use .pydistutils.cfg
In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za>
Message-ID: <1361350551.28.0.103794893679.issue4655@psf.upfronthosting.co.za>


Ned Deily added the comment:

rdm notes in duplicate Issue6138:

There is a bug here, of some sort.  Either the .pydistutils.cfg file's
install clause should override the default --prefix somehow, or the
error message should indicate where the setting for 'home' and
'--prefix' came from to enable the user to debug the configuration.  In
the latter case there would also need to be a way to explicitly tell
either make install or configure to ignore .pydistutils.cfg.  In the
former case, an explicit --prefix passed to configure would need to
override .pydistutils.cfg.

----------
nosy: +ned.deily, r.david.murray -BreamoreBoy
versions: +Python 3.3, Python 3.4 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4655>
_______________________________________

From report at bugs.python.org  Wed Feb 20 10:13:53 2013
From: report at bugs.python.org (Michael Kuhn)
Date: Wed, 20 Feb 2013 09:13:53 +0000
Subject: [issue17235] "make sharedinstall" ignores ./configure settings
In-Reply-To: <1361269225.76.0.790784107865.issue17235@psf.upfronthosting.co.za>
Message-ID: <1361351633.29.0.0148502230757.issue17235@psf.upfronthosting.co.za>


Michael Kuhn added the comment:

Thanks a lot Ned: you're right, the unexpected path was indeed set in ~/.pydistutils.cfg. So I agree with what has been written in the other issues, that the installation should detect the clash between the command line configuration and the configuration file to alert the unsuspecting user.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17235>
_______________________________________

From report at bugs.python.org  Wed Feb 20 10:14:15 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 09:14:15 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
Message-ID: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>


New submission from Firat Ozgul:

lower() method of strings gives different output for 'Latin Capital Letter I with Dot Above' on Python 3.2 and Python 3.3. 

On Python 3.2 (Windows XP):

>>> "\u0130".lower()
'i' #this is correct

On Python 3.3 (Windows XP):

>>> "\u0130".lower()
'i\u0307' #this is wrong

Why is this difference? This breaks code, because 'i' and 'i\u0307' are different letters.

----------
messages: 182485
nosy: firatozgul
priority: normal
severity: normal
status: open
title: Latin Capital Letter I with Dot Above
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 11:21:07 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 20 Feb 2013 10:21:07 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1361355667.89.0.0693356292026.issue17239@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Wed Feb 20 11:57:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 10:57:33 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361357853.65.0.366153455145.issue17252@psf.upfronthosting.co.za>


R. David Murray added the comment:

I thought this would just be a difference in the unicode database, but that appears not to be the case.  Ezio, this is related to the infamous Turkic dotless lower case i problem (see, eg, http://mail.python.org/pipermail/python-bugs-list/2005-October/030686.html).

The SpecialCasing.txt file entries for these characters seems to be the same in 6.0.0 (3.2) and 6.1.0 (3.3).  So the question is, why did the Python behavior change, and is it indeed a bug?  What python3.3 is returning is the canonical version, which would seem to be correct.  Have we been buggy up to this point and something got fixed?

And, referencing that thread above, how does one do a locale dependent lower case?

----------
components: +Unicode
nosy: +ezio.melotti, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 12:31:59 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 11:31:59 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361359919.37.0.228016952353.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

In Python, things like lowercasing-uppercasing and sorting were always problematic with regard to Turkish language. For instance, whatever the locale is, you cannot lowercase the word 'KADIN' (woman) in Turkish correctly::

    >>> "KADIN".lower()

    'kadin'

... which is wrong. That should be 'kad?n' ('kad\u0131n'). Likewise 'kitap' (book)::

    >>> "kitap".upper()

    'KITAP'

... which is wrong. That should be 'K?TAP' ('K\u0130TAP').

As for this thread, in 3.3, Python does a completely different thing::

    >>> "K?TAP".lower()

    'ki\u0307tap' #wrong

In Python 3.2, this was::

    >>> "K?TAP".lower()

    'kitap' #correct

'i' and 'i\u0307' are not the same. 

Turkish Python programmers define their own upper(), lower(), title(), swapcase() and casefold() methods and use their own sorting techniques.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 12:45:29 2013
From: report at bugs.python.org (Jason R Briggs)
Date: Wed, 20 Feb 2013 11:45:29 +0000
Subject: [issue17253] stdin.readline behaviour different between IDLE and the
	console
Message-ID: <1361360729.12.0.267865826707.issue17253@psf.upfronthosting.co.za>


New submission from Jason R Briggs:

The sys.stdin.readline function takes a limit parameter, which limits the number of characters read. If you try using that parameter in IDLE, you get the following error:

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.stdin.readline(13)
TypeError: readline() takes exactly 1 positional argument (2 given)

I've tried this in a number of different versions and it looks to have been like this for a while. A possible fix looks fairly straightforward. Something vaguely like...

<     def readline(self):
---
>     def readline(self, limit=-1):
993a994,995
>         if limit >= 0:
>             line = line[0:limit]

(with apologies if this is a dup ticket -- there seems to be a number of tickets raised regarding issues with IDLE and its version stdin/stdout, but I couldn't see any which discussed this particular behaviour).

----------
components: IDLE
messages: 182488
nosy: jason.briggs
priority: normal
severity: normal
status: open
title: stdin.readline behaviour different between IDLE and the console
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17253>
_______________________________________

From report at bugs.python.org  Wed Feb 20 12:48:44 2013
From: report at bugs.python.org (albertjan)
Date: Wed, 20 Feb 2013 11:48:44 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
Message-ID: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za>


New submission from albertjan:

This is almost identical to: http://bugs.python.org/issue854511
However, tis602, which is mentioned in the orginal bug report, is not an alias to cp874. Therefore, I propose the following:

import encodings

aliases = encodings.aliases.aliases
more_aliases = {'ibm874'     : 'cp874',
                'iso_8859_11': 'cp874',
                'iso8859_11' : 'cp874',
                'windows_874': 'cp874',
               }
aliases.update(more_aliases)

----------
messages: 182489
nosy: fomcl at yahoo.com
priority: normal
severity: normal
status: open
title: add thai encoding aliases to encodings.aliases

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Wed Feb 20 12:50:56 2013
From: report at bugs.python.org (Jason R Briggs)
Date: Wed, 20 Feb 2013 11:50:56 +0000
Subject: [issue17253] stdin.readline behaviour different between IDLE and the
	console
In-Reply-To: <1361360729.12.0.267865826707.issue17253@psf.upfronthosting.co.za>
Message-ID: <1361361056.26.0.890369852184.issue17253@psf.upfronthosting.co.za>


Jason R Briggs added the comment:

Note, that change I quoted would be in idlelib/PyShell.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17253>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:00:48 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 12:00:48 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361361648.47.0.899831708172.issue17252@psf.upfronthosting.co.za>


R. David Murray added the comment:

Right, and the unicode consortium says that that weird thing 3.3 is doing is the "canonical" lowercasing, and this is the case exactly because in 3.3 "\u0130".lower().upper() == "\u0130".  Which I why I asked Ezio if we ever came up with a way to do lower/upper in a locale specific manner.

The behavior change is an issue, but I'm thinking the 3.3 behavior is probably the "correct" behavior per the unicode standard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:11:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 12:11:08 +0000
Subject: [issue15004] add weakref support to types.SimpleNamespace
In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>
Message-ID: <1361362268.83.0.784358578782.issue15004@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Good, except that you have to add a gc.collect() call for the non-refcounted implementations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15004>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:22:21 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Feb 2013 12:22:21 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za>
Message-ID: <5124BFFC.8080505@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.02.2013 12:48, albertjan wrote:
> 
> New submission from albertjan:
> 
> This is almost identical to: http://bugs.python.org/issue854511
> However, tis602, which is mentioned in the orginal bug report, is not an alias to cp874. Therefore, I propose the following:
> 
> import encodings
> 
> aliases = encodings.aliases.aliases
> more_aliases = {'ibm874'     : 'cp874',
>                 'iso_8859_11': 'cp874',
>                 'iso8859_11' : 'cp874',
>                 'windows_874': 'cp874',
>                }
> aliases.update(more_aliases)

Please provide evidence that those encodings are indeed the same.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:24:09 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 12:24:09 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361363049.98.0.0650680240897.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

r.david.murray: '(...) because in 3.3 "\u0130".lower().upper() == "\u0130"'

Do you mean in Python 3.3 "\u0130".lower() returns "\u0130"?

If you are saying so, this is not the case, because in Python 3.3::

    >>> '\u0130'.lower()

    'i\u0307'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:28:22 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 12:28:22 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361363302.21.0.0557867636893.issue17252@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, I think 3.3 is correct here. I think it was Benjamin who fixed/improved the behaviour of casing methods. Compare 3.3:

>>> "?".upper()
'SS'

with 3.2:

>>> "?".upper()
'?'

Also, 3.2 loses information:

>>> "K?TAP".lower().upper()
'KITAP'
>>> ascii("K?TAP".lower().upper())
"'KITAP'"

while 3.3 retains it:

>>> "K?TAP".lower().upper()
'KI?TAP'
>>> ascii("K?TAP".lower().upper())
"'KI\\u0307TAP'"

You can get the combined form again with unicodedata.normalize:

>>> unicodedata.normalize("NFC", "K?TAP".lower().upper())
'K?TAP'

----------
nosy: +benjamin.peterson, haypo, lemburg, pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:32:03 2013
From: report at bugs.python.org (wim glenn)
Date: Wed, 20 Feb 2013 12:32:03 +0000
Subject: [issue17255] test_any and test_all should validate short-circuiting
	behaviour
Message-ID: <1361363523.21.0.389382040162.issue17255@psf.upfronthosting.co.za>


New submission from wim glenn:

The docs http://docs.python.org/2/library/functions.html#all provide some equivalent code for all builtin (and similarly for any):

def all(iterable):
    for element in iterable:
        if not element:
            return False
    return True

The behaviour is clearly documented as short-circuiting, but the cases contained in test_builtin.py are lacking any test coverage for the short-circuiting behaviour.  You could implement any/all in a broken way that still passes the current tests (consuming more of a generator than you want to for example), so it is important to guarantee the short-circuiting.

My patch adds two simple test cases to make this behaviour explicit.

----------
components: Tests
files: mywork.patch
keywords: patch
messages: 182496
nosy: wim.glenn
priority: normal
severity: normal
status: open
title: test_any and test_all should validate short-circuiting behaviour
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29131/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17255>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:36:42 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 12:36:42 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361363802.94.0.748913764526.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Don't you think that there is a problem here?

>>> "K?TAP".lower().upper()
'K?TAP'
>>> ascii("K?TAP".lower().upper())
"'KI\\u0307TAP'"

"?" is not "i\u0307". That's a different letter. "i\u0307"is 'i with combining dot above'. However, "?" is "\u0130" (Latin Capital Letter I with Dot Above).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:44:43 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 12:44:43 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361364283.25.0.325169064181.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

ascii("K?TAP".lower().upper()) should return "K\u0130TAP".

Yes, Python 3.2 loses information, but Python 3.3 inserts faulty information, which, I think, is much worse than losing information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:45:16 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 12:45:16 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361364316.11.0.450381594013.issue17252@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, you are right, I did not decode it to see what the actual characters were.

That does contradict what I said, but I'm way out of my depth on unicode at this point, so we'll have to wait for someone more expert to weigh in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 13:45:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 12:45:37 +0000
Subject: [issue17253] stdin.readline behaviour different between IDLE and the
	console
In-Reply-To: <1361360729.12.0.267865826707.issue17253@psf.upfronthosting.co.za>
Message-ID: <1361364337.82.0.498804745823.issue17253@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already fixed in issue9290.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17253>
_______________________________________

From report at bugs.python.org  Wed Feb 20 14:05:05 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Wed, 20 Feb 2013 13:05:05 +0000
Subject: [issue17164] MozillaCookieJar does not handle session cookies
In-Reply-To: <1360358603.06.0.441613239061.issue17164@psf.upfronthosting.co.za>
Message-ID: <1361365505.16.0.136759856764.issue17164@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

I could try to write a patch with some help if there was any chance it might be accepted. Where do I start?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17164>
_______________________________________

From report at bugs.python.org  Wed Feb 20 14:14:20 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 13:14:20 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361366060.88.0.60941554752.issue17252@psf.upfronthosting.co.za>


Changes by Firat Ozgul <ozgulfirat at gmail.com>:


----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 14:20:15 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 13:20:15 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361366415.83.0.644402850492.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Excerpt from http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt

# Turkish and Azeri

# I and i-dotless; I-dot and i are case pairs in Turkish and Azeri
# The following rules handle those cases.

0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE
0130; 0069; 0130; 0130; az; # LATIN CAPITAL LETTER I WITH DOT ABOVE

So the code 0130 should be 0069 in lowercase; 0130 in uppercase; 0130 in titlecase; and again 0130 in uppercase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 14:39:04 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 20 Feb 2013 13:39:04 +0000
Subject: [issue15004] add weakref support to types.SimpleNamespace
In-Reply-To: <1338865132.4.0.472631439697.issue15004@psf.upfronthosting.co.za>
Message-ID: <1361367544.4.0.939945573161.issue15004@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Good, except that you have to add a gc.collect() call for the 
> non-refcounted implementations.

Better to use test.support.gc_collect().

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15004>
_______________________________________

From report at bugs.python.org  Wed Feb 20 14:50:17 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Feb 2013 13:50:17 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361368217.19.0.826143465464.issue17252@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Notice the lines you pulled have "tr" and "az" at the end of them meaning they only apply for Turkish and Azeri. Since the lower() method has no idea whether the user intends to be in a Turkish or Azeri locale or not, we just have to use the generic lowering mapping which simply preserves canonical equivalence.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 14:59:24 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 13:59:24 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361368764.6.0.990261223111.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Even if you set Turkish locale, the output is still "generic".

Furthermore, does "canonical equivalence" really dictate that 'Latin Capital Letter I with Dot Above' should be mapped to 'I With Combining Dot Above' in lowercase?

Note: 'Uppercase Dotted i' only exists in Turkish and Azeri.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:19:58 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:19:58 +0000
Subject: [issue16245] Update html.entities.html5 dictionary and
	parseentities.py
In-Reply-To: <1350380511.49.0.860998010837.issue16245@psf.upfronthosting.co.za>
Message-ID: <1361369998.17.0.0827769671374.issue16245@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Shouldn't this be deferred blocker?

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16245>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:23:08 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:23:08 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361370188.97.0.725505090574.issue16248@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

I suppose this should be closed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:24:30 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:24:30 +0000
Subject: [issue886488] popen2 on Windows does not check _fdopen return value
Message-ID: <1361370270.49.0.773790170767.issue886488@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

I think so.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue886488>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:25:33 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 14:25:33 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361370333.12.0.855443624171.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Whatever the behavior of Python is in 'generic' terms, I believe, we should be able to do locale-dependent uppercasing-lowercasing, which we cannot do at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:29:51 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:29:51 +0000
Subject: [issue1398781] Example in section 5.3 "Pure Embedding" doesn't work.
Message-ID: <1361370591.16.0.914852906308.issue1398781@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Is this still valid?

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1398781>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:40:01 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 Feb 2013 14:40:01 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361371201.02.0.150410931829.issue16248@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The bug hasn't been closed deliberately. We need to announce the security fix and possibly acquire a CVE, too.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:40:37 2013
From: report at bugs.python.org (albertjan)
Date: Wed, 20 Feb 2013 14:40:37 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <5124BFFC.8080505@egenix.com>
Message-ID: <1361371234.25972.YahooMailNeo@web163804.mail.gq1.yahoo.com>


albertjan added the comment:

Hi,
?
I found this report that includes your name:
http://mail.python.org/pipermail/python-bugs-list/2004-August/024564.html
?
Other relevant websites:
http://en.wikipedia.org/wiki/ISO/IEC_8859-11? # is wikipedia 'proof'?
http://code.ohloh.net/file?fid=dhX2dJrRWGISzQAijawMU6qzWJQ&cid=YD58Y-grdtE&s=&browser=Default
http://msdn.microsoft.com/en-us/goglobal/cc305142.aspx
http://www.iso.org/iso/catalogue_detail?csnumber=28263? # non-free

Regards,
Albert-Jan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a 
fresh water system, and public health, what have the Romans ever done for us?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~? 

----- Original Message -----
> From: Marc-Andre Lemburg <report at bugs.python.org>
> To: fomcl at yahoo.com
> Cc: 
> Sent: Wednesday, February 20, 2013 1:22 PM
> Subject: [issue17254] add thai encoding aliases to encodings.aliases
> 
> 
> Marc-Andre Lemburg added the comment:
> 
> On 20.02.2013 12:48, albertjan wrote:
>> 
>> New submission from albertjan:
>> 
>> This is almost identical to: http://bugs.python.org/issue854511
>> However, tis602, which is mentioned in the orginal bug report, is not an 
> alias to cp874. Therefore, I propose the following:
>> 
>> import encodings
>> 
>> aliases = encodings.aliases.aliases
>> more_aliases = {'ibm874'? ? : 'cp874',
>> ? ? ? ? ? ? ? ? 'iso_8859_11': 'cp874',
>> ? ? ? ? ? ? ? ? 'iso8859_11' : 'cp874',
>> ? ? ? ? ? ? ? ? 'windows_874': 'cp874',
>> ? ? ? ? ? ? ? ? }
>> aliases.update(more_aliases)
> 
> Please provide evidence that those encodings are indeed the same.
> 
> Thanks,
> -- 
> Marc-Andre Lemburg
> eGenix.com
> 
> ----------
> nosy: +lemburg
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue17254>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:40:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 14:40:46 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361371246.92.0.214991240943.issue17252@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, earlier in that file is the generic translation:

# Preserve canonical equivalence for I with dot. Turkic is handled below.
0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE

You see that Python is following the standard, here.

Agreed about the locale-aware upper/lower, etc, but that's a feature request.  There's been some discussion about this kind of thing, but I don't remember what the status is.  A search of the python-ideas and/or python-dev mailing lists might yield some clues.  It's a discussion for one of those mailing lists rather than the bug tracker, in any case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:45:31 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:45:31 +0000
Subject: [issue17256] code example should be highlighted
Message-ID: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

in http://docs.python.org/2/extending/embedding.html#linking-requirements
 the code example isn't highlighted

----------
assignee: docs at python
components: Documentation
messages: 182515
nosy: Ramchandra Apte, docs at python
priority: normal
severity: normal
status: open
title: code example should be highlighted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:45:37 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:45:37 +0000
Subject: [issue17256] code example should be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361371537.31.0.282853002389.issue17256@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:47:23 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:47:23 +0000
Subject: [issue17256] code example should be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361371643.35.0.633014222455.issue17256@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Also in the section above: http://docs.python.org/2/extending/embedding.html#extending-embedded-python , the two code examples should be highlighted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:47:40 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:47:40 +0000
Subject: [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361371660.1.0.869850315162.issue17256@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: code example should be highlighted -> code example in C API docsshould be highlighted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:49:34 2013
From: report at bugs.python.org (Firat Ozgul)
Date: Wed, 20 Feb 2013 14:49:34 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361371774.31.0.220743303685.issue17252@psf.upfronthosting.co.za>


Firat Ozgul added the comment:

Apparently, what Python did wrong in the past was somewhat good for Turkish Python developers! This means Turkish developers now have one more problem to solve. Bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:52:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 14:52:14 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361363802.94.0.748913764526.issue17252@psf.upfronthosting.co.za>
Message-ID: <1564066420.50513344.1361371928521.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> "?" is not "i\u0307". That's a different letter. "i\u0307"is 'i with
> combining dot above'. However, "?" is "\u0130" (Latin Capital Letter
> I with Dot Above).

Did you actually read my message? You can reconcile the two using
unicodedata.normalize().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 15:58:18 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Feb 2013 14:58:18 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361372298.36.0.0917942547656.issue17252@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The "locale" module does not affect Unicode operations. That's C locale; I'm talking about concept of Unicode locale, which Python doesn't currently know anything about.

I agree it would be useful to customize the locale of various unicode operations. That's a much broader language-level issue, though, in need of careful design.

As for the useless generic mapping of LATIN CAPITAL LETTER I WITH DOT ABOVE, the idea is there is no LATIN SMALL LETTER I WITH DOT ABOVE so the generic lower casing comes from decomposing the character then lowering the latin one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 16:13:47 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Feb 2013 15:13:47 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361372298.36.0.0917942547656.issue17252@psf.upfronthosting.co.za>
Message-ID: <5124E829.1040403@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.02.2013 15:58, Benjamin Peterson wrote:
> 
> Benjamin Peterson added the comment:
> 
> The "locale" module does not affect Unicode operations. That's C locale; I'm talking about concept of Unicode locale, which Python doesn't currently know anything about.
> 
> I agree it would be useful to customize the locale of various unicode operations. That's a much broader language-level issue, though, in need of careful design.

We'd need to add the CLDR for locale aware operations and a Python
interface for it:

http://cldr.unicode.org/

The Babel project provides such an interface:

http://babel.edgewall.org/

The project appears to have stalled, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 16:21:37 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 Feb 2013 15:21:37 +0000
Subject: [issue17252] Latin Capital Letter I with Dot Above
In-Reply-To: <1361351655.21.0.204016778248.issue17252@psf.upfronthosting.co.za>
Message-ID: <1361373697.28.0.675954508793.issue17252@psf.upfronthosting.co.za>


Christian Heimes added the comment:

In the meantime you can use PyICU https://pypi.python.org/pypi/PyICU for locale aware transformations:

>>> from icu import UnicodeString, Locale
>>> tr = Locale("TR")
>>> s = UnicodeString("KADIN")
>>> print(unicode(s.toLower(tr)))
kad?n
>>> unicode(s.toLower(tr))
u'kad\u0131n'

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17252>
_______________________________________

From report at bugs.python.org  Wed Feb 20 16:25:43 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Feb 2013 15:25:43 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <1361371234.25972.YahooMailNeo@web163804.mail.gq1.yahoo.com>
Message-ID: <5124EAF6.4020201@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.02.2013 15:40, albertjan wrote:
> 
> albertjan added the comment:
> 
> Hi,
>  
> I found this report that includes your name:
> http://mail.python.org/pipermail/python-bugs-list/2004-August/024564.html
>  
> Other relevant websites:
> http://en.wikipedia.org/wiki/ISO/IEC_8859-11  # is wikipedia 'proof'?
> http://code.ohloh.net/file?fid=dhX2dJrRWGISzQAijawMU6qzWJQ&cid=YD58Y-grdtE&s=&browser=Default
> http://msdn.microsoft.com/en-us/goglobal/cc305142.aspx
> http://www.iso.org/iso/catalogue_detail?csnumber=28263  # non-free

Thanks.

Something is wrong with your request, though:

* we already have an iso8859_11 code, so aliasing it to some
  other name is not possible

* we already have an cp874 code, so aliasing it to some
  other name is not possible

* cp874 differs from iso8859_11 in a few places, so aliasing
  cp874 is not possible (see http://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_874)

What we could do is add aliases 'x-ibm874' and 'windows_874' to
'cp874'. I'm not sure whether 'ibm874' and 'x-ibm874' are the same
thing. The references only mention 'x-ibm874'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Wed Feb 20 16:47:36 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 20 Feb 2013 15:47:36 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361375256.15.0.968107229811.issue13772@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've started work on restoring the directory detection in my bitbucket repo (https://bitbucket.org/jaraco/cpython-issue13772). I have added a regression test to capture the basic failure (where the link is not created in the current working directory) as well as a fix. The fix uses the [Microsoft Shell Lightweight Utility Functions](http://msdn.microsoft.com/en-us/library/bb759844%28v=vs.85%29.aspx) which has one benefit of being tested and robust, but has two disadvantages, namely:

- it adds a link-time dependency.
- it doesn't support forward-slashes, which the reference implementation does, and which I believe the CPython implementation should.

Interestingly, it does detect the '/' character as a separator - it just doesn't treat it as one when stripping the trailing path.

Given these disadvantages, I'm inclined to write custom functions to support the directory detection. Any suggestions are appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Wed Feb 20 16:54:23 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Feb 2013 15:54:23 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1361371201.02.0.150410931829.issue16248@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MGe9=bLW82c-aBO_V-ocGVM9k8BOyXDcfwNgMXrHUwzg@mail.gmail.com>


Zachary Ware added the comment:

I believe we're also waiting on input from Barry about whether to apply the
patch to 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 16:57:35 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 15:57:35 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361375855.49.0.429484513055.issue16248@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Does the 2.x patch apply cleanly to 2.6?  If so, then I think it should be applied (though I'd like to review it first).  2.6 is still under security maintenance until October 2013.  I'm thinking we'll probably do one last security release around that time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:02:57 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Feb 2013 16:02:57 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1361375855.49.0.429484513055.issue16248@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MePyg1=CCvPz2CYn_ey4ENWRT66FGmZ35wzn4PSPb6Ug@mail.gmail.com>


Zachary Ware added the comment:

> Does the 2.x patch apply cleanly to 2.6?

It should, if I remember correctly, though I haven't checked since
uploading it. I believe there were actually very few or no changes to the
file the patch is for between 2.6 and 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:11:11 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 16:11:11 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361376671.98.0.229951311018.issue16248@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Release blocking for 2.6.9 (oh how I wish we could release block for specific Python versions).

----------
nosy: +georg.brandl, larry
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:11:29 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 16:11:29 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361376689.05.0.461627168494.issue16248@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:11:59 2013
From: report at bugs.python.org (albertjan)
Date: Wed, 20 Feb 2013 16:11:59 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <5124EAF6.4020201@egenix.com>
Message-ID: <1361376717.69703.YahooMailNeo@web163803.mail.gq1.yahoo.com>


albertjan added the comment:

> Sent: Wednesday, February 20, 2013 4:25 PM
> Subject: [issue17254] add thai encoding aliases to encodings.aliases
> 
> Thanks.
> 
> Something is wrong with your request, though:
> 
> * we already have an iso8859_11 code, so aliasing it to some
> ? other name is not possible
> 
> * we already have an cp874 code, so aliasing it to some
> ? other name is not possible
> 
> * cp874 differs from iso8859_11 in a few places, so aliasing
> ? cp874 is not possible (see 
> http://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_874)

Sorry about that.
?
> What we could do is add aliases 'x-ibm874' and 'windows_874' to
> 'cp874'. I'm not sure whether 'ibm874' and 
> 'x-ibm874' are the same
> thing. The references only mention 'x-ibm874'.

The following document says the following are aliases: x-IBM874, cp874, ibm874, ibm-874, 874
http://www.java2s.com/Tutorial/Java/0180__File/DisplaysAvailableCharsetsandaliases.htm
http://www.fileformat.info/info/charset/x-IBM874/index.htm
In addition it seems that 'windows_874' is used (that's the one that raised this issue for me), but I've also seen references of windows-874, windows874 , WIN874:
http://doxygen.postgresql.org/encnames_8c_source.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:11:59 2013
From: report at bugs.python.org (albertjan)
Date: Wed, 20 Feb 2013 16:11:59 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <5124EAF6.4020201@egenix.com>
Message-ID: <1361376717.69703.YahooMailNeo@web163803.mail.gq1.yahoo.com>


albertjan added the comment:

> Sent: Wednesday, February 20, 2013 4:25 PM
> Subject: [issue17254] add thai encoding aliases to encodings.aliases
> 
> Thanks.
> 
> Something is wrong with your request, though:
> 
> * we already have an iso8859_11 code, so aliasing it to some
> ? other name is not possible
> 
> * we already have an cp874 code, so aliasing it to some
> ? other name is not possible
> 
> * cp874 differs from iso8859_11 in a few places, so aliasing
> ? cp874 is not possible (see 
> http://en.wikipedia.org/wiki/ISO/IEC_8859-11#Code_page_874)

Sorry about that.
?
> What we could do is add aliases 'x-ibm874' and 'windows_874' to
> 'cp874'. I'm not sure whether 'ibm874' and 
> 'x-ibm874' are the same
> thing. The references only mention 'x-ibm874'.

The following document says the following are aliases: x-IBM874, cp874, ibm874, ibm-874, 874
http://www.java2s.com/Tutorial/Java/0180__File/DisplaysAvailableCharsetsandaliases.htm
http://www.fileformat.info/info/charset/x-IBM874/index.htm
In addition it seems that 'windows_874' is used (that's the one that raised this issue for me), but I've also seen references of windows-874, windows874 , WIN874:
http://doxygen.postgresql.org/encnames_8c_source.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:34:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 16:34:51 +0000
Subject: [issue8930] messed up formatting after reindenting
In-Reply-To: <1275862117.51.0.974367285734.issue8930@psf.upfronthosting.co.za>
Message-ID: <1361378091.48.0.910138149994.issue8930@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks like there's no reason for this issue to still be open.  If I'm wrong one of the principles can reopen it ;)

----------
nosy: +r.david.murray
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8930>
_______________________________________

From report at bugs.python.org  Wed Feb 20 17:56:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 16:56:34 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361379394.74.0.318475458727.issue17237@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

mirabilos, if you are motivated enough, do the following. Compile two Python executables - one with deleted assert, and second with deleted a block between "#if SIZEOF_LONG <= SIZEOF_VOID_P" and "#endif". Run  following microbenchmarks for both executables:

./python -m timeit -s "x=b'A'*10000"  "x.decode('ascii')"
./python -m timeit -s "x=b'A'*10000"  "x.decode('utf-8')"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Wed Feb 20 18:09:10 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Feb 2013 17:09:10 +0000
Subject: [issue17241] Python-2.3.5.exe file possibly corrupt
In-Reply-To: <1361299332.57.0.860667306426.issue17241@psf.upfronthosting.co.za>
Message-ID: <1361380150.35.0.0425278999432.issue17241@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution:  -> works for me
stage:  -> committed/rejected
status: pending -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17241>
_______________________________________

From report at bugs.python.org  Wed Feb 20 18:42:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 17:42:31 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1361375855.49.0.429484513055.issue16248@psf.upfronthosting.co.za>
Message-ID: <783363169.50958915.1361382145432.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Barry A. Warsaw added the comment:
> 
> Does the 2.x patch apply cleanly to 2.6?

Perhaps it's your job as a release manager to check that ;-P

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 18:53:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Feb 2013 17:53:44 +0000
Subject: [issue15301] os.chown: OverflowError: Python int too large to convert
	to C long
In-Reply-To: <1341800139.98.0.546402243809.issue15301@psf.upfronthosting.co.za>
Message-ID: <3ZB5yv3sP0zT2F@mail.python.org>


Roundup Robot added the comment:

New changeset 9b37e53838eb by Serhiy Storchaka in branch '2.7':
Issue #15301: Enhance os.*chown() testing.  Based on patch by Larry Hastings.
http://hg.python.org/cpython/rev/9b37e53838eb

New changeset a0baf5347cd1 by Serhiy Storchaka in branch '3.2':
Issue #15301: Enhance os.*chown() testing.  Based on patch by Larry Hastings.
http://hg.python.org/cpython/rev/a0baf5347cd1

New changeset e97b6394848b by Serhiy Storchaka in branch '3.3':
Issue #15301: Enhance os.*chown() testing.  Based on patch by Larry Hastings.
http://hg.python.org/cpython/rev/e97b6394848b

New changeset d4bf997a34e9 by Serhiy Storchaka in branch 'default':
Issue #15301: Enhance os.*chown() testing.  Based on patch by Larry Hastings.
http://hg.python.org/cpython/rev/d4bf997a34e9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15301>
_______________________________________

From report at bugs.python.org  Wed Feb 20 18:53:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Feb 2013 17:53:45 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <3ZB5yw2r8XzT2F@mail.python.org>


Roundup Robot added the comment:

New changeset 0383a54347ea by Serhiy Storchaka in branch '2.7':
Issue #17248: Fix os.*chown() testing when user has group root.
http://hg.python.org/cpython/rev/0383a54347ea

New changeset a49bbaadce67 by Serhiy Storchaka in branch '3.2':
Issue #17248: Fix os.*chown() testing when user has group root.
http://hg.python.org/cpython/rev/a49bbaadce67

New changeset 96b4acb253f8 by Serhiy Storchaka in branch '3.3':
Issue #17248: Fix os.*chown() testing when user has group root.
http://hg.python.org/cpython/rev/96b4acb253f8

New changeset 8c11bbdbac09 by Serhiy Storchaka in branch 'default':
Issue #17248: Fix os.*chown() testing when user has group root.
http://hg.python.org/cpython/rev/8c11bbdbac09

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 18:55:44 2013
From: report at bugs.python.org (Hendrik Lemelson)
Date: Wed, 20 Feb 2013 17:55:44 +0000
Subject: [issue17257] re module shows unexpected non-greedy behavior when
	using groups
Message-ID: <1361382944.02.0.85313570363.issue17257@psf.upfronthosting.co.za>


New submission from Hendrik Lemelson:

When using the Python 2.7.3 re module, it shows a strange behavior upon the use of quantifiers together with groups:

>>> re.search('(a*)', 'caaaat').groups()
('',)
>>> re.search('(a+)', 'caaaat').groups()
('aaaa',)
>>> re.search('(a{0,5})', 'caaaat').groups()
('',)
>>> re.search('(a{1,5})', 'caaaat').groups()
('aaaa',)

Whenever a quantifier is used that allows also zero occurrences, the quantifier loses its greedy behavior. This in my eyes is a defect in the re module. In the following there is another example with nested groups where the quantifier for the outer group even prevents the inner groups to match:

>>> re.search('(a(b*)a)', 'caabbaat').groups()
('aa', '')
>>> re.search('(a(b+)a)', 'caabbaat').groups()
('abba', 'bb')
>>> re.search('(a(b*)a){0,1}', 'caabbaat').groups()
(None, None)
>>> re.search('(a(b+)a){0,1}', 'caabbaat').groups()
(None, None)

It would be great if you could manage to fix this.
Thank you in advance.

Regards
Hendrik Lemelson

----------
components: Regular Expressions
messages: 182535
nosy: Hendrik.Lemelson, ezio.melotti, mrabarnett, pitrou
priority: normal
severity: normal
status: open
title: re module shows unexpected non-greedy behavior when using groups
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17257>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:02:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 18:02:50 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <1361383370.94.0.195957761278.issue17248@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:05:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 18:05:44 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361383544.59.0.724396023511.issue6975@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have no access to Windows and can't design Windows tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:08:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 18:08:45 +0000
Subject: [issue17257] re module shows unexpected non-greedy behavior when
	using groups
In-Reply-To: <1361382944.02.0.85313570363.issue17257@psf.upfronthosting.co.za>
Message-ID: <1361383725.11.0.114959836561.issue17257@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17257>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:24:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 18:24:34 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <1361384674.81.0.776889719502.issue17248@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unfortunately, no it isn't.

root isn't my primary group, it just one of the groups I belong to.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:29:08 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 20 Feb 2013 18:29:08 +0000
Subject: [issue17257] re module shows unexpected non-greedy behavior when
	using groups
In-Reply-To: <1361382944.02.0.85313570363.issue17257@psf.upfronthosting.co.za>
Message-ID: <1361384948.44.0.940813275912.issue17257@psf.upfronthosting.co.za>


Tim Peters added the comment:

This is how it's supposed to work:  Python's re matches at the leftmost position possible, and _then_ matches the longest possible substring at that position.  When a regexp _can_ match 0 characters, it will match starting at index 0.  So, e.g.,

>>> re.search('(a*)', 'caaaat').span()
(0, 0)

shows that the regexp matches the empty slice 'caaaat'[0:0] (the leftmost position at which it _can_ match), and

>>> re.search('(a(b+)a){0,1}', 'caabbaat').span()
(0, 0)

shows the same.  The groups didn't match anything in this case, because the outer {0,1} said "it's OK if you can't match anything".  Put another group around it:

>>> re.search('((a(b+)a){0,1})', 'caabbaat').groups()
('', None, None)

to see that the regexp as a whole did match the empty string.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17257>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:36:20 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 20 Feb 2013 18:36:20 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1253685313.69.0.648289112505.issue6975@psf.upfronthosting.co.za>
Message-ID: <1361385380.92.0.855817960581.issue6975@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Use os.path.sep and os.path.sep.encode() instead of hardcoding "/" and b"/".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:42:06 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 18:42:06 +0000
Subject: [issue17217] Fix test discovery for test_format.py on Windows
In-Reply-To: <1361055748.87.0.775684522637.issue17217@psf.upfronthosting.co.za>
Message-ID: <1361385726.24.0.572734752022.issue17217@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

In order to fix test discovery on Windows the attached patch should be enough.

There are two somewhat unrelated issues though:
1) moving replace_stdout to test.support (and possibly turn it into a context manager/decorator);
2) use unittest verbosity to control the output of test_format instead of test.support.verbose;

Apparently there's no API to access the unittest verbosity level, so that would be a new feature request.

----------
Added file: http://bugs.python.org/file29132/issue17217.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17217>
_______________________________________

From report at bugs.python.org  Wed Feb 20 19:58:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 18:58:57 +0000
Subject: [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1361386737.29.0.171964189675.issue16954@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a few comments on rietveld.

In the rst docs the markup used for arguments is *arg*, and this is sometimes reflected in docstrings too.  We might want to do this here too, instead of using 'arg' (using 'attr' for attributes it's fine though).

> maybe docstrings should be also added in Modules/_elementtree.c?

Maybe we could have a loop that does something like cfunc.__doc__ = pyfunc.__doc__?

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16954>
_______________________________________

From report at bugs.python.org  Wed Feb 20 20:04:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 19:04:22 +0000
Subject: [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1361387062.69.0.0966428397922.issue13124@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Before I take any time to update the patch, does anyone object
> to the location or intent of the changes?

Adding a new page to the devguide seems OK to me.  It makes the devguide bigger, but it can easily be ignored by developers/contributors if they are not interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13124>
_______________________________________

From report at bugs.python.org  Wed Feb 20 20:29:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 20 Feb 2013 19:29:08 +0000
Subject: [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361388548.2.0.62602421872.issue17256@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Looks like it's because highlightlang:: c is at the top.

----------
nosy: +chris.jerdonek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Wed Feb 20 20:29:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 19:29:54 +0000
Subject: [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361388594.04.0.344835691656.issue17256@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Wed Feb 20 20:48:27 2013
From: report at bugs.python.org (mirabilos)
Date: Wed, 20 Feb 2013 19:48:27 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361379394.74.0.318475458727.issue17237@psf.upfronthosting.co.za>
Message-ID: <Pine.BSM.4.64L.1302201941090.26458@herc.mirbsd.org>


mirabilos added the comment:

Serhiy Storchaka dixit:

>mirabilos, if you are motivated enough, do the following. Compile two
>Python executables - one with deleted assert, and second with deleted
>a block between "#if SIZEOF_LONG <= SIZEOF_VOID_P" and "#endif". Run
>following microbenchmarks for both executables:
>
>./python -m timeit -s "x=b'A'*10000"  "x.decode('ascii')"
>./python -m timeit -s "x=b'A'*10000"  "x.decode('utf-8')"
>
>----------
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue17237>
>_______________________________________

Thanks, will actually do that, just not before the weekend,
dayjob?s keeping me busy, and I need to be careful to not
burn out myself in the evening too.

Which tree should I build? A release (if so, which)? Or
some CVS branch?

Do note we clock at roughly 1000 pystones for the fastest
machines? yes 1000 not 10000.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Wed Feb 20 20:50:53 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Feb 2013 19:50:53 +0000
Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361389853.37.0.750180450086.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new version of the patch, with the fixes that Ned pointed out.

I also tried to address concerns about lost information; menu divisions have been added to Doc/library/idle.rst, along with the blurb about running without a subprocess being deprecated.  Also, every instance of :kbd:`C-x` has been expanded to :kbd:`Control-x`, as that's how help.txt has commands written.  A rather unrelated change that I snuck in while I was editing idle.rst was to move the index markers for Class browser and Path browser to be above those entries rather than below.

The generated help.txt is significantly longer than the old version but I don't think that's all bad.  Most of the extra lines are new whitespace or things that had been a single line being broken up into two.  I personally thought the old help.txt was rather too dense in some places, though I might agree that the generated version is a bit sparse in others.

The paragraph about environment variables does have a rather unfortunate number of backticks, but I don't think it's unreadable.  It's also information that wasn't present in the original help.txt.

Thank you for the review, Ned :)

----------
Added file: http://bugs.python.org/file29133/issue16893.v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16893>
_______________________________________

From report at bugs.python.org  Wed Feb 20 20:51:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Feb 2013 19:51:08 +0000
Subject: [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361389868.78.0.255304679532.issue16893@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Removed file: http://bugs.python.org/file28725/issue16893.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16893>
_______________________________________

From report at bugs.python.org  Wed Feb 20 21:11:36 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 20 Feb 2013 20:11:36 +0000
Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5
Message-ID: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

Within multiprocessing.connection, deliver_challenge() and
answer_challenge() use hmac for a challenge/response.

hmac implicitly defaults to using MD5.

MD5 should no longer be used for security purposes.  See e.g. 
http://www.kb.cert.org/vuls/id/836068

This fails in a FIPS-compliant environment (e.g. with the patches I
apply to hashlib in issue 9216).

There's thus a possibility of an attacker defeating the multiprocessing
authenticator.

I'm attaching a patch which changes multiprocessing to use a clearly
identified algorithm (for the day when it needs changing again),
hardcoding it as "sha256"; presumably all processes within a
multiprocess program that share authkey can share the algorithm.

It's not clear to me whether hmac.py should also be changed (this would
seem to have tougher backwards-compat concerns).

[Note to self: I'm tracking this downstream for RHEL as
https://bugzilla.redhat.com/show_bug.cgi?id=879695 (this bug is
currently only visible to RH employees)]

----------
components: Library (Lib)
files: avoid-implicit-usage-of-md5-in-multiprocessing.patch
keywords: patch
messages: 182547
nosy: dmalcolm, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing.connection challenge implicitly uses MD5
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29134/avoid-implicit-usage-of-md5-in-multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________

From report at bugs.python.org  Wed Feb 20 21:17:48 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 20:17:48 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <1361391468.76.0.310630957411.issue17249@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks like a straightforward translation to me.  There's no obvious reason not to move it to being a real test, which means it would sure be nice if we knew why it was left in test_main.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Wed Feb 20 21:33:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 20:33:42 +0000
Subject: [issue6975] symlinks incorrectly resolved on POSIX platforms
In-Reply-To: <1361385380.92.0.855817960581.issue6975@psf.upfronthosting.co.za>
Message-ID: <201302202233.26429.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Use os.path.sep and os.path.sep.encode() instead of hardcoding "/" and
> b"/".

Some separators will be '\\' (if they are derived from OS functions, i.e. 
getcwd), and some will be '/' (if they are generated by posixpath). I do not 
have the ability to research where there are any. Feel free to fix these tests 
for Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6975>
_______________________________________

From report at bugs.python.org  Wed Feb 20 21:43:14 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 Feb 2013 20:43:14 +0000
Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5
In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>
Message-ID: <1361392994.96.0.35916221283.issue17258@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The statement "MD5 should no longer be used for security purposes" is not entirely correct. MD5 should no longer be used as cryptographic hash function for signatures. However HMAC-MD5 is a different story.

>From https://tools.ietf.org/html/rfc6151

   The attacks on HMAC-MD5 do not seem to indicate a practical
   vulnerability when used as a message authentication code.
   [...]
   Therefore, it may not be urgent to remove HMAC-MD5 from the existing
   protocols.  However, since MD5 must not be used for digital
   signatures, for a new protocol design, a ciphersuite with HMAC-MD5
   should not be included.

I agree that we should slowly migrate to a more modern MAC such as HMAC-SHA256. AES-CBC is too hard to get right and most AES implementation are vulnerable to timing attacks, too.

How about we include the name of the MAC in multiprocessing's wire protocol and define "no MAC name given" as HMAC-MD5? Please don't call it SHA256 but HMAC-SHA256, too.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________

From report at bugs.python.org  Wed Feb 20 21:44:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 20:44:12 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <Pine.BSM.4.64L.1302201941090.26458@herc.mirbsd.org>
Message-ID: <201302202243.57488.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> Which tree should I build? A release (if so, which)? Or
> some CVS branch?

It doesn't matter.

> Do note we clock at roughly 1000 pystones for the fastest
> machines? yes 1000 not 10000.

It doesn't matter. Only relative values have a meaning. What is faster and on 
how many percent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Wed Feb 20 21:46:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 20:46:15 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361393175.79.0.968747095698.issue17237@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And of course run the tests on non-debug builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:16:03 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 20 Feb 2013 21:16:03 +0000
Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5
In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>
Message-ID: <1361394963.82.0.312281425588.issue17258@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Banning md5 as a matter of policy may be perfectly sensible.

However, I think the way multiprocessing uses hmac authentication is *not* affected by the collision attacks the advisory talks about.  These depend on the attacker being able to determine for himself whether a particular candidate string is a "solution".

But with the way multiprocessing uses hmac authentication there is no way for the attacker to check for himself whether a candidate string has the desired hash: he does not know what the desired hash value is, or even what the hash function is.  (The effective hash function, though built on top of md5, depends on the secret key.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:21:54 2013
From: report at bugs.python.org (Francis Nimick)
Date: Wed, 20 Feb 2013 21:21:54 +0000
Subject: [issue17259] locale.format() rounding is not reliable for floats
Message-ID: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>


New submission from Francis Nimick:

Locale.format() doesn't work correctly with floating point numbers.

locale.format('%.0f', 5.5) -> 6
locale.format('%.0f', 6.5) -> 6
locale.format('%.0f', 7.5) -> 8
locale.format('%.0f', 8.5) -> 8

It seems that if the number before the decimal point is even, it rounds down, else it rounds up.

----------
components: Library (Lib)
messages: 182554
nosy: Francis.Nimick
priority: normal
severity: normal
status: open
title: locale.format() rounding is not reliable for floats
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:27:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 21:27:32 +0000
Subject: [issue17259] locale.format() rounding is not reliable for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361395652.97.0.509759536476.issue17259@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

http://docs.python.org/library/functions.html#round

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:30:05 2013
From: report at bugs.python.org (Francis Nimick)
Date: Wed, 20 Feb 2013 21:30:05 +0000
Subject: [issue17259] locale.format() rounding is not reliable for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361395805.1.0.151794337972.issue17259@psf.upfronthosting.co.za>


Francis Nimick added the comment:

I did end up using round - does that mean the locale.format() behavior is correct?  It's not specified anywhere in the doc that I can find.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:33:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Feb 2013 21:33:26 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <1361396006.57.0.425445876901.issue17248@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about this patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file29135/test_posix_chown_root_group.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:41:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 21:41:18 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <1361396478.89.0.551162208681.issue17248@psf.upfronthosting.co.za>


R. David Murray added the comment:

That works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:56:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Feb 2013 21:56:15 +0000
Subject: [issue17228] Building without PYMALLOC fails
In-Reply-To: <1361219177.62.0.296828194519.issue17228@psf.upfronthosting.co.za>
Message-ID: <3ZBCLl0WtMz7LlK@mail.python.org>


Roundup Robot added the comment:

New changeset 470350fd2831 by Benjamin Peterson in branch '3.3':
fix building without pymalloc (closes #17228)
http://hg.python.org/cpython/rev/470350fd2831

New changeset 67fa0643751d by Benjamin Peterson in branch '2.7':
fix building without pymalloc (closes #17228)
http://hg.python.org/cpython/rev/67fa0643751d

New changeset ea4a36c667ce by Benjamin Peterson in branch 'default':
merge 3.3 (#17228)
http://hg.python.org/cpython/rev/ea4a36c667ce

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17228>
_______________________________________

From report at bugs.python.org  Wed Feb 20 22:58:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 21:58:01 +0000
Subject: [issue17259] locale.format() rounding is not reliable for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361397481.71.0.837721306994.issue17259@psf.upfronthosting.co.za>


R. David Murray added the comment:

Perhaps Serhiy meant to direct your attention to the "note" in the round docs.  Floating point is tricky.

In Python3 the round is actually "half to even".  I'm not sure what the rounding algorithm is for %f, but I have a suspicion it might be half to even.  I suppose that it ought to be documented.

Note that this applies equally to regular string formatting, it's not something special about the locale module.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, eric.smith, mark.dickinson, r.david.murray
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:00:28 2013
From: report at bugs.python.org (mirabilos)
Date: Wed, 20 Feb 2013 22:00:28 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <201302202243.57488.storchaka@gmail.com>
Message-ID: <Pine.BSM.4.64L.1302202152440.26458@herc.mirbsd.org>


mirabilos added the comment:

Serhiy Storchaka dixit:

>> Which tree should I build? A release (if so, which)? Or
>> some CVS branch?
>
>It doesn't matter.

Erm, still, which one do I build? Not 3.2 because it obviously
works, at least as packaged in Debian.

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
	-- Tonnerre Lombard in #nosec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:10:16 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 22:10:16 +0000
Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5
In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>
Message-ID: <1361398216.9.0.444792495676.issue17258@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:11:43 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 22:11:43 +0000
Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5
In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>
Message-ID: <1361398303.98.0.995974721806.issue17258@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:20:43 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 22:20:43 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>
Message-ID: <1361398843.59.0.607719410558.issue17186@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:26:33 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 22:26:33 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1361399193.66.0.830376287495.issue16037@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:27:27 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 22:27:27 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1361399247.38.0.155474721176.issue16043@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:28:36 2013
From: report at bugs.python.org (Johannes)
Date: Wed, 20 Feb 2013 22:28:36 +0000
Subject: [issue17260] Seg fault when calling unicode() on old style class in
	virtualenv
Message-ID: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>


New submission from Johannes:

Running the code attached causes a segmentation fault.

This only occurs when run from within a virtual environment, and when the class is an old style class.

I've tested on OSX with both 2.7.3 installed via Homebrew, and the default 2.7.2 Python installation.

Also got the same result testing with 2.7.3 on linux ([GCC 4.4.5] on linux2)

I've verified that exactly the same Python installation is being used inside and outside of the virtual env.

Running the same code under 2.5 and 2.6 results in no seg fault.

----------
components: Unicode
files: unicode-bug.py
messages: 182562
nosy: ezio.melotti, johtso
priority: normal
severity: normal
status: open
title: Seg fault when calling unicode() on old style class in virtualenv
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file29136/unicode-bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17260>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:31:07 2013
From: report at bugs.python.org (Johannes)
Date: Wed, 20 Feb 2013 22:31:07 +0000
Subject: [issue17260] Seg fault when calling unicode() on old style object in
	virtualenv
In-Reply-To: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>
Message-ID: <1361399467.0.0.118009424115.issue17260@psf.upfronthosting.co.za>


Changes by Johannes <johtso at gmail.com>:


----------
title: Seg fault when calling unicode() on old style class in virtualenv -> Seg fault when calling unicode() on old style object in virtualenv

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17260>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:40:22 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 20 Feb 2013 22:40:22 +0000
Subject: [issue17259] locale.format() rounding is not reliable for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361400022.46.0.143542687761.issue17259@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Mark is the ultimate authority here, but my recollection is (and a quick scan of the code shows) that half to even rounding is used in all of our float to string conversions. So that includes %f and float.__format__, among others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Wed Feb 20 23:57:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 22:57:06 +0000
Subject: [issue17258] multiprocessing.connection challenge implicitly uses MD5
In-Reply-To: <1361391096.59.0.84157337171.issue17258@psf.upfronthosting.co.za>
Message-ID: <1361401026.85.0.257694553278.issue17258@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17258>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:03:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 23:03:37 +0000
Subject: [issue17260] Seg fault when calling unicode() on old style object in
	virtualenv
In-Reply-To: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>
Message-ID: <1361401417.8.0.581938938391.issue17260@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Can you please post a gdb traceback?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17260>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:09:26 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 23:09:26 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361401766.37.0.981433999422.issue16248@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I'm working on applying the 2.x patch to 2.6, but one thing interesting of note: sudo, at least on Debian and derivatives going back at least to Squeeze, generally reset the environment by default (i.e. env_reset).  So you'd have to either have disabled env_reset in sudoers or use `sudo -E` the exploit.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:17:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 23:17:28 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1361401766.37.0.981433999422.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361402043.3699.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I'm working on applying the 2.x patch to 2.6, but one thing
> interesting of note: sudo, at least on Debian and derivatives going
> back at least to Squeeze, generally reset the environment by default
> (i.e. env_reset).  So you'd have to either have disabled env_reset in
> sudoers or use `sudo -E` the exploit.py.

Or you just have to use something else than Debian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:20:42 2013
From: report at bugs.python.org (Wilson Harron)
Date: Wed, 20 Feb 2013 23:20:42 +0000
Subject: [issue17261] multiprocessing.manager BaseManager cannot return
	proxies from proxies remotely (when listening on '')
Message-ID: <1361402442.38.0.214511208873.issue17261@psf.upfronthosting.co.za>


New submission from Wilson Harron:

If a manager is running listening to all ports ('0.0.0.0') and the manager has a proxy that returns another proxy the client will not be able to create the resulting proxy. 

This is because the server (manager) returns '0.0.0.0' in the token returned, and the therefore the client cannot connect to the proxy.

----------
components: Library (Lib)
files: proxytest.py
messages: 182567
nosy: Wilson.Harron
priority: normal
severity: normal
status: open
title: multiprocessing.manager BaseManager cannot return proxies from proxies remotely (when listening on '')
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29137/proxytest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17261>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:26:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Feb 2013 23:26:03 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <3ZBFLL5xV1zSwl@mail.python.org>


Roundup Robot added the comment:

New changeset 936621d33c38 by Barry Warsaw in branch '2.6':
- Issue #16248: Disable code execution from the user's home directory by
http://hg.python.org/cpython/rev/936621d33c38

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:29:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Feb 2013 23:29:04 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361402944.91.0.636132172915.issue16248@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:29:48 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 20 Feb 2013 23:29:48 +0000
Subject: [issue16248] Security bug in tkinter allows for untrusted,
	arbitrary code execution.
In-Reply-To: <1350401361.69.0.96754494265.issue16248@psf.upfronthosting.co.za>
Message-ID: <1361402988.43.0.20456707641.issue16248@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I think this has now been applied to all of 2.6, 2.7, 3.1, 3.2, 3.3, and 3.4.  So, closing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:34:31 2013
From: report at bugs.python.org (Matthew Porter)
Date: Wed, 20 Feb 2013 23:34:31 +0000
Subject: [issue17262] OrderedDict not ordering properly when int and float
	keys are used
Message-ID: <1361403271.7.0.362355753291.issue17262@psf.upfronthosting.co.za>


New submission from Matthew Porter:

I've got two lists:

state_cns_list = [0.001, 1, 2, 5]
state_names_list = [L, S, D, H]

When I try to create an OrderedDict linking each state_cns_list entry with its corresponding state_names_list entry, like so:

states = OrderedDict( {float(state_cns_list[i]): state_names_list[i] for i in range(0, len(state_cns_list) ) } )

rather than maintaining the original order, (0.001, 'L') is placed at the end of the OrderedDict instead of at the beginning. The attached screenshot shows the bug in action.

Although it's not in the screenshot, when I try placing 4 integers into state_cns_list instead of 3 integers and a float, it has no problem correctly ordering them.

----------
components: Library (Lib)
files: OrderedDictBug.png
messages: 182570
nosy: MrDrMcNinja
priority: normal
severity: normal
status: open
title: OrderedDict not ordering properly when int and float keys are used
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file29138/OrderedDictBug.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17262>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:35:53 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Feb 2013 23:35:53 +0000
Subject: [issue17262] OrderedDict not ordering properly when int and float
	keys are used
In-Reply-To: <1361403271.7.0.362355753291.issue17262@psf.upfronthosting.co.za>
Message-ID: <1361403353.97.0.156258891708.issue17262@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The dictionary you pass to the OrderedDict constructor has already lost the order you initialize it with.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17262>
_______________________________________

From report at bugs.python.org  Thu Feb 21 00:36:30 2013
From: report at bugs.python.org (Matthew Porter)
Date: Wed, 20 Feb 2013 23:36:30 +0000
Subject: [issue17262] OrderedDict not ordering properly when int and float
	keys are used
In-Reply-To: <1361403271.7.0.362355753291.issue17262@psf.upfronthosting.co.za>
Message-ID: <1361403390.34.0.844850246959.issue17262@psf.upfronthosting.co.za>


Matthew Porter added the comment:

Ahh nevermind, just realized my error :P Sorry for the waste of internet space

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17262>
_______________________________________

From report at bugs.python.org  Thu Feb 21 01:18:25 2013
From: report at bugs.python.org (Johannes)
Date: Thu, 21 Feb 2013 00:18:25 +0000
Subject: [issue17260] Seg fault when calling unicode() on old style object in
	virtualenv
In-Reply-To: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>
Message-ID: <1361405905.6.0.927755199602.issue17260@psf.upfronthosting.co.za>


Johannes added the comment:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x000000010004e221 in PyObject_GetAttr ()
(gdb) bt
#0  0x000000010004e221 in PyObject_GetAttr ()
#1  0x000000010004e0ff in PyObject_Unicode ()
#2  0x000000010007ee57 in unicode_new ()
#3  0x0000000100063cbc in type_call ()
#4  0x00000001000108d1 in PyObject_Call ()
#5  0x00000001000a5a1a in PyEval_EvalFrameEx ()
#6  0x00000001000a313f in PyEval_EvalCodeEx ()
#7  0x00000001000a2916 in PyEval_EvalCode ()
#8  0x00000001000c9e2e in PyRun_FileExFlags ()
#9  0x00000001000c980a in PyRun_SimpleFileExFlags ()
#10 0x00000001000ded8a in Py_Main ()
#11 0x0000000100000e4a in ?? ()
#12 0x0000000100000d51 in ?? ()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17260>
_______________________________________

From report at bugs.python.org  Thu Feb 21 02:53:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Feb 2013 01:53:51 +0000
Subject: [issue17260] Seg fault when calling unicode() on old style object in
	virtualenv
In-Reply-To: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>
Message-ID: <1361411631.47.0.345853569796.issue17260@psf.upfronthosting.co.za>


Ned Deily added the comment:

I can reproduce the segfault with a v2.7.3 Python + virtualenv but not with a current 2.7 tip Python + virtualenv.  Nothing comes to mind immediately; I'll try bisecting.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17260>
_______________________________________

From report at bugs.python.org  Thu Feb 21 03:06:59 2013
From: report at bugs.python.org (Kim)
Date: Thu, 21 Feb 2013 02:06:59 +0000
Subject: [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1361412419.94.0.368515263307.issue17155@psf.upfronthosting.co.za>


Kim added the comment:

I'm running into similar issues with 2.6.7 and logging 0.4.9.6, where unicode strings are fine in print statements and codecs writes, but the same string is giving tracebacks for logging.  If it's an education issue, I'm not finding the education I need ... :-/

import logging
import codecs

# Unicode string
i = u'\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044a'

# Print statement is fine
print "hi, i'm the string in question in a print statement: %s" % i

# Codecs write is fine
with codecs.open('/tmp/utf8', 'w', 'utf-8') as f:
    f.write(i)

# Logging gives a Traceback
log = logging.getLogger(__name__)
log.setLevel(logging.DEBUG)
handler = logging.FileHandler('/tmp/out', 'w', 'utf-8')
handler.setFormatter(logging.Formatter(u'[%(levelname)s] %(message)s'))
# I've also tried nixing setFormatter and going with the default
log.addHandler(handler)
log.debug(u"process_clusters: From CSV: %s", i)
# I've also tried a bare call to i, with and without the u in the message, and explicitly i.encode('utf8'); all Tracebacks.

----------
nosy: +kiminoa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17155>
_______________________________________

From report at bugs.python.org  Thu Feb 21 03:33:36 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Feb 2013 02:33:36 +0000
Subject: [issue17260] Seg fault when calling unicode() on old style object in
	virtualenv
In-Reply-To: <1361399316.25.0.654994591669.issue17260@psf.upfronthosting.co.za>
Message-ID: <1361414016.25.0.158239706268.issue17260@psf.upfronthosting.co.za>


Ned Deily added the comment:

Duh! Issue16839 "segmentation fault when unicode(classic_class_instance)"

That was recently fixed and will be available in the upcoming 2.7.4 maintenance release.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> segmentation fault when unicode(classic_class_instance)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17260>
_______________________________________

From report at bugs.python.org  Thu Feb 21 03:37:51 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Thu, 21 Feb 2013 02:37:51 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
Message-ID: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>


New submission from Albert Zeyer:

If you have some Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS in some tp_dealloc and you use such objects in thread local storage, you might get crashes, depending on which thread at what time is trying to cleanup such object.

I haven't fully figured out the details but I have a somewhat reduced testcase. Note that I encountered this in practice because the sqlite connection object does that (while it disconnects, the GIL is released).

This is the C code with some dummy type which has a tp_dealloc which just sleeps for some seconds while the GIL is released: https://github.com/albertz/playground/blob/master/testcrash_python_threadlocal.c

This is the Python code: https://github.com/albertz/playground/blob/master/testcrash_python_threadlocal_py.py

The Python code also contains some code path with a workaround which I'm using currently to avoid such crashes in my application.

----------
components: Interpreter Core
messages: 182577
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: crash when tp_dealloc allows other threads
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Thu Feb 21 03:54:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 02:54:55 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361415295.67.0.0386717190433.issue17225@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Are these values accessible from somewhere (e.g. as attributes of the exception)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 04:49:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Feb 2013 03:49:40 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361418580.26.0.867313212368.issue17263@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/issue17263>
_______________________________________

From report at bugs.python.org  Thu Feb 21 04:52:43 2013
From: report at bugs.python.org (Kim)
Date: Thu, 21 Feb 2013 03:52:43 +0000
Subject: [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1361418763.18.0.851710858488.issue17155@psf.upfronthosting.co.za>


Kim added the comment:

p.s. Converting to a StreamHandler fixes my issue for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17155>
_______________________________________

From report at bugs.python.org  Thu Feb 21 06:31:37 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 05:31:37 +0000
Subject: [issue17264] Update Building C and C++ Extensions with distutils
	documentation
Message-ID: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I have removed all mentions about Python 1.4 and 2.0 from the
Doc/extending/building.rst. The Demo/embed/demo.c file has been removed
in 3.x, so I used "_spammodule.c" convention in the examples. The patch
also fixes all the PEP 8 violations in the setup.py examples.

----------
assignee: docs at python
components: Documentation
files: extending_building.diff
keywords: patch
messages: 182580
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Update Building C and C++ Extensions with distutils documentation
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29139/extending_building.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17264>
_______________________________________

From report at bugs.python.org  Thu Feb 21 07:58:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 06:58:02 +0000
Subject: [issue17262] OrderedDict not ordering properly when int and float
	keys are used
In-Reply-To: <1361403271.7.0.362355753291.issue17262@psf.upfronthosting.co.za>
Message-ID: <1361429882.86.0.603234330531.issue17262@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17262>
_______________________________________

From report at bugs.python.org  Thu Feb 21 09:51:10 2013
From: report at bugs.python.org (Hendrik Lemelson)
Date: Thu, 21 Feb 2013 08:51:10 +0000
Subject: [issue17257] re module shows unexpected non-greedy behavior when
	using groups
In-Reply-To: <1361382944.02.0.85313570363.issue17257@psf.upfronthosting.co.za>
Message-ID: <1361436670.33.0.361686398474.issue17257@psf.upfronthosting.co.za>


Hendrik Lemelson added the comment:

Thank you for clarifying this. While it still not seems really intuitive to me I can handle the behavior.

To summarize: It is not possible with re to have an optional ({0,1}) group that contains further subgroups, because re considers (0,0) to already fulfill the constraints for the outer group?

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17257>
_______________________________________

From report at bugs.python.org  Thu Feb 21 10:04:48 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 09:04:48 +0000
Subject: [issue16181] cookielib.http2time raises ValueError for invalid date.
In-Reply-To: <1349813212.28.0.59101014442.issue16181@psf.upfronthosting.co.za>
Message-ID: <1361437488.87.0.767326021345.issue16181@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Patch attached with a test.

----------
keywords: +patch
nosy: +berker.peksag
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29140/issue16181_v1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16181>
_______________________________________

From report at bugs.python.org  Thu Feb 21 11:19:55 2013
From: report at bugs.python.org (Ferdinand Beyer)
Date: Thu, 21 Feb 2013 10:19:55 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361441995.08.0.163183894378.issue17225@psf.upfronthosting.co.za>


Ferdinand Beyer added the comment:

Line and column number are included in the formatted error message ("raise ValueError(errormsg(...))").  They are currently not accessible separately as exception arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 11:22:53 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 10:22:53 +0000
Subject: [issue17265] Fix code highlight in the string.Template example
Message-ID: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the current version:

http://docs.python.org/3.4/library/string.html#string.Template.template

----------
assignee: docs at python
components: Documentation
files: string_template_highlight.diff
keywords: patch
messages: 182584
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix code highlight in the string.Template example
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29141/string_template_highlight.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17265>
_______________________________________

From report at bugs.python.org  Thu Feb 21 11:34:54 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Thu, 21 Feb 2013 10:34:54 +0000
Subject: [issue17261] multiprocessing.manager BaseManager cannot return
	proxies from proxies remotely (when listening on '')
In-Reply-To: <1361402442.38.0.214511208873.issue17261@psf.upfronthosting.co.za>
Message-ID: <1361442894.76.0.0706689698043.issue17261@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17261>
_______________________________________

From report at bugs.python.org  Thu Feb 21 11:36:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Feb 2013 10:36:10 +0000
Subject: [issue17265] Fix code highlight in the string.Template example
In-Reply-To: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>
Message-ID: <3ZBXCY5XnvzNtY@mail.python.org>


Roundup Robot added the comment:

New changeset 943ea41d3ceb by Ezio Melotti in branch '2.7':
#17265: fix highlight in template example.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/943ea41d3ceb

New changeset 1b9de5788698 by Ezio Melotti in branch '3.2':
#17265: fix highlight in template example.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/1b9de5788698

New changeset 0e2d89f34ae5 by Ezio Melotti in branch '3.3':
#17265: merge with 3.2.
http://hg.python.org/cpython/rev/0e2d89f34ae5

New changeset a11ddd687a0b by Ezio Melotti in branch 'default':
#17265: merge with 3.3.
http://hg.python.org/cpython/rev/a11ddd687a0b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17265>
_______________________________________

From report at bugs.python.org  Thu Feb 21 11:36:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 10:36:54 +0000
Subject: [issue17265] Fix code highlight in the string.Template example
In-Reply-To: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>
Message-ID: <1361443014.6.0.455200014399.issue17265@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17265>
_______________________________________

From report at bugs.python.org  Thu Feb 21 12:11:30 2013
From: report at bugs.python.org (Helmut Jarausch)
Date: Thu, 21 Feb 2013 11:11:30 +0000
Subject: [issue17266] Idle + tcl 8.6.0 Can't convert '_tkinter.Tcl_Obj' object
	to str implicitly
Message-ID: <1361445090.41.0.645711703675.issue17266@psf.upfronthosting.co.za>


New submission from Helmut Jarausch:

I have tcl/tk 8.6.0 installed here. Both Python versions below
are build from source.

I'm using LANG=en_US.iso88591 here if that matters.

When opening a file in Idle with 
python-3.3.1 revision: c08bcf5302ec

or

python-3.4.0a0 (default:3a110a506d35) (HG version)

I get
Failed to load extension 'CodeContext'
Traceback (most recent call last):
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/EditorWindow.py", line 1034, in load_standard_extensions
    self.load_extension(name)
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/EditorWindow.py", line 1055, in load_extension
    ins = cls(self)
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/CodeContext.py", line 49, in __init__
    self.toggle_code_context_event()
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/idlelib/CodeContext.py", line 66, in toggle_code_context_event
    padx += int(str( widget.pack_info()['padx'] ))
  File "/home/jarausch/GenToo/LOC/TEST/Python/cpython/Lib/tkinter/__init__.py", line 1919, in pack_info
    self.tk.call('pack', 'info', self._w))
TypeError: Can't convert '_tkinter.Tcl_Obj' object to str implicitly

----------
components: IDLE
messages: 182587
nosy: HJarausch
priority: normal
severity: normal
status: open
title: Idle + tcl 8.6.0 Can't convert '_tkinter.Tcl_Obj' object to str implicitly
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17266>
_______________________________________

From report at bugs.python.org  Thu Feb 21 12:51:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Feb 2013 11:51:03 +0000
Subject: [issue17266] Idle + tcl 8.6.0 Can't convert '_tkinter.Tcl_Obj' object
	to str implicitly
In-Reply-To: <1361445090.41.0.645711703675.issue17266@psf.upfronthosting.co.za>
Message-ID: <1361447463.64.0.79454899651.issue17266@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python is not ready for Tcl/Tk 8.6 yet.

----------
components: +Tkinter
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17266>
_______________________________________

From report at bugs.python.org  Thu Feb 21 13:05:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Feb 2013 12:05:35 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361448335.29.0.49328308252.issue17225@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These values used only in the exception message. However current (3.0.8, stdlib json based on 2.0.9) simplejson exposes them as an exception attributes.

http://simplejson.readthedocs.org/en/latest/#exceptions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 13:27:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Feb 2013 12:27:31 +0000
Subject: [issue17237] m68k aligns on 16bit boundaries.
In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za>
Message-ID: <1361449651.18.0.531128774858.issue17237@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Erm, still, which one do I build? Not 3.2 because it obviously
> works, at least as packaged in Debian.

Any >= 3.3.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17237>
_______________________________________

From report at bugs.python.org  Thu Feb 21 13:38:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Feb 2013 12:38:02 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <3ZBZwB1krxz7Lmx@mail.python.org>


Roundup Robot added the comment:

New changeset 7a9ea3d08f51 by Serhiy Storchaka in branch '2.7':
Issue #17248: Fix os.*chown() testing when user is in root group.
http://hg.python.org/cpython/rev/7a9ea3d08f51

New changeset 0f7383e6ced7 by Serhiy Storchaka in branch '3.2':
Issue #17248: Fix os.*chown() testing when user is in root group.
http://hg.python.org/cpython/rev/0f7383e6ced7

New changeset a4e348c4b5d3 by Serhiy Storchaka in branch '3.3':
Issue #17248: Fix os.*chown() testing when user is in root group.
http://hg.python.org/cpython/rev/a4e348c4b5d3

New changeset d49685548a7a by Serhiy Storchaka in branch 'default':
Issue #17248: Fix os.*chown() testing when user is in root group.
http://hg.python.org/cpython/rev/d49685548a7a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 13:45:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Feb 2013 12:45:49 +0000
Subject: [issue17248] test_posix chown -1, 0 tests fail if user has group root
In-Reply-To: <1361323391.07.0.678749400911.issue17248@psf.upfronthosting.co.za>
Message-ID: <1361450749.89.0.184386223496.issue17248@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17248>
_______________________________________

From report at bugs.python.org  Thu Feb 21 13:47:59 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 21 Feb 2013 12:47:59 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
Message-ID: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

It would be nice if datetime.time would be possible to add a delta to a datetime.time object, and if datetime.time had a method for returning the current time (just like datetime.date and date time.datetime have 'today' and 'now' methods).

Rationale for the '+' operator: calculating the wall clock time some time after an time on an unspecified date. The easy solution would be:

   tm = datetime.time(13, 20)
   later = tm + datetime.timedelta(hours=5, minutes=44)

That's is currently not possible, but requires more complicated code.

Getting the current time without date information currently requires getting done with 'datetime.datetime.now().time()', a class method of 'datetime.time' would IMHO be nicer. I must admit that I don't have a good suggestion for the name of that method.

----------
components: Library (Lib)
messages: 182592
nosy: ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: datetime.time support for '+' and 'now'
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Thu Feb 21 14:16:35 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 21 Feb 2013 13:16:35 +0000
Subject: [issue16233] IDLE: conceptual problems with *Class browser*
In-Reply-To: <1350229949.19.0.565182759034.issue16233@psf.upfronthosting.co.za>
Message-ID: <1361452595.73.0.105151601159.issue16233@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

IMO, Class Browser shouldn't even appear in PyShell.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16233>
_______________________________________

From report at bugs.python.org  Thu Feb 21 15:00:49 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 21 Feb 2013 14:00:49 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361455249.29.0.662049308448.issue17267@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

What would this give:

   tm = datetime.time(13, 20)
   later = tm + datetime.timedelta(hours=47, minutes=44)

datetime.time(13, 4)? Or raise an exception?

I've thought about this before, but it's always a problem when going over date boundaries. If you define "+" to be modulo 24 hours, then it's not very useful for cases I've looked at. Every time I've used time by itself, I end up going back to datetime. But I'll admit that might be a shortcoming of mine, not the concept.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Thu Feb 21 15:31:56 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 21 Feb 2013 14:31:56 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361457116.42.0.286818689997.issue17267@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

IMHO this would to module 24 arithmetic, just like a normal clock.

When I do calculations with plain time that is what I want, if the date is also important I use datetime.datetime.  That a time value silently truncates when going past midnight is IMHO also the obvious behavior.

The biggest argument against adding this functionality I could come up with is that this can give wrong answers when daylight savings time transitions happen, which could lead to subtle bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Thu Feb 21 16:58:31 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 21 Feb 2013 15:58:31 +0000
Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace
In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za>
Message-ID: <1361462311.76.0.160285874879.issue16446@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16446>
_______________________________________

From report at bugs.python.org  Thu Feb 21 16:59:35 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 21 Feb 2013 15:59:35 +0000
Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace
In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za>
Message-ID: <1361462375.67.0.698537092026.issue16446@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I also bumped into this problem on both 2.7 and 3.3. It is very annoying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16446>
_______________________________________

From report at bugs.python.org  Thu Feb 21 17:16:06 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Feb 2013 16:16:06 +0000
Subject: [issue17264] Update Building C and C++ Extensions with distutils
	documentation
In-Reply-To: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>
Message-ID: <1361463366.01.0.833111108318.issue17264@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks, will tweak and apply.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17264>
_______________________________________

From report at bugs.python.org  Thu Feb 21 17:31:51 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 16:31:51 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
Message-ID: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

We have implemented the context manager API for connections and cursors in our mxODBC module and this works fine in Python 2.6.

In Python 2.7 we get the following error:

Traceback (most recent call last):
  File "context-manager.py", line 6, in <module>
    with db.cursor() as cursor:
AttributeError: __exit__

Here's the code snippet:

import mx.ODBC.unixODBC as ODBC
connectionString = '...'
db = ODBC.DriverConnect(connectionString)
with db.cursor() as cursor:
    print cursor

The mxODBC cursor is not an instance, it's implemented as Python type in C. It implements the tp_getattr slot, but not the tp_desc_get slot.

Looking at the apparently new API _PyObject_LookupSpecial(), this does not appear to support the tp_getattr slot and goes straight for the tp_desc_get slot.

----------
messages: 182598
nosy: lemburg
priority: normal
severity: normal
status: open
title: Context managers written as C types no longer work in Python 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 17:36:38 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 16:36:38 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361464598.2.0.488657628625.issue17268@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

After some experiments, it turned out that by simply filling in the tp_methods slot, the problem went away.

Still, the change to use _PyObject_LookupSpecial() appears to have missed the (older) use case where you don't define tp_members, but instead implement method lookup as part of the tp_getattr slot.

Not sure whether this is worth fixing. I just filed this report so that others running into the same problem can find it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 17:40:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 21 Feb 2013 16:40:30 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361464830.28.0.711887161749.issue17268@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The change should also be documented here, http://docs.python.org/2.7/whatsnew/2.7.html#porting-to-python-2-7

----------
assignee:  -> docs at python
components: +Documentation
nosy: +christian.heimes, docs at python
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 18:37:19 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 17:37:19 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464598.2.0.488657628625.issue17268@psf.upfronthosting.co.za>
Message-ID: <51265B4C.2040502@egenix.com>


Marc-Andre Lemburg added the comment:

On 21.02.2013 17:36, Marc-Andre Lemburg wrote:
> 
> After some experiments, it turned out that by simply filling in the tp_methods slot, the problem went away.

Sorry: *tp_methods*, not tp_members.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 18:48:22 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 17:48:22 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361468902.37.0.0333686612593.issue17268@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
Removed message: http://bugs.python.org/msg182601

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 18:49:04 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 17:49:04 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464598.2.0.488657628625.issue17268@psf.upfronthosting.co.za>
Message-ID: <51265E0D.1050005@egenix.com>


Marc-Andre Lemburg added the comment:

On 21.02.2013 17:36, Marc-Andre Lemburg wrote:
> After some experiments, it turned out that by simply filling in the tp_methods slot, the problem went away.
> 
> Still, the change to use _PyObject_LookupSpecial() appears to have missed the (older) use case where you don't define tp_members, but instead implement method lookup as part of the tp_getattr slot.

Sorry: *tp_methods*, not tp_members.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 18:50:59 2013
From: report at bugs.python.org (Bob Ippolito)
Date: Thu, 21 Feb 2013 17:50:59 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361469059.1.0.803335448308.issue17225@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

I've applied a very similar patch to simplejson and released 3.0.9 

https://github.com/simplejson/simplejson/commit/44d7709a31f3a19f3d465411585ebb7be7fa2295

----------
nosy: +bob.ippolito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 18:52:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Feb 2013 17:52:30 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361469150.65.0.676649159813.issue17225@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

https://github.com/simplejson/simplejson/issues/57

Simplejson has fixed this for about 6 hours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 19:31:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Feb 2013 18:31:11 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <3ZBklf3l0lzSq0@mail.python.org>


Roundup Robot added the comment:

New changeset ce583eb0bec2 by Serhiy Storchaka in branch '2.7':
Issue #17225: JSON decoder now counts columns in the first line starting
http://hg.python.org/cpython/rev/ce583eb0bec2

New changeset 36220cf535aa by Serhiy Storchaka in branch '3.2':
Issue #17225: JSON decoder now counts columns in the first line starting
http://hg.python.org/cpython/rev/36220cf535aa

New changeset 361ba6d4b7c9 by Serhiy Storchaka in branch '3.3':
Issue #17225: JSON decoder now counts columns in the first line starting
http://hg.python.org/cpython/rev/361ba6d4b7c9

New changeset 69f793cc34fc by Serhiy Storchaka in branch 'default':
Issue #17225: JSON decoder now counts columns in the first line starting
http://hg.python.org/cpython/rev/69f793cc34fc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 19:56:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Feb 2013 18:56:10 +0000
Subject: [issue17225] JSON decoder reports wrong column number on first line
In-Reply-To: <1361193566.84.0.658685915007.issue17225@psf.upfronthosting.co.za>
Message-ID: <1361472970.09.0.776788710169.issue17225@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the report, Ferdinand.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17225>
_______________________________________

From report at bugs.python.org  Thu Feb 21 21:11:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Feb 2013 20:11:53 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361477513.35.0.645831980848.issue17268@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 21:34:34 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 21 Feb 2013 20:34:34 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1361478874.77.0.984298630811.issue17170@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Let me throw in a quick reminder that Cython has substantially faster argument parsing than the C-API functions provide because it translates function signatures like

    def func(int a, b=1, *, list c, d=2):
        ...

into tightly specialised unpacking code, while keeping it as compatible as possible with the equivalent Python function (better than manually implemented C functions, BTW). Might be an alternative to the Argument Clinic, one that has been working for a couple of years now and has already proven its applicability to a large body of real world code.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Thu Feb 21 21:44:06 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2013 20:44:06 +0000
Subject: [issue17268] Context managers written as C types no longer work in
	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361479446.25.0.442848178817.issue17268@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is a property of all special methods not just __enter__ and __exit__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17268>
_______________________________________

From report at bugs.python.org  Thu Feb 21 22:17:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Feb 2013 21:17:48 +0000
Subject: [issue17255] test_any and test_all should validate short-circuiting
	behaviour
In-Reply-To: <1361363523.21.0.389382040162.issue17255@psf.upfronthosting.co.za>
Message-ID: <3ZBpRv5MT6zSy8@mail.python.org>


Roundup Robot added the comment:

New changeset 124237eb5de9 by Ezio Melotti in branch '2.7':
#17255: test short-circuiting behavior of any()/all().  Patch by Wim Glenn.
http://hg.python.org/cpython/rev/124237eb5de9

New changeset 34b7240d678b by Ezio Melotti in branch '3.2':
#17255: test short-circuiting behavior of any()/all().  Patch by Wim Glenn.
http://hg.python.org/cpython/rev/34b7240d678b

New changeset 576d2c885eb6 by Ezio Melotti in branch '3.3':
#17255: merge with 3.2.
http://hg.python.org/cpython/rev/576d2c885eb6

New changeset c65fcedc511c by Ezio Melotti in branch 'default':
#17255: merge with 3.3.
http://hg.python.org/cpython/rev/c65fcedc511c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17255>
_______________________________________

From report at bugs.python.org  Thu Feb 21 22:18:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 21:18:28 +0000
Subject: [issue17255] test_any and test_all should validate short-circuiting
	behaviour
In-Reply-To: <1361363523.21.0.389382040162.issue17255@psf.upfronthosting.co.za>
Message-ID: <1361481508.64.0.369885893401.issue17255@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.1, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17255>
_______________________________________

From report at bugs.python.org  Thu Feb 21 22:58:58 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Feb 2013 21:58:58 +0000
Subject: [issue16233] IDLE: conceptual problems with *Class browser*
In-Reply-To: <1350229949.19.0.565182759034.issue16233@psf.upfronthosting.co.za>
Message-ID: <1361483938.44.0.335946822101.issue16233@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Conceptual problems indeed. I never tried the 'class browser' because I mostly write modules with functions, not classes. Nonetheless, to see what this issue is about, I just tried it with one of my function-only files, expecting to see an empty 'show', whatever that would be. Instead I see new window with a nice listing of all the function definitions in the file.

& xxx.py
|- & def a(...)
|- & def b(...)
(& is a green Python snake)

But why must the file be open? Left click, right click, left double click, and the answer appears. The cursor in the open edit window moves to the corresponding def line, which is highlighted. So this is not just a class browser, but a module file navigator. This is a real gem that I should have been using, and would have if it were properly labeled and documented. I think the help/manual entry should be something like

Module Browser -- Summarize the function, class, and method statements in a opened module file with a tree structure in an auxiliary window. Double clicking on any line in the tree activates the corresponding edit window, moves its cursor to the beginning of the corresponding def or class statement, and highlights the first line of that statement.

(I did check that lambda expressions are ignored.)

Since this feature can almost never be useful in PyShell, I agree that 'Module Browser' (or whatever new name we choose) should best not be present, or grayed out, or always fail with a shell specific message. But it seems that while shell and edit windows each have some main menu entries that the other does not, the submenus present in each are the same, so this might not be trivial (or the context specific message might be the easiest change).

I think we can further improve the error message. I think 'this edit window' would be clearer that 'this buffer'. I think it should also specify that it only works with python module file. If someone who is editing a new non-Python file follows the instruction to save and try again, they will only be frustrated.

I have two complaints about the browser window itself. The first is that the line spacing is not adjusted for my larger than default font (which I need for my less than 'default' vision). Consequently, each line cuts off the bottoem of the chars in the line above. This is a bug.

The other is that the green snake at the beginning of *every* line is just distracting visual noise. The one before xxx.py is enough.

I think all the mentioned changes can go in all current versions.

----------
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16233>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:20:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Feb 2013 22:20:27 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1361478874.77.0.984298630811.issue17170@psf.upfronthosting.co.za>
Message-ID: <51269D7D.2090809@udel.edu>


Terry J. Reedy added the comment:

(Stefan) > into tightly specialised unpacking code,

Are you suggesting that func.__call__ should be specialized to func's 
signature, more than it is now (which is perhaps not at all), or 
something else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:21:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:21:55 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361485315.91.0.971203312466.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
hgrepos:  -170

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:22:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:22:13 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361485333.27.0.481485596761.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file28629/committing.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:22:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:22:15 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361485335.98.0.516293744949.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file28628/issue14468-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:22:17 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:22:17 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361485337.7.0.020168468109.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file28540/issue14468.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:32:25 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 21 Feb 2013 22:32:25 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1361485945.92.0.549013500066.issue17170@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Cython does that in general, sure. However, this ticket is about a specific case where string methods (which are implemented in C) are slow when called from Python. Antoine found out that the main overhead is not so much from the method lookup itself but from argument parsing inside of the function. The unpacking code that Cython generates for the equivalent Python signature would speed this up, while keeping or improving the compatibility with Python call semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:34:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:34:29 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486069.66.0.717091872745.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29142/1-add_clones_setup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:35:33 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:35:33 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486133.31.0.62943096377.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29143/2-move_two_sections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:36:17 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:36:17 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486177.69.0.0333523952832.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29144/3-update_active_branches_and_mergin_order.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:36:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:36:44 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486204.54.0.496471134267.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29145/4-update_merge_within_same_version.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:37:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:37:04 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486224.57.0.651804890372.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29146/5-update_merge_between_major_versions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:37:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:37:35 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486255.85.0.412969999228.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29147/6-remove_outdated_sections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:38:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:38:05 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486285.15.0.296175144144.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29148/7-move_faq_in_two_subsections.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:38:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:38:54 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486334.0.0.0151152444831.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29149/8-update_faqs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:45:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:45:10 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486710.42.0.957369412779.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29150/1-6-committing.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:45:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:45:35 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361486735.29.0.303020407002.issue14468@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file29151/7-8-faqs.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 21 23:51:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 22:51:11 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361487071.03.0.675087525596.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I extracted the diffs and attached them to the issue.
The first 6 patches update committing.rst:
[1]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/c2fca99bdb7212c4815d9fe6b0c869bb4358886a
[2]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/37e287725636bb9c4b82ae864e38a97e8b332809
[3]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/55055f30dd933c3f05be1581fd7c6cf2ec97c09c
[4]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/389488fc431dca256b3534ca658a4e4f
[5]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/8dc7283e53de97692a76b9f363a80303
[6]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/3c5c77f2fa75d3c8bcb459d0c6060354

The last two patches update faqs.rst:
[7]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/7a6f9b28a9d14e1e40988c76712a78a6a6014d28
[8]: https://bitbucket.org/ezio_melotti/devguide-14468/commits/5bf313aec51c326673a63206f0d7d0c7b40d6e86

I also updated two patches that includes the changes of patches 1-6 and 7-8.
I'm planning to commit these two last patches, but I can also make 8 separate commits or even a single one.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 00:31:53 2013
From: report at bugs.python.org (Johan Tibell)
Date: Thu, 21 Feb 2013 23:31:53 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
Message-ID: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>


New submission from Johan Tibell:

The following call to getaddrinfo makes Python segfault:

$ python
Python 2.7.2 (default, Jun 20 2012, 16:23:33) 
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getaddrinfo("localhost", None, 0, 0, 0, socket.AI_NUMERICSERV)
Segmentation fault: 11

The combination of no port (None) and socket.AI_NUMERICSERV makes no sense (I used it by mistake) but we probably don't want to segfault anyway.

----------
components: Library (Lib)
messages: 182615
nosy: tibbe
priority: normal
severity: normal
status: open
title: getaddrinfo segfaults on OS X when provided with invalid arguments combinations
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 00:32:33 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Feb 2013 23:32:33 +0000
Subject: [issue17209] get_wch() doesn't handle KeyboardInterrupt
In-Reply-To: <1360931664.77.0.750623076852.issue17209@psf.upfronthosting.co.za>
Message-ID: <1361489553.46.0.871415030795.issue17209@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Attached patch should fix this issue.

----------
keywords: +patch
versions: +Python 3.4
Added file: http://bugs.python.org/file29152/curses_get_wch_sigint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17209>
_______________________________________

From report at bugs.python.org  Fri Feb 22 00:35:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Feb 2013 23:35:57 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361489757.96.0.30391584777.issue17269@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Linux manual page: "If  AI_NUMERICSERV  is  specified  in hints.ai_flags and service is not NULL, then service must point to a string containing a numeric port number."

So it looks like None is accepted on Linux. I checked: the example doesn't crash.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 00:36:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Feb 2013 23:36:09 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361489769.28.0.644975512413.issue17269@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 01:49:22 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 00:49:22 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361494162.87.0.294035293007.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for waiting and for posting the patches here.  I think the second patch "2-move_two_sections.diff" should be committed now, along with making "Working with Mercurial" a higher-level header (as it is done in the aggregate patch).  This will separate the Mercurial-specific info from the non-Mercurial info in committing.rst, which is a good change in any case.

I will try to voice my high-level comments on the rest of the patches by this weekend, and/or suggest a second incremental change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 02:00:07 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Feb 2013 01:00:07 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361494807.51.0.919873659713.issue17269@psf.upfronthosting.co.za>


Ned Deily added the comment:

The crash occurs in OS X's libsystem_info on 10.8.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_info.dylib          	0x00007fff86bacd9e mdns_addrinfo + 299
1   libsystem_info.dylib          	0x00007fff86badae2 search_addrinfo + 152
2   libsystem_info.dylib          	0x00007fff86b97f6d si_addrinfo + 1641
3   libsystem_info.dylib          	0x00007fff86b9785c getaddrinfo + 171
4   _socket.so                    	0x0000000100516524 socket_getaddrinfo + 500

It's also reproducible back on OS X 10.6 crashing there in libSystem. (It looks like earlier versions of OS X don't support the AI_NUMERICSERV flag.)  So it would appear to be a long-standing OS X bug.  Possible actions: open an Apple incident and patch socket.getaddrinfo to catch this case.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 03:18:03 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 02:18:03 +0000
Subject: [issue17270] make the section header doc convention more clearly
	optional
Message-ID: <1361499483.55.0.95674710032.issue17270@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation guidelines in the devguide list a convention for section headers:

http://docs.python.org/devguide/documenting.html#sections

The current wording, however, can be interpreted to mean that this convention is always (and should always) be used.  However, the reality is weaker.  For example, see:

http://bugs.python.org/issue17109#msg181302

This issue is to update the wording so the convention is more clearly a suggestion rather than a requirement.

----------
components: Devguide
files: devguide-section-headers.diff
keywords: easy, patch
messages: 182620
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: make the section header doc convention more clearly optional
type: enhancement
Added file: http://bugs.python.org/file29153/devguide-section-headers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17270>
_______________________________________

From report at bugs.python.org  Fri Feb 22 03:19:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 02:19:11 +0000
Subject: [issue17270] make the section header doc convention more clearly
	optional
In-Reply-To: <1361499483.55.0.95674710032.issue17270@psf.upfronthosting.co.za>
Message-ID: <1361499551.27.0.00911227502326.issue17270@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17270>
_______________________________________

From report at bugs.python.org  Fri Feb 22 03:20:37 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 02:20:37 +0000
Subject: [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1361499637.75.0.754883308332.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> It can just be changed to being a suggestion as opposed to "the convention that we use."

I created issue 17270 for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17109>
_______________________________________

From report at bugs.python.org  Fri Feb 22 03:25:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 02:25:27 +0000
Subject: [issue17270] make the section header doc convention more clearly
	optional
In-Reply-To: <1361499483.55.0.95674710032.issue17270@psf.upfronthosting.co.za>
Message-ID: <3ZBxGt2sZKzNlv@mail.python.org>


Roundup Robot added the comment:

New changeset fa06f733e2fe by Chris Jerdonek in branch 'default':
Issue #17270: clarify that the section header doc convention is optional.
http://hg.python.org/devguide/rev/fa06f733e2fe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17270>
_______________________________________

From report at bugs.python.org  Fri Feb 22 03:27:01 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 02:27:01 +0000
Subject: [issue17270] make the section header doc convention more clearly
	optional
In-Reply-To: <1361499483.55.0.95674710032.issue17270@psf.upfronthosting.co.za>
Message-ID: <1361500021.21.0.466327854833.issue17270@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17270>
_______________________________________

From report at bugs.python.org  Fri Feb 22 04:04:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 03:04:53 +0000
Subject: [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <3ZBy8N49zCzSrl@mail.python.org>


Roundup Robot added the comment:

New changeset f4ccc5aab287 by Chris Jerdonek in branch '2.7':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/f4ccc5aab287

New changeset c0581f7be196 by Chris Jerdonek in branch '3.2':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/c0581f7be196

New changeset 7d1122c79985 by Chris Jerdonek in branch '3.3':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/7d1122c79985

New changeset bbe5efa9c667 by Chris Jerdonek in branch 'default':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/bbe5efa9c667

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17203>
_______________________________________

From report at bugs.python.org  Fri Feb 22 04:05:47 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 03:05:47 +0000
Subject: [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <1361502347.96.0.719901769333.issue17203@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17203>
_______________________________________

From report at bugs.python.org  Fri Feb 22 04:26:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 03:26:12 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361503572.44.0.301711892839.issue14468@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking at patch 1. On Windows, ~/.hgrc is $HOME$/mercurial.ini.
On my win7 machine, that translates to C:/Users/Terry/mercurial.ini.
I think it would be different on xp. But with TortoiseHG/Workbench, one should better use the Settings dialogs than edit directly.

I have [extensions]\nshare = set in that file but I don't think that is actually used as I created the clones with hg update rather than hg share. I will see what I have to do when I recreate the clones with hg share instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 04:32:22 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 03:32:22 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1361503942.41.0.123788388903.issue16123@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Fri Feb 22 04:46:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 03:46:48 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1361504808.06.0.912762802933.issue17183@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I did some macro-benchmarks and the proposed changes don't seem to affect the result (most likely because they are in _parse_doctype_element and _parse_doctype_attlist which should be called only once per document).

I did some profiling, and this is the result:
         4437196 function calls (4436748 primitive calls) in 36.582 seconds

   Ordered by: internal time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
    92931    7.400    0.000   17.082    0.000 parser.py:320(parse_starttag)
      202    6.363    0.032   36.281    0.180 parser.py:171(goahead)
   673285    5.302    0.000    5.302    0.000 {method 'match' of '_sre.SRE_Pattern' objects}
   369418    3.272    0.000    4.554    0.000 _markupbase.py:48(updatepos)
    83243    2.698    0.000    4.639    0.000 parser.py:421(parse_endtag)
   308882    2.006    0.000    2.006    0.000 {method 'group' of '_sre.SRE_Match' objects}
   270074    1.521    0.000    1.521    0.000 {method 'search' of '_sre.SRE_Pattern' objects}
    92931    1.150    0.000    2.643    0.000 parser.py:378(check_for_whole_start_tag)
   291079    1.028    0.000    1.028    0.000 {method 'count' of 'str' objects}
   295892    0.883    0.000    0.883    0.000 {method 'startswith' of 'str' objects}
   387439    0.733    0.000    0.733    0.000 {method 'lower' of 'str' objects}
   403922    0.642    0.000    0.642    0.000 {method 'end' of '_sre.SRE_Match' objects}
   124512    0.406    0.000    1.156    0.000 parser.py:504(unescape)
   186775    0.326    0.000    0.326    0.000 {method 'start' of '_sre.SRE_Match' objects}
    96213    0.255    0.000    0.255    0.000 {method 'endswith' of 'str' objects}
    59522    0.253    0.000    0.253    0.000 {method 'rindex' of 'str' objects}
    83226    0.215    0.000    0.215    0.000 parser.py:164(clear_cdata_mode)
     6428    0.194    0.000    0.337    0.000 parser.py:507(replaceEntities)
   106487    0.183    0.000    0.183    0.000 parser.py:484(handle_data)

Excluding string and regex methods, the 3 slowest methods are parse_starttag, goahead, and updatepos.
The attached patch adds a couple of simple optimizations to the first two -- I couldn't think a way to optimize updatepos.
The resulting speedup is however fairly small, so I'm not sure it's worth applying the patch.
I might try doing other benchmarks in future (should I add them somewhere in Tools?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Fri Feb 22 04:50:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 03:50:46 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361505046.27.0.978129368812.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I could mention mercurial.ini too, but I don't think the devguide should cover tortoisehg.  All the commands should work fine on Windows too.

> I don't think that is actually used as I created the clones with
> hg update rather than hg share.

Do you you mean s/update/clone/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 05:17:35 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 04:17:35 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361506655.11.0.0129750242103.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

For reasons I stated above, I think it will help to break this issue into smaller, self-contained parts as we go -- even if some of the issues turn out to be short-lived.

For example, an issue can be created for adding to the docs a section on how to set up multiple clones.  This way, we can separate the discussion and treatment of telling people how to use multiple clones from telling people how to set them up.  I think it will be simpler to address and commit the latter first.  The current "1-add_clones_setup.diff" patch mixes things by including info on applying, committing, and merging a patch under the section on setting things up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 05:30:05 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Feb 2013 04:30:05 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1361507405.02.0.338054822476.issue16123@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I help a lot of people with IDLE problems and sometimes the -n option is the only thing that saves them.  ISTM that removing it is not such as a good idea.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Fri Feb 22 05:47:22 2013
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 22 Feb 2013 04:47:22 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1361508442.48.0.190626195136.issue16123@psf.upfronthosting.co.za>


Roger Serwy added the comment:

@Raymond: What is so broken about IDLE that requires using "-n" to fix it? Let's try to fix those problems rather than keeping up the maintenance burden of supporting two execution modes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:28:27 2013
From: report at bugs.python.org (Kushal Das)
Date: Fri, 22 Feb 2013 05:28:27 +0000
Subject: [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361510907.21.0.105229629206.issue17256@psf.upfronthosting.co.za>


Kushal Das added the comment:

Following patch solves the problem.

----------
keywords: +patch
nosy: +kushaldas
Added file: http://bugs.python.org/file29154/issue17256.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:29:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 05:29:27 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361510967.78.0.728610683695.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The current "1-add_clones_setup.diff" patch mixes things by including 
> info on applying, committing, and merging a patch under the section on 
> setting things up.

The goal of that section is to provide an overview of all the steps that a committer has to follow, starting from the beginning (getting a clone) till the end (the patch is applied on all the branches and pushed).
The "Clones setup" section is not about "how to set up a clone", but "how do I do these steps depending on the specific setup I'm using" (single or multiple clones).


> For example, an issue can be created for adding to the docs a section on how to set up multiple clones. 

This is not the goal of this issue.
How to create one/multiple clones is already covered in:
 1) http://docs.python.org/devguide/#quick-start (single clone)
 2) http://docs.python.org/devguide/setup.html#checkout (single clone)
 3) http://docs.python.org/devguide/committing.html#using-several-working-copies (multiple clones without share)
 4) http://docs.python.org/devguide/faq.html#i-want-to-keep-a-separate-working-copy-per-development-branch-is-it-possible (multiple clones without share)
 5) http://docs.python.org/devguide/faq.html#how-do-i-avoid-repeated-pulls-and-pushes-between-my-local-repositories (just a link to the share extension)


After all the patches are applied:
 * the quick start and the setup page will still explain the single-clone approach (intended for contributors, but valid also for developers);
 * the committing.rst page will only explain the multiple shared clones approach (for developers) and just link to 2) for the single-clone approach;
 * the faq will still explain the multiple non-shared clones approach in 4) as an alternative, but also suggest the shared version and link to committing.rst;

The reason why (almost) all the patches should be applied together is that once the multiple shared clones approach is explained as the default approach (patch 1), the instructions about the different branches (patch 3), merging between the same major version (patch 4) and between major versions (patch 5) must be updated.  At the same time, the section about using multiple unshared clones is no longer necessary so it has to be removed (patch 6).  Finally there's no reason to mention the share extension in the faq (patch 8).

Patch 2 could indeed committed separately, and patch 7 reflects the separation between single-clone/contributors and multiple-clones/developers by dividing the FAQs in two groups.

After this is done I was planning to update the "developers" FAQs, but this issue is currently blocking that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:30:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 05:30:53 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361511053.51.0.635494766926.issue14468@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> Do you you mean s/update/clone/? duh, yes
> I don't think the devguide should cover tortoisehg.

Given the obnoxiousness of Command Prompt, and how foreign it is to working on Windows, I think maybe there should be an addendum *somewhere*, but I don't expect anyone else to write it. (Goodness, there is a devguide chapter for emacs editing.) The easiest way to run direct hg commands is within the command pane of Workbench.

About  "run `make patchcheck`". The current Committing page gives
"(or ./python.exe Tools/scripts/patchcheck.py on Windows)" as the windows equivalent. './' does not work on Windows. '.\' will, but I do not know if it is needed. I presume the command should be given from within a particular repository. In its top directory, 'python' will run the installed python, 'PCbuild\python.exe' or 'PCbuild\python_d.exe' (backslash required here, though not in the patchcheck path) is needed to run the python built from that repository.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:47:00 2013
From: report at bugs.python.org (Kushal Das)
Date: Fri, 22 Feb 2013 05:47:00 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361512020.32.0.977632756778.issue17227@psf.upfronthosting.co.za>


Kushal Das added the comment:

Adding a patch to fix this issue.

----------
keywords: +patch
nosy: +kushaldas
Added file: http://bugs.python.org/file29155/issue17227.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:49:40 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 05:49:40 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361512180.81.0.991292800785.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> The "Clones setup" section is not about "how to set up a clone", but "how do I do these steps depending on the specific setup I'm using" (single or multiple clones).

Then the section should be called something like "Cloning approaches" rather than "Clones setup."  Neverthless, I think it would be good to have a separate subsection dedicated just to the setting up portion of multiple clones with the share extension (with an appropriate title).

>> For example, an issue can be created for adding to the docs a section on how to set up multiple clones.
>
> This is not the goal of this issue.

My remarks were about setting up multiple clones with the share extension.  I was suggesting that a separate issue be created to address that aspect of the current issue.  It's okay to add information on how to set up multiple clones with the share extension without initially saying everything about how to use this approach (just as the share extension is already linked to without including such instructions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:53:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 05:53:38 +0000
Subject: [issue17035] Use new style classes in {class, static}method examples
In-Reply-To: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>
Message-ID: <3ZC1v5213lzSqZ@mail.python.org>


Roundup Robot added the comment:

New changeset 30e7bc28d4f5 by Ezio Melotti in branch '2.7':
#17035: use new style classes in classmethod/staticmethod examples.  Patch by Berker Peksag.
http://hg.python.org/cpython/rev/30e7bc28d4f5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17035>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:53:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 05:53:38 +0000
Subject: [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <3ZC1v60mMRzSqZ@mail.python.org>


Roundup Robot added the comment:

New changeset ad55dc7de7fc by Ezio Melotti in branch '2.7':
#17256: fix syntax highlight in embedding example.  Patch by Kushal Das.
http://hg.python.org/cpython/rev/ad55dc7de7fc

New changeset b42e7aeb4235 by Ezio Melotti in branch '3.2':
#17256: fix syntax highlight in embedding example.  Patch by Kushal Das.
http://hg.python.org/cpython/rev/b42e7aeb4235

New changeset 3405d828ce95 by Ezio Melotti in branch '3.3':
#17256: merge with 3.2.
http://hg.python.org/cpython/rev/3405d828ce95

New changeset fb50eb64e097 by Ezio Melotti in branch 'default':
#17256: merge with 3.3.
http://hg.python.org/cpython/rev/fb50eb64e097

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:54:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 05:54:27 +0000
Subject: [issue17035] Use new style classes in {class, static}method examples
In-Reply-To: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>
Message-ID: <1361512467.39.0.176763798114.issue17035@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17035>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:55:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 05:55:04 +0000
Subject: [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361512504.26.0.425871105102.issue17256@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17256>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:55:23 2013
From: report at bugs.python.org (Jason S Friedman)
Date: Fri, 22 Feb 2013 05:55:23 +0000
Subject: [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
Message-ID: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>


New submission from Jason S Friedman:

Page is http://docs.python.org/3/library/tempfile.html#module-tempfile.

The code in question currently reads:
>>> f = NamedTemporaryFile(delete=False)
>>> f
<open file '<fdopen>', mode 'w+b' at 0x384698>
>>> f.name
'/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpG7V1Y0'
>>> f.write("Hello World!\n")
>>> f.close()
>>> os.unlink(f.name)
>>> os.path.exists(f.name)
False

It should read:
>>> import os
>>> from tempfile import NamedTemporaryFile
>>> f = NamedTemporaryFile(delete=False)
>>> f
<tempfile._TemporaryFileWrapper object at 0x29bfc50>
>>> f.name
'/tmp/tmpdxd_85'
>>> f.write("Hello World!\n".encode())
13
>>> f.close()
>>> os.unlink(f.name)
>>> os.path.exists(f.name)
False

----------
assignee: docs at python
components: Documentation
messages: 182640
nosy: docs at python, jsf80238 at gmail.com
priority: normal
severity: normal
status: open
title: NamedTemporaryFile expects bytes, not string in documentation for tempfile module
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17271>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:55:35 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 05:55:35 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361512535.49.0.369369964983.issue17227@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Adding a patch to fix this issue.

I had tried this, but doesn't this make the contents in the left side bar unwieldy (and perhaps also on the devguide index page) -- is that what we want?  I was under the assumption that the purpose of the tocdepth directive was to avoid that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:56:42 2013
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 22 Feb 2013 05:56:42 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
Message-ID: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>


New submission from Demian Brecht:

When assigning a value to an already instantiated Request object's full_url, unexpected results are found as a consequence in the attributes selector, type and fragment. Selector, type and fragment are only assigned to during instantiation. Unless you know to call Request._parse() after assignment to Request.full_url, the other attributes will not be reassigned new values.

The attached patch changes full_url to be a @property, essentially moving what was going on in the constructor into the property method(s). All tests pass.

I ran into this issue when working on an OAuth 2.0 client library when attempting to mutate an already instantiated Request object, injecting the access_token into the query params.

Sandboxed code to repro the issue below:

In [1]: from urllib.request import Request
In [2]: r = Request('https://example.com?foo=bar#baz')

# as expected
In [4]: r.__dict__
Out[4]: 
{'_data': None,
 '_tunnel_host': None,
 'fragment': 'baz',
 'full_url': 'https://example.com?foo=bar',
 'headers': {},
 'host': 'example.com',
 'method': None,
 'origin_req_host': 'example.com',
 'selector': '/?foo=bar',
 'type': 'https',
 'unredirected_hdrs': {},
 'unverifiable': False}

In [5]: r.full_url = 'https://example.com?foo=bar&access_token=token_value#baz'

# unexpected results in selector
In [6]: r.__dict__
Out[6]: 
{'_data': None,
 '_tunnel_host': None,
 'fragment': 'baz',
 'full_url': 'https://example.com?foo=bar&access_token=token_value#baz',
 'headers': {},
 'host': 'example.com',
 'method': None,
 'origin_req_host': 'example.com',
 'selector': '/?foo=bar',
 'type': 'https',
 'unredirected_hdrs': {},
 'unverifiable': False}

In [7]: Request('https://example.com?foo=bar&access_token=token_value#baz')
Out[7]: <urllib.request.Request at 0x10ef6ce90>

# these results should match that of the full_url setter
In [8]: Request('https://example.com?foo=bar&access_token=token_value#baz').__dict__
Out[8]: 
{'_data': None,
 '_tunnel_host': None,
 'fragment': 'baz',
 'full_url': 'https://example.com?foo=bar&access_token=token_value',
 'headers': {},
 'host': 'example.com',
 'method': None,
 'origin_req_host': 'example.com',
 'selector': '/?foo=bar&access_token=token_value',
 'type': 'https',
 'unredirected_hdrs': {},
 'unverifiable': False}

----------
components: Library (Lib)
files: request.patch
keywords: patch
messages: 182642
nosy: dbrecht
priority: normal
severity: normal
status: open
title: request.full_url: unexpected results on assignment
versions: Python 3.4
Added file: http://bugs.python.org/file29156/request.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 06:59:01 2013
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 22 Feb 2013 05:59:01 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361512741.2.0.0366124602457.issue17272@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I also meant to mention that of course, the obvious workaround would simply be to instantiate a new Request object with the new URL, but in my mind, this is something that should likely be supported by the Request object itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:07:10 2013
From: report at bugs.python.org (Kushal Das)
Date: Fri, 22 Feb 2013 06:07:10 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361513230.98.0.333245054894.issue17227@psf.upfronthosting.co.za>


Kushal Das added the comment:

>I had tried this, but doesn't this make the contents in the left side bar unwieldy (and perhaps also on the devguide index page) -- is that what we want?  I was under the assumption that the purpose of the tocdepth directive was to avoid that.

Yes, missed that issue. Trying to find any other solution if possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:12:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 06:12:59 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361513579.18.0.205529480628.issue14468@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As someone who previously tried but failed to setup shared clones, to avoid the apparently senseless copying of multiple copies of .hg/store, because of the inadequate disjointed doc, I like patch 1. I am using it now to redo my setup and batch file. I think how to set it up (10 lines) *should* be followed by how to use it. One thing that is missing though, which I think is or was in a current or previous version, is to put all the pull and update commands in a batch file. If the shared approach somehow mandates that they be interspersed with edit, merge, and commit, that would be a big negative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:19:31 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 06:19:31 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361513971.22.0.251367099389.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I think it would be good to have a separate subsection dedicated just 
> to the setting up portion of multiple clones with the share extension 

I'm not sure that's necessary though, given how simple it is (enable share extension, "hg share source dest", repeat).

The ideas are:
  1) have a straightforward from-beginning-to-end overview in committing.rst, followed by a few sections that explain more in detail the most common steps (e.g. how to merge between different versions, how to solve merge conflicts, etc.);
  2) list alternative approaches (e.g. multiple unshared clones) and "advanced" steps (e.g. deal with merge conflicts) in the FAQs;

If you think all the approaches should be listed somewhere, we can always add a new FAQ later, but it shouldn't block this issue (and it shouldn't be in committing.rst).

> One thing that is missing though, which I think is or was in a
> current or previous version, is to put all the pull and update
> commands in a batch file.

The point of the share extension is that is no longer necessary to pull/push changesets between clones (the updates still are though).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:20:53 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Fri, 22 Feb 2013 06:20:53 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
Message-ID: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>


New submission from Arun Babu Neelicattu:

The task/worker handler threads in the multiprocessing.pool.Pool class are (in accordance to posix standards) not copied over when the process containing the pool is forked.

This leads to a situation where the Pool keeps receiving tasks but the tasks never get handled. This could potentially lead to deadlocks if AsyncResult.wait() is called.

Not sure if this should be considered as a bug, or an invalid use case. However, this becomes a problem when importing modules that use pools and the main code uses multiprocessing too.

[BAD] Workaround:
Reassigning Pool._task_handler to a new instance of threading.Thread after the fork seems to work in the case highlighted in the example.

Environment:
Fedora 18 
Linux 3.7.8-202.fc18.x86_64 #1 SMP Fri Feb 15 17:33:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
python3-3.3.0-1.fc18.x86_64

An example of this issue is shown below:

from multiprocessing import Pool, Process

def t2():
	# We expect the pool to handle this
	print('t2: Hello!')

pool = Pool()
def t1():
	# We assign a task to the pool
	pool.apply_async(t2)
	print('t1: Hello!')

if __name__ == '__main__':
	# Process() forks the main process containing the pool
	Process(target=t1).start()

----------
components: Library (Lib)
files: pool_forking.py
messages: 182647
nosy: abn
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool task/worker handlers are not fork safe
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29157/pool_forking.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:27:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 06:27:27 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361514447.18.0.0653923435377.issue14468@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I meant one pull and multiple updates (instead of the multiple 'pull -u's I have now).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:29:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 06:29:46 +0000
Subject: [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
In-Reply-To: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>
Message-ID: <3ZC2hn6qBCzQRJ@mail.python.org>


Roundup Robot added the comment:

New changeset 82343bbf8868 by Ezio Melotti in branch '3.2':
#17271: update example in tempfile docs.
http://hg.python.org/cpython/rev/82343bbf8868

New changeset a9993d40821f by Ezio Melotti in branch '3.3':
#17271: merge with 3.2.
http://hg.python.org/cpython/rev/a9993d40821f

New changeset fcc61327c86c by Ezio Melotti in branch 'default':
#17271: merge with 3.3.
http://hg.python.org/cpython/rev/fcc61327c86c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17271>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:30:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 06:30:18 +0000
Subject: [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
In-Reply-To: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>
Message-ID: <1361514618.79.0.689026109919.issue17271@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17271>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:35:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 06:35:18 +0000
Subject: [issue17183] Small enhancements to Lib/_markupbase.py
In-Reply-To: <1360599068.18.0.00237006036364.issue17183@psf.upfronthosting.co.za>
Message-ID: <1361514918.54.0.561954179525.issue17183@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29158/issue17183.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17183>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:55:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 06:55:30 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <1361516130.48.0.902064469494.issue17249@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The attached patch converts the function in a real test, using proper skips and assert methods.

----------
components: +Library (Lib) -Tests
Added file: http://bugs.python.org/file29159/issue17249.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Fri Feb 22 07:58:07 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 22 Feb 2013 06:58:07 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361516287.92.0.972832095597.issue17269@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Looks like a bug in libSystem, see mdns_addrinfo in <http://www.opensource.apple.com/source/Libinfo/Libinfo-406.17/lookup.subproj/mdns_module.c>. Its handling of AI_NUMERICSERV doesn't match that of si_getaddrinfo.c at the same location.

I'll file a bug with Apple, anyone running into this problem migh want to do so as well (Apple's tracker is more or less a popularity contest, the more an issue is report, the more likely it is to get fixed).

I'm in favor of working around this bug on OSX by settings the servname to "0" when AI_NUMERICSERVICE is set and the passed in service name is None. I\m working on a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 08:03:11 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Fri, 22 Feb 2013 07:03:11 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361516591.74.0.623066783468.issue17273@psf.upfronthosting.co.za>


Changes by Arun Babu Neelicattu <alectolytic at gmail.com>:


----------
nosy: +jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Fri Feb 22 08:12:48 2013
From: report at bugs.python.org (Kushal Das)
Date: Fri, 22 Feb 2013 07:12:48 +0000
Subject: [issue17227] devguide: buggy heading numbers
In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za>
Message-ID: <1361517168.62.0.427326521384.issue17227@psf.upfronthosting.co.za>


Kushal Das added the comment:

I found that http://docs.python.org/devguide/stdlibchanges.html also has left side bar text with full index just like my patch does. For FAQ the problem is title texts are kind of long so they look bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17227>
_______________________________________

From report at bugs.python.org  Fri Feb 22 08:17:16 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 22 Feb 2013 07:17:16 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361517436.08.0.66558372708.issue17269@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

That's interesting... this also crashes:

>>> socket.getaddrinfo("localhost", "0", 0, 0, 0, socket.AI_NUMERICSERV)

While using another port number does not.

The attached patches for the default branch fixes the issue for me (on OSX 10.8). 

The same approach should also work with 2.7 (but the patch likely won't apply cleanly due to the use of TABs for indents in 2.7 and spaces in 3.x).

Open issue: should there be a testcase for this problem?

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file29160/issue17269.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 08:25:22 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 22 Feb 2013 07:25:22 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361517922.13.0.680361247342.issue17269@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I've filed radar #13271126 for this in Apple's tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 08:35:46 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Fri, 22 Feb 2013 07:35:46 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361518546.08.0.924707089889.issue17273@psf.upfronthosting.co.za>


Arun Babu Neelicattu added the comment:

I should have mentioned this too,

[GOOD] Workaround:
Probably the 'correct' way to achieve what is required in the example, could be to use a managed pool.

pool = multiprocessing.Manager().Pool()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Fri Feb 22 08:41:18 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Feb 2013 07:41:18 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361518878.1.0.222222977383.issue17263@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Could you try with recent checkout of python 2.7?
I wonder if this could be an occurrence of issue #13992 fixed by Antoine a couple months ago.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Fri Feb 22 09:02:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 08:02:26 +0000
Subject: [issue13262] IDLE opens partially hidden
In-Reply-To: <1319538134.39.0.210129529894.issue13262@psf.upfronthosting.co.za>
Message-ID: <1361520146.67.0.598034113371.issue13262@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13262>
_______________________________________

From report at bugs.python.org  Fri Feb 22 10:34:13 2013
From: report at bugs.python.org (Florian Berger)
Date: Fri, 22 Feb 2013 09:34:13 +0000
Subject: [issue17274] distutils silently omits relative symlinks
Message-ID: <1361525653.88.0.944877368203.issue17274@psf.upfronthosting.co.za>


New submission from Florian Berger:

This issue is related to #12585, #15205 and #8876.

In `distutils/archive_util.py`, in `make_zipfile()`, the code

    for dirpath, dirnames, filenames in os.walk(base_dir):
        for name in filenames:
            path = os.path.normpath(os.path.join(dirpath, name))
            if os.path.isfile(path):
                zip.write(path, path)
                log.info("adding '%s'" % path)

will silently omit relative symlinks from the archive.

Relative symlinks (`file.dat -> ../../../real_file.dat`) will become invalid when copied as-is into the package directory before compressing.
`os.path.isfile(path)` will evaluate to `False` in this case.

That is a critical condition, as the file has explicitly been specified for inclusion, but the package author is never warned about the fact, rendering the distributed package defunct in worst case.

Actual behaviour: relative symlinks are silently ignored.

Expected behaviour: any file that, for whatever reason, can not be included in the distribution archive should be warned about.

As hinted at in #15205, this might be fixed in `distutils2` / `packaging` in case it always dereferences and copies files.

This issue could be fixed without breaking behaviour if no Exception is raised, but a warning is printed.

With `packaging` available in Python 3.3, this report also serves as documentation of the problem for legacy Python programmers searching the web.

Thanks for considering.

----------
assignee: eric.araujo
components: Distutils
messages: 182658
nosy: eric.araujo, fberger, tarek
priority: normal
severity: normal
status: open
title: distutils silently omits relative symlinks
versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17274>
_______________________________________

From report at bugs.python.org  Fri Feb 22 10:50:12 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 22 Feb 2013 09:50:12 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361526612.78.0.0680697268195.issue17273@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

A pool should only be used by the process that created it (unless you use a managed pool).

If you are creating long lived processes then you could create a new pool on demand.  For example (untested)

    pool_pid = (None, None)

    def get_pool():
        global pool_pid
        if os.getpid() != pool_pid[1]:
            pool_pid = (Pool(), os.getpid())
        return pool_pid[0]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Fri Feb 22 12:51:50 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Fri, 22 Feb 2013 11:51:50 +0000
Subject: [issue17275] io.BufferedWriter shows wrong type in argument error
	message
Message-ID: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>


New submission from Manuel Jacob:

>>> import io
>>> io.BufferedWriter(io.BytesIO(), 1024, 1024, 1024)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: BufferedReader() takes at most 2 arguments (4 given)

It should be "BufferedWriter()" instead of "BufferedReader()".

----------
messages: 182660
nosy: mjacob
priority: normal
severity: normal
status: open
title: io.BufferedWriter shows wrong type in argument error message
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17275>
_______________________________________

From report at bugs.python.org  Fri Feb 22 12:59:55 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Fri, 22 Feb 2013 11:59:55 +0000
Subject: [issue17275] io.BufferedWriter shows wrong type in argument error
	message
In-Reply-To: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>
Message-ID: <1361534395.27.0.821461741931.issue17275@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

The attached patch fixes the issue. Should I write a test?

----------
keywords: +patch
Added file: http://bugs.python.org/file29161/issue17275.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17275>
_______________________________________

From report at bugs.python.org  Fri Feb 22 13:16:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Feb 2013 12:16:42 +0000
Subject: [issue17276] HMAC: deprecate default hash
Message-ID: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>


New submission from Christian Heimes:

As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.

Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too.

In addition I would like to enhance the meaning of the `digestmod` argument a bit. Right now it either must be a module or a callable. It should also support a name, e.g. hmac.new("secret", digestmod="sha256")

----------
components: Library (Lib)
messages: 182662
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: HMAC: deprecate default hash
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Fri Feb 22 13:48:38 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 22 Feb 2013 12:48:38 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1361537318.14.0.64376631275.issue17276@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

+1.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Fri Feb 22 14:00:14 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 22 Feb 2013 13:00:14 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1361538014.69.0.301315028966.issue16043@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Fri Feb 22 14:33:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Feb 2013 13:33:14 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361539994.3.0.477199716597.issue17272@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, full_url was not designed to be assignable, and is documented that way (the docs say it is the URL passed to the constructor).  Whether or not it is reasonable to make it assignable is an interesting question.

----------
nosy: +r.david.murray
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 14:37:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Feb 2013 13:37:11 +0000
Subject: [issue17275] io.BufferedWriter shows wrong type in argument error
	message
In-Reply-To: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>
Message-ID: <1361540231.34.0.754174141086.issue17275@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would be great.  Use assertRaisesRegex and check that the correct name is in the message string.

----------
nosy: +pitrou, r.david.murray
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17275>
_______________________________________

From report at bugs.python.org  Fri Feb 22 14:59:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Feb 2013 13:59:57 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1361541597.53.0.600667535881.issue17276@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't know how you intend to make `digestmod` mandatory given the current function signature.

> Applications should slowly migrate away from HMAC-MD5 and use a more
> modern algorithm like HMAC-SHA256.

Applications don't always choose their cipher. MD5 is needed for compatibility with existing protocols such as CRAM-MD5.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Fri Feb 22 15:47:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Feb 2013 14:47:47 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <1361544467.0.0.384510081104.issue17249@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Fri Feb 22 15:51:25 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Feb 2013 14:51:25 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1361544685.03.0.487997165477.issue17276@psf.upfronthosting.co.za>


Christian Heimes added the comment:

> I don't know how you intend to make `digestmod` mandatory given the current function signature.

That's easy:

if digestmod is None:
    raise TypeError("HMAC needs argument 'digestmod'")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Fri Feb 22 16:13:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Feb 2013 15:13:05 +0000
Subject: [issue17276] HMAC: deprecate default hash
In-Reply-To: <1361535402.96.0.618065106631.issue17276@psf.upfronthosting.co.za>
Message-ID: <1361545985.66.0.160072518935.issue17276@psf.upfronthosting.co.za>


Christian Heimes added the comment:

PS: I don't want to deprecate HMAC-MD5. I just want to deprecate that HMAC defaults to HMAC-MD5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17276>
_______________________________________

From report at bugs.python.org  Fri Feb 22 16:28:55 2013
From: report at bugs.python.org (Vladimir Rutsky)
Date: Fri, 22 Feb 2013 15:28:55 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1361546935.46.0.187395168604.issue8800@psf.upfronthosting.co.za>


Changes by Vladimir Rutsky <rutsky.vladimir at gmail.com>:


----------
nosy: +vrutsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Fri Feb 22 16:33:18 2013
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 22 Feb 2013 15:33:18 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361547198.15.0.745928239002.issue17272@psf.upfronthosting.co.za>


Demian Brecht added the comment:

It could entirely be my lack of being Dutch that didn't make this obvious without reading the docs ;)

I guess there's one of three ways that this could go:

To help clarify the intention through code, either

a) Change full_url to _full_url, indicating that this should be treated as a private member and only expose the url through get_full_url(). This will obviously have the negative side effect of breaking backwards compatibility for anyone using full_url directly.

b) Keep the property implementation in the patch, but replace the setter with a read-only exception.

And the third option is what's in this patch (there are likely other options that I'm just not seeing at the moment as well).

Having said all that, if the mutability of full_url is made explicit, then safeguards should also be put in place for the rest of the attributes.


I couldn't think of any hard reason as to why the state of a Request instance /shouldn't/ be mutable and the user should be required to instantiate a new Request in order to use a new URL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 17:19:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Feb 2013 16:19:31 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361549971.4.0.217400444935.issue17272@psf.upfronthosting.co.za>


R. David Murray added the comment:

One of those other options is: do nothing :)

Python doesn't normally make things read-only just because mutating them does nothing useful.  Sometimes we make things read-only when mutating them does nasty stuff, but even then sometimes we don't.

So the real question is, do others consider it a sensible and useful API change to make setting it do something useful, and how many other changes would be required to make the rest of the API consistent with that change?

We may be in python-ideas territory here, I'm not sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 17:42:49 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 22 Feb 2013 16:42:49 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
Message-ID: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

It seems that using f_trace in the f_lineno getter PyFrame_GetLineNumber(), as
the condition to decide when tracing is active, is incorrect.
See the following two examples.

In the backtrace printed by tracer.py running with python 3.3,
the last entry should be line 12 instead of line 10:

$ python3 /tmp/tracer.py
Traceback (most recent call last):
  File "/tmp/tracer.py", line 15, in <module>
    foo()
  File "/tmp/tracer.py", line 10, in foo
    bar()
ZeroDivisionError: division by zero


This simple case does not occur with pdb, because pdb takes care of deleting
the f_trace attribute of all the frames in the call stack when removing the
trace function (see set_continue() in bdb.py). But this is not good enough when
a generator is involved as can be seen when running generator.py. In the
backtrace the last entry should be line 6 instead of line 8:

$ python3 /tmp/generator.py
> /tmp/generator.py(16)<module>()
-> foo()
(Pdb) step
--Call--
> /tmp/generator.py(10)foo()
-> def foo():
(Pdb) step
> /tmp/generator.py(11)foo()
-> it = gen()
(Pdb) step
> /tmp/generator.py(12)foo()
-> next(it)
(Pdb) step
--Call--
> /tmp/generator.py(3)gen()
-> def gen():
(Pdb) return
--Return--
> /tmp/generator.py(8)gen()->0
-> yield i
(Pdb) step
> /tmp/generator.py(13)foo()
-> next(it)
(Pdb) continue
Traceback (most recent call last):
  File "/tmp/generator.py", line 16, in <module>
    foo()
  File "/tmp/generator.py", line 13, in foo
    next(it)
  File "/tmp/generator.py", line 8, in gen
    yield i
ZeroDivisionError: division by zero


It seems that it could be possible to fix this issue by replacing the test for
f->f_trace in PyFrame_GetLineNumber, by a test for f->f_tstate->use_tracing,
and updating accordingly the f_lineno and f_trace setters.

----------
components: Interpreter Core
files: tracer.py
messages: 182672
nosy: xdegaye
priority: normal
severity: normal
status: open
title: incorrect line numbers in backtrace after removing a trace function
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29162/tracer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Fri Feb 22 17:43:21 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 22 Feb 2013 16:43:21 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361551401.82.0.68595833563.issue17277@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


Added file: http://bugs.python.org/file29163/generator.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Fri Feb 22 17:54:20 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Fri, 22 Feb 2013 16:54:20 +0000
Subject: [issue17275] io.BufferedWriter shows wrong type in argument error
	message
In-Reply-To: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>
Message-ID: <1361552060.75.0.521588409217.issue17275@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

Added a new patch including tests for the C implementations of BufferedWriter and BufferedRandom.

----------
Added file: http://bugs.python.org/file29164/issue17275_with_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17275>
_______________________________________

From report at bugs.python.org  Fri Feb 22 18:10:26 2013
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 22 Feb 2013 17:10:26 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361553026.42.0.316467508247.issue17272@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Yes, I realized that I had forgotten to add the "do nothing" option after posting but figured it was relatively obvious :)

"Python doesn't normally make things read-only just because mutating them does nothing useful.  Sometimes we make things read-only when mutating them does nasty stuff, but even then sometimes we don't."

I realize that this is a higher level question and outside of the scope of this particular issue (and likely belonging more in python-ideas), but doesn't this somewhat contradict "There should be one-- and preferably only one --obvious way to do it."? I'd assume that this should not only apply to sandboxed object implementations, but also at a higher level across /all/ objects. From your post, I assume inconsistency between modules, which would imply non-obvious ways to "do something" when moving from one module (or object) implementation to the next.

I'm definitely interested to hear whether or not others would find this change useful as I do. There /should/ be no other changes required for consistency as no other attributes of the Request class that don't already implement assignment methods (i.e. "data") are affected by side effects within __init__ (or anywhere else).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 18:12:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Feb 2013 17:12:50 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <1361553170.06.0.348124748447.issue17249@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This test was introduced in a4154dd5939a.

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Fri Feb 22 18:26:07 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Feb 2013 17:26:07 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1361553967.12.0.844287227501.issue16123@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The issue is usually with firewalls, security software, socket issues, etc.  While the root problem lies outside IDLE, often the simplest way to get someone up and running is to use the -n option.

This is one of many annoyances that arise when teaching students Python using IDLE:
* Preferences window crashing
* Default font-size on a retina mac is tiny
* Inability to shutoff the prominent warning messages
* Control-A goes to the beginning of the line, past the >>> prompt.
* On Windows, IDLE sometimes has a two second delay before it runs scripts
* Students find that IDLE mysteriously pastes a clipboard into the interactive prompt unintentionally
* It is a common complaint that IDLE hangs
* Getting the correct Tcl/Tk setup on Macs is problematic.
* Starting IDLE from the command line emits messages about "setCanCycle is deprecated"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Fri Feb 22 18:32:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 17:32:59 +0000
Subject: [issue17212] os.path.isfile() in Python 3.3 sometimes fails
In-Reply-To: <1360968598.97.0.73683430526.issue17212@psf.upfronthosting.co.za>
Message-ID: <1361554379.44.0.503204970288.issue17212@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#17137 has a patch that will be in 3.3.1, coming soon we hope. If you cannot build Python on Windows, please retest with the new release.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17212>
_______________________________________

From report at bugs.python.org  Fri Feb 22 18:36:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 17:36:42 +0000
Subject: [issue17213] ctypes loads wrong version of C runtime,
	leading to error message box from system
In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za>
Message-ID: <1361554602.07.0.459376728454.issue17213@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage:  -> needs patch
versions: +Python 2.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17213>
_______________________________________

From report at bugs.python.org  Fri Feb 22 18:59:53 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 22 Feb 2013 17:59:53 +0000
Subject: [issue17217] Fix test discovery for test_format.py on Windows
In-Reply-To: <1361055748.87.0.775684522637.issue17217@psf.upfronthosting.co.za>
Message-ID: <1361555993.38.0.72325987219.issue17217@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Your patch is certainly much simpler and more effective than mine; consider mine withdrawn.  I didn't take the simple step of figuring out exactly where the problem was happening and was just trying to fix the issue without changing anything in the actual tests....oops :-S

I'll raise other issues about moving replace_stdout and unittest verbosity soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17217>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:06:51 2013
From: report at bugs.python.org (Julian Berman)
Date: Fri, 22 Feb 2013 18:06:51 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1361556411.57.0.755144455556.issue9584@psf.upfronthosting.co.za>


Changes by Julian Berman <Julian+Python.org at GrayVines.com>:


----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:16:09 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:16:09 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1361556969.76.0.276413441809.issue17214@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Please give us
1. the exact Python version used. 3.2.3? or something earlier?
2. A minimal but complete example that we can run. What is 'headers'?
3. The complete traceback, not just the last two entries.
4. The result of running with the newer 3.3.0, if you possibly can. Perhaps the problem has already been fixed.

While line numbers have changed, even in 3.2.4 in repository, 3.2-3.4 all have

        request = '%s %s %s' % (method, url, self._http_vsn_str)
        # Non-ASCII characters should have been eliminated earlier
        self._output(request.encode('ascii'))

Since there is nothing earlier in the function that would eliminate non-ascii, there must be an assumption about what happens earlier in the call chain. That might have already been fixed, which is why we need an example to test.

----------
components: +Library (Lib) -Unicode
nosy: +orsenthil, terry.reedy
stage:  -> test needed
type:  -> behavior
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:26:11 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:26:11 +0000
Subject: [issue17224] can not open idle in python 2.7.3
In-Reply-To: <1361176830.93.0.935966223453.issue17224@psf.upfronthosting.co.za>
Message-ID: <1361557571.19.0.917586124986.issue17224@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serwy, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17224>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:30:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:30:19 +0000
Subject: [issue17229] unable to discover preferred HTTPConnection class
In-Reply-To: <1361222471.81.0.536204108906.issue17229@psf.upfronthosting.co.za>
Message-ID: <1361557819.35.0.472043615796.issue17229@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +orsenthil
stage:  -> test needed
type:  -> enhancement
versions:  -3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17229>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:43:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:43:37 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361558617.16.0.0408448035956.issue17232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that we should document exactly what is now. Patch replaces first sentence with Nick's. It is against 3.4, but should be identical for all versions. Maciej, thanks for reminding us to finally fix this.

----------
keywords: +patch
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29165/issue17232.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:45:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Feb 2013 18:45:11 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361558711.93.0.445219488516.issue17232@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Should probably be "Remove", not "Removes" (we use infinitives to describe the actions undertaken by a command / option / method ...).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:46:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:46:12 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361558772.14.0.387267642871.issue17232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps '__debug__' need markup, but if so, I don't know how.
And I agree with Antoine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:49:20 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Feb 2013 18:49:20 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>
Message-ID: <1361558960.55.0.769446609877.issue17186@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Could you please give an example of why this would be a useful addition?
I can see the usage of removing a handler, but the user should know which handlers are registered.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:51:28 2013
From: report at bugs.python.org (Chris Withers)
Date: Fri, 22 Feb 2013 18:51:28 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>
Message-ID: <1361559088.82.0.480896465777.issue17186@psf.upfronthosting.co.za>


Chris Withers added the comment:

Barry advised me to open this issue as it's a functional regression from Python 2.

My use case is unit testing code that registers atexit handlers and making sure the right handlers are registered with the correct parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:54:20 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Feb 2013 18:54:20 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <1361559088.82.0.480896465777.issue17186@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3tx8YSJGAB0D=dJAcmrexNeM6sExNCHBVbYERvZCoH=A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Barry advised me to open this issue as it's a functional regression from Python 2.

But it was relying on a private and non documented feature in Python
2, so it's not really a regression.

> My use case is unit testing code that registers atexit handlers and making sure the right handlers are registered with the correct parameters.

IMO, complicating an API for testing purpose is a bad idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Fri Feb 22 19:55:26 2013
From: report at bugs.python.org (Chris Withers)
Date: Fri, 22 Feb 2013 18:55:26 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>
Message-ID: <1361559326.3.0.821374883812.issue17186@psf.upfronthosting.co.za>


Chris Withers added the comment:

I can think of other use cases. Anyway, I'm just glad your opinion isn't the only one there is ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:02:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Feb 2013 19:02:57 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1361559777.38.0.35493206339.issue17137@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Shouldn't this issue be closed now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17137>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:08:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Feb 2013 19:08:08 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <1360622130.89.0.261803397072.issue17186@psf.upfronthosting.co.za>
Message-ID: <1361560088.11.0.299091030764.issue17186@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't think you want your test suite to run your atexit handlers at exit, so you should probably mock atexit.register instead.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:15:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 19:15:59 +0000
Subject: [issue17233] http.client header debug output format
In-Reply-To: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>
Message-ID: <1361560559.65.0.522199092025.issue17233@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The doc is vague on debug output (intentionally so, I suspect).
" Any value greater than 0 will cause all currently defined debug output to be printed to stdout."

I agree that send: and reply: should be formatted the same, so the reply: line should include the headers *with* the values. The current header line seems to be truncated after Date, without even its ':', and it is definitely missing a newline. Are you claiming that there are other missing newlines? I don't understand the lines with
send: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00')

Patches are good, but you might wait a few days for other comments as I am definitely not an http expert.

----------
nosy: +terry.reedy
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:29:42 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Feb 2013 19:29:42 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1361561382.77.0.438829467087.issue17180@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

> Shouldn't you try to make the permission removal atomic?
> Otherwise there's a window of opportunity to exploit the suid bit.

Actually there's already a race even without setuid bit: http://bugs.python.org/issue15100

All metadat should be set atomically.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:34:48 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 19:34:48 +0000
Subject: [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361561688.7.0.115266304344.issue17259@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'%.0f' % 5.5, etc, does the same. I agree that consistent 3.x half to even is both correct and and in need of better doc to avoid repeated questions and invalid bug reports.

----------
nosy: +terry.reedy
title: locale.format() rounding is not reliable for floats -> Document round half to even rule for floats
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:41:54 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 22 Feb 2013 19:41:54 +0000
Subject: [issue17186] no way to introspect registered atexit handlers
In-Reply-To: <CAH_1eM3tx8YSJGAB0D=dJAcmrexNeM6sExNCHBVbYERvZCoH=A@mail.gmail.com>
Message-ID: <20130222144141.3cfccd02@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Feb 22, 2013, at 06:54 PM, Charles-Fran?ois Natali wrote:

>Charles-Fran?ois Natali added the comment:
>
>> Barry advised me to open this issue as it's a functional regression from
>> Python 2.
>
>But it was relying on a private and non documented feature in Python
>2, so it's not really a regression.

I also suggested it would have to be considered a new feature for 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17186>
_______________________________________

From report at bugs.python.org  Fri Feb 22 20:54:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Feb 2013 19:54:57 +0000
Subject: [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361562897.37.0.138329938329.issue17259@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:02:42 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Feb 2013 20:02:42 +0000
Subject: [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361563362.94.0.330362417682.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Indeed, in Python 3, round and new-style string formatting both do round-ties-to-even, by design.  Old-style formatting does whatever the underlying OS does, which is typically round-half-away-from-zero.

Python 2 is a bit more of a mess:  in 2.7, new-style formatting does round-ties-to-even, round does round-half-away-from-zero, and old-style formatting continues to do whatever the OS does, just as in Python 3.  And 2.6 is different again (and much more system dependent).

Agreed that this could be better documented for 'format'.  The documentation for the round function is already explicit on this, at least for Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:05:35 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Fri, 22 Feb 2013 20:05:35 +0000
Subject: [issue17233] http.client header debug output format
In-Reply-To: <1361256774.67.0.162902666936.issue17233@psf.upfronthosting.co.za>
Message-ID: <1361563535.91.0.63105084809.issue17233@psf.upfronthosting.co.za>


Kim Gr?sman added the comment:

Thanks for your response!

> I agree that send: and reply: should be formatted the same, 
> so the reply: line should include the headers *with* the
> values.

OK, yeah, that would avoid having to specify request/response for headers as well, I think.

> The current header line seems to be truncated after Date,
> without even its ':',

It doesn't look like there are any trailing colons on header names. Rather, all header names have a "header: " prefix. As you can see, it's pretty hard to parse :-)

> and it is definitely missing a newline.

Glad we agree!

> Are you claiming that there are other missing newlines?

It's not visible in the attached log, but if you add print() statements in a script using http.client, the output usually ends up at the end of one of http.client's log lines. So I think every log output is missing a newline.

> I don't understand the lines with
> send: bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00')

We're sending binary data in our HTTP body, so this is the actual content. For some reason, though, the fact that it's binary seems to force it onto its own line.

> Patches are good, but you might wait a few days
> for other comments as I am definitely not an http expert.

OK, thanks again!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17233>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:06:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 20:06:33 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361563593.29.0.233030482701.issue17269@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On win7, the original example and '0' version give
[(23, 0, 0, '', ('::1', 0, 0, 0)), (2, 0, 0, '', ('127.0.0.1', 0))]
I think a testcase would be good.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:14:58 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 22 Feb 2013 20:14:58 +0000
Subject: [issue17218] support title and description in argparse
	add_mutually_exclusive_group
In-Reply-To: <1361061502.09.0.252084655816.issue17218@psf.upfronthosting.co.za>
Message-ID: <1361564098.13.0.335158336757.issue17218@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17218>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:16:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 20:16:37 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361564197.42.0.591398467806.issue17272@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe the issue of reusing request objects after modification has come up before, either on the tracker (but I cannot find an issue) or elsewhere. Senthil may remember better and certainly may have an opinion. I agree that python-idea would be a better place for other opinions.

----------
nosy: +orsenthil, terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17272>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:23:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 20:23:20 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361564600.78.0.672762695576.issue17273@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Arun, to call this a bug, you need to demonstrate a conflict between behavior and doc, and I do not see that you have.

Richard, are you suggesting that we close this, or do you see an actionable issue? (a plausible patch to the repository?)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:25:39 2013
From: report at bugs.python.org (maxxedev)
Date: Fri, 22 Feb 2013 20:25:39 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
Message-ID: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>


New submission from maxxedev:

I've been getting sporadic SIGSEGV crashes in _heapqmodule.c

I have not be able to reliably reproduce it, but here is a stacktrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaad51d940 (LWP 13976)]
(gdb) where
#0  0x00002aaaab617e8a in _siftdown (heap=0xa1f2d8, startpos=0, pos=46)
    at [...]/Python-2.7.2/Modules/_heapqmodule.c:67
#1  0x00002aaaab617f76 in heappush (self=<value optimized out>, args=<value optimized out>)
    at [...]/Python-2.7.2/Modules/_heapqmodule.c:137
#2  0x000000000049ba34 in call_function (f=0xa565e0, throwflag=<value optimized out>) at Python/ceval.c:4013
#3  PyEval_EvalFrameEx (f=0xa565e0, throwflag=<value optimized out>) at Python/ceval.c:2666
#4  0x000000000049ca8d in call_function (f=0xa60f40, throwflag=<value optimized out>) at Python/ceval.c:4099
#5  PyEval_EvalFrameEx (f=0xa60f40, throwflag=<value optimized out>) at Python/ceval.c:2666
#6  0x000000000049ca8d in call_function (f=0xa5e210, throwflag=<value optimized out>) at Python/ceval.c:4099
#7  PyEval_EvalFrameEx (f=0xa5e210, throwflag=<value optimized out>) at Python/ceval.c:2666
#8  0x000000000049ca8d in call_function (f=0xa5e020, throwflag=<value optimized out>) at Python/ceval.c:4099
#9  PyEval_EvalFrameEx (f=0xa5e020, throwflag=<value optimized out>) at Python/ceval.c:2666
#10 0x000000000049ca8d in call_function (f=0xa5de00, throwflag=<value optimized out>) at Python/ceval.c:4099
#11 PyEval_EvalFrameEx (f=0xa5de00, throwflag=<value optimized out>) at Python/ceval.c:2666
#12 0x000000000049ca8d in call_function (f=0xa5dc30, throwflag=<value optimized out>) at Python/ceval.c:4099
#13 PyEval_EvalFrameEx (f=0xa5dc30, throwflag=<value optimized out>) at Python/ceval.c:2666
#14 0x000000000049d87b in PyEval_EvalCodeEx (co=0x896530, globals=<value optimized out>, locals=<value optimized out>,
    args=0x99dba8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3253
#15 0x00000000004fbf9f in function_call (func=0x8c30c8, arg=0x99db90, kw=0x0) at Objects/funcobject.c:526
#16 0x000000000041882d in PyObject_Call (func=0x8c30c8, arg=0x99db90, kw=0x0) at Objects/abstract.c:2529
#17 0x000000000041fd3f in instancemethod_call (func=<value optimized out>, arg=0x99db90, kw=0x0)
    at Objects/classobject.c:2578
#18 0x000000000041882d in PyObject_Call (func=0x2aaaaab7e730, arg=0x2aaaaaabc050, kw=0x0) at Objects/abstract.c:2529
#19 0x0000000000494a66 in PyEval_CallObjectWithKeywords (func=0x2aaaaab7e730, arg=0x2aaaaaabc050, kw=0x0)
    at Python/ceval.c:3882
#20 0x00000000004d30d2 in t_bootstrap (boot_raw=0x96d320) at ./Modules/threadmodule.c:614
#21 0x0000003fa780683d in start_thread () from /lib64/libpthread.so.0
#22 0x0000003fa6cd503d in clone () from /lib64/libc.so.6

----------
components: Library (Lib)
messages: 182698
nosy: maxxedev
priority: normal
severity: normal
status: open
title: SIGSEGV in _heapqmodule.c
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:31:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 20:31:19 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361565079.32.0.327456798347.issue17277@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:31:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Feb 2013 20:31:55 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
In-Reply-To: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>
Message-ID: <1361565115.99.0.4218268366.issue17278@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Extension Modules -Library (Lib)
nosy: +rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Fri Feb 22 21:34:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Feb 2013 20:34:45 +0000
Subject: [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361565285.83.0.586145904365.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Bah.  Ignore me;  I don't know what I'm talking about.  Old-style formatting does round-half-to-even, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Fri Feb 22 22:16:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 21:16:56 +0000
Subject: [issue17212] os.path.isfile() in Python 3.3 sometimes fails
In-Reply-To: <1360968598.97.0.73683430526.issue17212@psf.upfronthosting.co.za>
Message-ID: <1361567816.74.0.172815878817.issue17212@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
status: open -> pending
superseder:  -> Malfunctioning compiled code in Python 3.3 x64

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17212>
_______________________________________

From report at bugs.python.org  Fri Feb 22 22:19:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 21:19:19 +0000
Subject: [issue17213] ctypes loads wrong version of C runtime,
	leading to error message box from system
In-Reply-To: <1360992800.86.0.617349310494.issue17213@psf.upfronthosting.co.za>
Message-ID: <1361567959.51.0.35411357511.issue17213@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for the report.  Could you also provide a patch?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17213>
_______________________________________

From report at bugs.python.org  Fri Feb 22 22:45:09 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 22 Feb 2013 21:45:09 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361569509.71.0.70288669502.issue17273@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Richard, are you suggesting that we close this, or do you see an 
> actionable issue? (a plausible patch to the repository?)

I skimmed the documentation and could not see that this restriction has been documented.

So I think a documentation patch would be a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Fri Feb 22 22:58:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 22 Feb 2013 21:58:26 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
In-Reply-To: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>
Message-ID: <1361570306.27.0.791351254179.issue17278@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The heapq C implementation is apparently not thread-safe: PyObject_RichCompareBool() and Py_DECREF() can lead to arbitrary python code being called, which can result in a context switch.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Fri Feb 22 23:09:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 22:09:24 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
Message-ID: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

More than once, people have noted on python-list that not all built-in classes can be subclassed and that there seems to be no way to find out which, other than to try each. (Today, Daniel Urban pointed out the CPython-specific 'xx.__flags__ & (1 << 10)'.) If the specifics are a Python feature, rather than CPython specific, I think they should be given in the doc.

There is a recent issue, which I cannot find, about re-organizing the Library built-in functions chapter by groups. If this is done, it would be easy to add, in the introduction to built-in classes, a list of which of the named classes can or cannot be subclassed (whichever list is shorter) and note that those not in builtins cannot be.)

----------
assignee: docs at python
components: Documentation
messages: 182703
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document which named built-in classes can be subclassed
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17279>
_______________________________________

From report at bugs.python.org  Fri Feb 22 23:09:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Feb 2013 22:09:28 +0000
Subject: [issue17137] Malfunctioning compiled code in Python 3.3 x64
In-Reply-To: <1360085542.96.0.0792349837187.issue17137@psf.upfronthosting.co.za>
Message-ID: <1361570968.58.0.564700533054.issue17137@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Shouldn't this issue be closed now?

Correct, I forgot to close it.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17137>
_______________________________________

From report at bugs.python.org  Fri Feb 22 23:52:35 2013
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Feb 2013 22:52:35 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361573555.78.0.27372826619.issue17279@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +daniel.urban

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17279>
_______________________________________

From report at bugs.python.org  Fri Feb 22 23:59:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 22:59:09 +0000
Subject: [issue17246] cgitb fails when frame arguments are deleted (due to
	inspect bug I think)
In-Reply-To: <1361312556.73.0.83895942435.issue17246@psf.upfronthosting.co.za>
Message-ID: <1361573949.9.0.501858885626.issue17246@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The bug seems to be in inspect indeed:

import inspect
def fun(x):
    del x
    return inspect.currentframe()

inspect.formatargvalues(*inspect.getargvalues(fun(10)))

Attached a proof-of-concept patch that replaces the missing value with <deleted>.  If the approach is ok, the same fix might have to be applied to other functions and/or other types of arguments.

----------
keywords: +patch
nosy: +ezio.melotti
stage:  -> patch review
type:  -> behavior
Added file: http://bugs.python.org/file29166/issue17246.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17246>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:03:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 23:03:29 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za>
Message-ID: <1361574209.22.0.548670274357.issue17254@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:05:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 23:05:38 +0000
Subject: [issue17272] request.full_url: unexpected results on assignment
In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za>
Message-ID: <1361574338.36.0.238712833196.issue17272@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/issue17272>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:32:27 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:32:27 +0000
Subject: [issue16043] xmlrpc: gzip_decode has unlimited read()
In-Reply-To: <1348570326.9.0.587983624118.issue16043@psf.upfronthosting.co.za>
Message-ID: <1361575947.85.0.526097084814.issue16043@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16043>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:33:45 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:33:45 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1361576025.91.0.296116206328.issue16037@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:40:35 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:40:35 +0000
Subject: [issue17239] XML vulnerabilities in Python
In-Reply-To: <1361288141.97.0.791394359972.issue17239@psf.upfronthosting.co.za>
Message-ID: <1361576435.98.0.475913997923.issue17239@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17239>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:46:34 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:46:34 +0000
Subject: [issue16038] ftplib: unlimited readline() from connection
In-Reply-To: <1348569175.14.0.867789583045.issue16038@psf.upfronthosting.co.za>
Message-ID: <1361576794.56.0.0433228909403.issue16038@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16038>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:47:25 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:47:25 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1361576845.33.0.517337613726.issue16039@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:47:40 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:47:40 +0000
Subject: [issue16040] nntplib: unlimited readline() from connection
In-Reply-To: <1348569525.38.0.219080768405.issue16040@psf.upfronthosting.co.za>
Message-ID: <1361576860.85.0.567999846087.issue16040@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16040>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:48:13 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:48:13 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1361576893.92.0.18211544002.issue16041@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:48:28 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:48:28 +0000
Subject: [issue16042] smtplib: unlimited readline() from connection
In-Reply-To: <1348569609.82.0.499861906556.issue16042@psf.upfronthosting.co.za>
Message-ID: <1361576908.01.0.919901036079.issue16042@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16042>
_______________________________________

From report at bugs.python.org  Sat Feb 23 00:51:48 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 22 Feb 2013 23:51:48 +0000
Subject: [issue17180] shutil copy* unsafe on POSIX - they preserve
	setuid/setgit bits
In-Reply-To: <1360573856.52.0.124531930967.issue17180@psf.upfronthosting.co.za>
Message-ID: <1361577108.18.0.569621356937.issue17180@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17180>
_______________________________________

From report at bugs.python.org  Sat Feb 23 02:39:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 01:39:46 +0000
Subject: [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361583586.25.0.377677290242.issue17259@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

When I wrote my previous message, I was reading the link above and did not notice that it want to the old 2.7 docs. The 3.x entry is fine.

Perhaps 6.1.3.1. Format Specification Mini-Language could end with
  Rounding of floats is the same as for round().
under the box, with 'round()' linked to its entry.

>From what you said, % does half to even on my system only because that is what MC VC10 does. 4.7.2. printf-style String Formatting could add "Rounding is system dependent" as note 6 (currently missing!).

I removed 2.7 because is seems like a mess and mostly does not use the new rule. But from what you say, only round() itself is different. 'Half-away-from-0' could be added, with a note about changing in py 3.
The note for .format would have to give the rule rather than refer to round(). Did I get it all right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Sat Feb 23 02:43:34 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 01:43:34 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361583814.12.0.571530278531.issue17273@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Arun, can you suggest a sentence to add and where to add it?

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Sat Feb 23 03:56:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 02:56:03 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <3ZCYvk2dHyzRVk@mail.python.org>


Roundup Robot added the comment:

New changeset ad0712f4b3e0 by Ezio Melotti in branch '2.7':
#15438: add a note to math.pow() that suggests using **/pow() for integers.  Patch by Mark Dickinson.
http://hg.python.org/cpython/rev/ad0712f4b3e0

New changeset 7d95a0aa6b5a by Ezio Melotti in branch '3.2':
#15438: add a note to math.pow() that suggests using **/pow() for integers.  Patch by Mark Dickinson.
http://hg.python.org/cpython/rev/7d95a0aa6b5a

New changeset a305901366a6 by Ezio Melotti in branch '3.3':
#15438: merge with 3.2.
http://hg.python.org/cpython/rev/a305901366a6

New changeset e0f940829eb6 by Ezio Melotti in branch 'default':
#15438: merge with 3.3.
http://hg.python.org/cpython/rev/e0f940829eb6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sat Feb 23 03:56:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 02:56:51 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1361588211.26.0.579135878297.issue15438@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sat Feb 23 04:16:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 03:16:54 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
	interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1361589414.4.0.837909772158.issue2704@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
_______________________________________

From report at bugs.python.org  Sat Feb 23 04:22:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 03:22:12 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361589732.69.0.403804531671.issue17223@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Shouldn't this still work on 3.3/3.4?

In Modules/arraymodule.c:1562, in the array_tounicode function, there is:

return PyUnicode_FromUnicode((Py_UNICODE *) self->ob_item, Py_SIZE(self));

I think this should be updated to work with the PEP 393 implementation, rather than raising an error.

----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Sat Feb 23 04:36:02 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 23 Feb 2013 03:36:02 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361590562.84.0.684604625875.issue17277@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Xavier, could you possibly provide a patch and a test?

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Sat Feb 23 04:39:48 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 23 Feb 2013 03:39:48 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1361553967.12.0.844287227501.issue16123@psf.upfronthosting.co.za>
Message-ID: <CAExgZOhUp4_tRoovN+KdxYbF4xw1rh97NU8C7axttgbWf9G1eQ@mail.gmail.com>


Ramchandra Apte added the comment:

On 22 February 2013 22:56, Raymond Hettinger <report at bugs.python.org> wrote:

>
> Raymond Hettinger added the comment:
>
> The issue is usually with firewalls, security software, socket issues,
> etc.  While the root problem lies outside IDLE, often the simplest way to
> get someone up and running is to use the -n option.
>
> This is one of many annoyances that arise when teaching students Python
> using IDLE:
> * Preferences window crashing
> * Default font-size on a retina mac is tiny
> * Inability to shutoff the prominent warning messages
> * Control-A goes to the beginning of the line, past the >>> prompt.
> * On Windows, IDLE sometimes has a two second delay before it runs scripts
> * Students find that IDLE mysteriously pastes a clipboard into the
> interactive prompt unintentionally
> * It is a common complaint that IDLE hangs
> * Getting the correct Tcl/Tk setup on Macs is problematic.
> * Starting IDLE from the command line emits messages about "setCanCycle is
> deprecated"
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16123>
> _______________________________________
>

Not experienced any of the problems on Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Sat Feb 23 04:46:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 03:46:18 +0000
Subject: [issue16123] IDLE - deprecate running without a subprocess
In-Reply-To: <1349302429.82.0.0807471180715.issue16123@psf.upfronthosting.co.za>
Message-ID: <1361591178.63.0.519776717668.issue16123@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Roger has submitted patches for some of the items on your list (off topic for this issue), especially crashes and stalls. Some still need review and commits. Mac tends to be the most difficult platform to get tests on.

While these would be better discussed on other issues or on idle-sig (mirrored on gmane), I will briefly comment on a few.

Cntl-A selects the entire window on Windows, while Home sends the cursor to the beginning of the line. On the current command line, it first goes after the prompt, and alternates before and after with repetition. This is kbk's design. On old command lines, it only goes before, and that is a bug to be fixed. I think there is an issue, but cannot find it.

I have never seen unprovoked pasting, nor an unexpected startup delay when running from the editor.

I cannot find 'setCanCycle' in 2.7 or 3.3 Lib/idlelib/*.py and 'deprecated' only appears once, in a comment. I expanded the 'setCanCycle' to the entire cpython repository and still did not find it, so that is a complete mystery.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16123>
_______________________________________

From report at bugs.python.org  Sat Feb 23 04:59:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 03:59:51 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <3ZCbKM0mFNzQhK@mail.python.org>


Roundup Robot added the comment:

New changeset c6ca87fbea39 by Ezio Melotti in branch '2.7':
#17249: convert a test in test_capi to use unittest and reap threads.
http://hg.python.org/cpython/rev/c6ca87fbea39

New changeset 329732a1572f by Ezio Melotti in branch '3.2':
#17249: convert a test in test_capi to use unittest and reap threads.
http://hg.python.org/cpython/rev/329732a1572f

New changeset 81f98372f893 by Ezio Melotti in branch '3.3':
#17249: merge with 3.2.
http://hg.python.org/cpython/rev/81f98372f893

New changeset f716a178b4e1 by Ezio Melotti in branch 'default':
#17249: merge with 3.3.
http://hg.python.org/cpython/rev/f716a178b4e1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Sat Feb 23 05:02:50 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 04:02:50 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <1361592170.57.0.300459838245.issue17249@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the reviews!

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Sat Feb 23 05:53:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 04:53:56 +0000
Subject: [issue17249] reap threads in test_capi
In-Reply-To: <1361329289.06.0.007526267954.issue17249@psf.upfronthosting.co.za>
Message-ID: <3ZCcWl584bzQKr@mail.python.org>


Roundup Robot added the comment:

New changeset 041d0f68c67d by Ezio Melotti in branch '2.7':
#17249: check for the availability of the thread module.
http://hg.python.org/cpython/rev/041d0f68c67d

New changeset 01fdf24c9d75 by Ezio Melotti in branch '3.2':
#17249: check for the availability of the thread module.
http://hg.python.org/cpython/rev/01fdf24c9d75

New changeset eb9edac39751 by Ezio Melotti in branch '3.3':
#17249: null merge.
http://hg.python.org/cpython/rev/eb9edac39751

New changeset cb46ccdc226a by Ezio Melotti in branch 'default':
#17249: null merge.
http://hg.python.org/cpython/rev/cb46ccdc226a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17249>
_______________________________________

From report at bugs.python.org  Sat Feb 23 06:58:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 05:58:43 +0000
Subject: [issue17217] Fix test discovery for test_format.py on Windows
In-Reply-To: <1361055748.87.0.775684522637.issue17217@psf.upfronthosting.co.za>
Message-ID: <3ZCdyV3mw7zPx9@mail.python.org>


Roundup Robot added the comment:

New changeset 831be7dc260a by Ezio Melotti in branch '3.2':
#17217: fix UnicodeEncodeErrors errors in test_format by printing ASCII only.
http://hg.python.org/cpython/rev/831be7dc260a

New changeset 3eb693462891 by Ezio Melotti in branch '3.3':
#17217: merge with 3.2.
http://hg.python.org/cpython/rev/3eb693462891

New changeset 562ba95dd4c9 by Ezio Melotti in branch 'default':
#17217: merge with 3.3.
http://hg.python.org/cpython/rev/562ba95dd4c9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17217>
_______________________________________

From report at bugs.python.org  Sat Feb 23 06:59:23 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 05:59:23 +0000
Subject: [issue17217] Fix test discovery for test_format.py on Windows
In-Reply-To: <1361055748.87.0.775684522637.issue17217@psf.upfronthosting.co.za>
Message-ID: <1361599163.13.0.371254765922.issue17217@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17217>
_______________________________________

From report at bugs.python.org  Sat Feb 23 07:17:04 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 23 Feb 2013 06:17:04 +0000
Subject: [issue1615] descriptor protocol bug
In-Reply-To: <1197576817.5.0.617961278098.issue1615@psf.upfronthosting.co.za>
Message-ID: <1361600224.17.0.149833417113.issue1615@psf.upfronthosting.co.za>


Eric Snow added the comment:

The whole AttributeError gaining an attribute seems impractical, but the second approach still seems reasonable to me.  I've attached a rough patch to demonstrate.  If that looks okay, I can flesh it out.

----------
keywords: +patch
Added file: http://bugs.python.org/file29167/getattr-descriptors.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1615>
_______________________________________

From report at bugs.python.org  Sat Feb 23 07:22:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 06:22:11 +0000
Subject: [issue5979] strptime() gives inconsistent exceptions
In-Reply-To: <1241896450.71.0.860512052019.issue5979@psf.upfronthosting.co.za>
Message-ID: <1361600531.03.0.394584416801.issue5979@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5979>
_______________________________________

From report at bugs.python.org  Sat Feb 23 07:29:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 06:29:30 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <1361600970.61.0.609694298637.issue12749@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tried bigrange.py on 3.3/3.4 and I got:
match 1 passed
match 2 passed
match 3 passed

PEP 393 probably fixed this issue.
I don't think it's worth attempting to backport this on 2.7/3.2, so I'm closing this issue.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sat Feb 23 07:40:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 06:40:52 +0000
Subject: [issue12749] lib re cannot match non-BMP ranges (all versions,
	all builds)
In-Reply-To: <1313336859.29.0.142959598943.issue12749@psf.upfronthosting.co.za>
Message-ID: <3ZCfv80cdfzQZP@mail.python.org>


Roundup Robot added the comment:

New changeset 489cfa062442 by Ezio Melotti in branch '3.3':
#12749: add a test for non-BMP ranges in character classes.
http://hg.python.org/cpython/rev/489cfa062442

New changeset c3a09c535001 by Ezio Melotti in branch 'default':
#12749: merge with 3.3.
http://hg.python.org/cpython/rev/c3a09c535001

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12749>
_______________________________________

From report at bugs.python.org  Sat Feb 23 07:46:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 06:46:54 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1361602014.88.0.289035788014.issue3232@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
type: behavior -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3232>
_______________________________________

From report at bugs.python.org  Sat Feb 23 07:53:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 06:53:08 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1361602388.61.0.730565191321.issue5033@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.3, Python 3.4 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Sat Feb 23 08:27:50 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Sat, 23 Feb 2013 07:27:50 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361604470.1.0.101350406612.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

The latest 2.7 hg still crashes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 08:35:52 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Sat, 23 Feb 2013 07:35:52 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361604952.34.0.656939998244.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

The backtrace:

Thread 0:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8a54e386 __semwait_signal + 10
1   libsystem_c.dylib             	0x00007fff85e30800 nanosleep + 163
2   libsystem_c.dylib             	0x00007fff85e30717 usleep + 54
3   testcrash_python_threadlocal.so	0x00000001002ddd40 test_dealloc + 48
4   python.exe                    	0x00000001000400a9 dict_dealloc + 153 (dictobject.c:1010)
5   python.exe                    	0x00000001000432d3 PyDict_DelItem + 259 (dictobject.c:855)
6   python.exe                    	0x00000001000d7f27 _localdummy_destroyed + 71 (threadmodule.c:585)
7   python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
8   python.exe                    	0x0000000100006e42 PyObject_CallFunctionObjArgs + 370 (abstract.c:2761)
9   python.exe                    	0x000000010006b2e6 PyObject_ClearWeakRefs + 534 (weakrefobject.c:892)
10  python.exe                    	0x00000001000d746b localdummy_dealloc + 27 (threadmodule.c:231)
11  python.exe                    	0x00000001000400a9 dict_dealloc + 153 (dictobject.c:1010)
12  python.exe                    	0x00000001000c003b PyThreadState_Clear + 139 (pystate.c:240)
13  python.exe                    	0x00000001000c02c8 PyInterpreterState_Clear + 56 (pystate.c:104)
14  python.exe                    	0x00000001000c1c68 Py_Finalize + 344 (pythonrun.c:504)
15  python.exe                    	0x00000001000d5891 Py_Main + 3041 (main.c:665)
16  python.exe                    	0x0000000100000a74 start + 52

Thread 1:
0   libsystem_kernel.dylib        	0x00007fff8a54e386 __semwait_signal + 10
1   libsystem_c.dylib             	0x00007fff85e30800 nanosleep + 163
2   libsystem_c.dylib             	0x00007fff85e30717 usleep + 54
3   testcrash_python_threadlocal.so	0x00000001002ddd40 test_dealloc + 48
4   python.exe                    	0x00000001000400a9 dict_dealloc + 153 (dictobject.c:1010)
5   python.exe                    	0x00000001000432d3 PyDict_DelItem + 259 (dictobject.c:855)
6   python.exe                    	0x00000001000d7f27 _localdummy_destroyed + 71 (threadmodule.c:585)
7   python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
8   python.exe                    	0x0000000100006e42 PyObject_CallFunctionObjArgs + 370 (abstract.c:2761)
9   python.exe                    	0x000000010006b2e6 PyObject_ClearWeakRefs + 534 (weakrefobject.c:892)
10  python.exe                    	0x00000001000d746b localdummy_dealloc + 27 (threadmodule.c:231)
11  python.exe                    	0x00000001000400a9 dict_dealloc + 153 (dictobject.c:1010)
12  python.exe                    	0x00000001000c003b PyThreadState_Clear + 139 (pystate.c:240)
13  python.exe                    	0x00000001000d7ec4 t_bootstrap + 372 (threadmodule.c:643)
14  libsystem_c.dylib             	0x00007fff85da6742 _pthread_start + 327
15  libsystem_c.dylib             	0x00007fff85d93181 thread_start + 13

Thread 2:
0   libsystem_kernel.dylib        	0x00007fff8a54e322 __select + 10
1   time.so                       	0x00000001002fb01b time_sleep + 139 (timemodule.c:948)
2   python.exe                    	0x000000010009fcfb PyEval_EvalFrameEx + 18011 (ceval.c:4021)
3   python.exe                    	0x00000001000a30f3 fast_function + 179 (ceval.c:4107)
4   python.exe                    	0x000000010009fdad PyEval_EvalFrameEx + 18189 (ceval.c:4042)
5   python.exe                    	0x00000001000a2fb7 PyEval_EvalCodeEx + 2103 (ceval.c:3253)
6   python.exe                    	0x000000010002f8cb function_call + 347 (funcobject.c:526)
7   python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
8   python.exe                    	0x00000001000a066a PyEval_EvalFrameEx + 20426 (ceval.c:4334)
9   python.exe                    	0x00000001000a30f3 fast_function + 179 (ceval.c:4107)
10  python.exe                    	0x000000010009fdad PyEval_EvalFrameEx + 18189 (ceval.c:4042)
11  python.exe                    	0x00000001000a30f3 fast_function + 179 (ceval.c:4107)
12  python.exe                    	0x000000010009fdad PyEval_EvalFrameEx + 18189 (ceval.c:4042)
13  python.exe                    	0x00000001000a2fb7 PyEval_EvalCodeEx + 2103 (ceval.c:3253)
14  python.exe                    	0x000000010002f8cb function_call + 347 (funcobject.c:526)
15  python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
16  python.exe                    	0x0000000100018b07 instancemethod_call + 439 (classobject.c:2603)
17  python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
18  python.exe                    	0x000000010009aaa4 PyEval_CallObjectWithKeywords + 180 (ceval.c:3891)
19  python.exe                    	0x00000001000d7d96 t_bootstrap + 70 (threadmodule.c:614)
20  libsystem_c.dylib             	0x00007fff85da6742 _pthread_start + 327
21  libsystem_c.dylib             	0x00007fff85d93181 thread_start + 13

Thread 3 Crashed:
0   python.exe                    	0x00000001000a2329 PyEval_EvalFrameEx + 27785 (ceval.c:2995)
1   python.exe                    	0x00000001000a2fb7 PyEval_EvalCodeEx + 2103 (ceval.c:3253)
2   python.exe                    	0x000000010002f8cb function_call + 347 (funcobject.c:526)
3   python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
4   python.exe                    	0x00000001000a066a PyEval_EvalFrameEx + 20426 (ceval.c:4334)
5   python.exe                    	0x00000001000a30f3 fast_function + 179 (ceval.c:4107)
6   python.exe                    	0x000000010009fdad PyEval_EvalFrameEx + 18189 (ceval.c:4042)
7   python.exe                    	0x00000001000a30f3 fast_function + 179 (ceval.c:4107)
8   python.exe                    	0x000000010009fdad PyEval_EvalFrameEx + 18189 (ceval.c:4042)
9   python.exe                    	0x00000001000a2fb7 PyEval_EvalCodeEx + 2103 (ceval.c:3253)
10  python.exe                    	0x000000010002f8cb function_call + 347 (funcobject.c:526)
11  python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
12  python.exe                    	0x0000000100018b07 instancemethod_call + 439 (classobject.c:2603)
13  python.exe                    	0x0000000100006c61 PyObject_Call + 97 (abstract.c:2529)
14  python.exe                    	0x000000010009aaa4 PyEval_CallObjectWithKeywords + 180 (ceval.c:3891)
15  python.exe                    	0x00000001000d7d96 t_bootstrap + 70 (threadmodule.c:614)
16  libsystem_c.dylib             	0x00007fff85da6742 _pthread_start + 327
17  libsystem_c.dylib             	0x00007fff85d93181 thread_start + 13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 08:38:38 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 07:38:38 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1361605118.58.0.563277597269.issue10213@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tried to reproduce the issue and copied /usr/share/zoneinfo/Factory to /etc/localtime as suggested in msg119762.
Only 2.7 and 3.2 are affected:
>>> import time
>>> time.strftime('%Z', time.gmtime(time.time()))
'Local time zone must be set--see zic manual page'

On 3.3+ this return 'GMT':
>>> import time
>>> time.strftime('%Z', time.gmtime(time.time()))
'GMT'

The error comes from the libc strftime:

$ cat tz.c 
#include <stdio.h>
#include <time.h>

int main() {
    int buflen;
    char outbuf[256];
    struct tm *buf;
    time_t curtime;

    time(&curtime);
    buf = localtime(&curtime);
    buflen = strftime(outbuf, 256, "%Z", buf);
    printf("outbuf: %s\nbuflen: %d\n", outbuf, buflen);
    return 0;
}
$ gcc -Wall -Wextra -O -ansi -pedantic tz.c -o tz
$ ./tz 
outbuf: Local time zone must be set--see zic manual page
buflen: 48

There are different possible solutions:
  1) we close the issue as out of date, since it's fixed in 3.3+;
  2) we fix the test on 2.7/3.2 by checking for the error message and raising a SkipTest;
  3) we fix the code on 2.7/3.2 by backporting the 3.3 implementation that returns 'GMT';
  4) we fix the code on 2.7/3.2 by checking for the error message and raising an exception;

----------
components: +Extension Modules
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 3.1
Added file: http://bugs.python.org/file29168/tz.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Sat Feb 23 08:46:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 07:46:00 +0000
Subject: [issue6359] pyexpat.c calls trace function incorrectly for exceptions
In-Reply-To: <1246229003.36.0.107970043042.issue6359@psf.upfronthosting.co.za>
Message-ID: <1361605560.9.0.102415644594.issue6359@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The relevant changesets are 1c26eb768293 and e43126c470a7. See also #534864.

----------
nosy: +Jeremy.Hylton, fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6359>
_______________________________________

From report at bugs.python.org  Sat Feb 23 08:48:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 07:48:10 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1361605690.17.0.268041876675.issue10560@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Is this issue still valid?

----------
nosy: +brian.curtin, ezio.melotti
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sat Feb 23 09:17:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Feb 2013 08:17:58 +0000
Subject: [issue11882] test_imaplib failed on x86 ubuntu
In-Reply-To: <1303242113.82.0.307299264452.issue11882@psf.upfronthosting.co.za>
Message-ID: <1361607477.99.0.296572195388.issue11882@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tried to reproduce the issue and copied /usr/share/zoneinfo/posix/Asia/Calcutta to /etc/localtime as suggested in msg134382, but test_imaplib passes on 2.7/3.2/3.3/3.4.

I wrote a C program to test the output of mktime:
$ cat mk.c 
#include <stdio.h>
#include <time.h>

int main() {
    struct tm buf;
    char outbuf[80];
    time_t tt;
 
    buf.tm_year = 2000-1900;
    buf.tm_mon = 1;
    buf.tm_mday = 1;
    buf.tm_hour = 5;
    buf.tm_min = 30;
    buf.tm_sec = 0;
    buf.tm_wday = 5;
    buf.tm_yday = 1;
    buf.tm_isdst = 0;

    tt = mktime(&buf);
    printf("mktime: %9.1f\n", (double)tt);
    strftime(outbuf, 80, "%c", &buf);
    printf("outbuf: %s\n", outbuf);
    return 0;
}
$ gcc -Wall -Wextra -O -ansi -pedantic mk.c -o mk
$ ./mk 
mktime: 949363200.0
outbuf: Tue Feb  1 05:30:00 2000


Kasun, can you still reproduce the failure?
If so, could you try the attached C program?

----------
nosy: +ezio.melotti
versions: +Python 3.4 -Python 3.1
Added file: http://bugs.python.org/file29169/mk.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11882>
_______________________________________

From report at bugs.python.org  Sat Feb 23 09:24:15 2013
From: report at bugs.python.org (Dan)
Date: Sat, 23 Feb 2013 08:24:15 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1361607855.98.0.644801291496.issue12641@psf.upfronthosting.co.za>


Dan added the comment:

Guys, this looks really bad and inconveniences a lot of users. You install the latest MinGW and Distutils from their default location, try using them on **anything that requires compilation**, and get the cryptic gcc -mno-cygwin error (after having to edit the obscure distutils.cfg, of course).

Aren't Python / distutils supposed to be cross-platform? It's already hard enough to find distutils / pip setup instructions for Windows, shouldn't they at least **work**? After removing -mno-cygwin from cygwincompiler.py, I get another obscure -mdll error. This is ridiculous.

If you can't agree on a patch that detects both new and old compilers, can't you split cygwincompiler.py into several versions, or somehow provide separate mingw32-old and mingw32-new options?

----------
nosy: +danmbox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sat Feb 23 09:58:51 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 23 Feb 2013 08:58:51 +0000
Subject: [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361609931.09.0.348357108806.issue17259@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I've just looked through the code for 2.7. It uses short float repr for both %-formatting and for float.__format__. So they both use Gay's code, and both should work the same as they do in 3.2+. In all cases, round-half-to-even is used.

It's 2.6 that uses the C library to do float formatting (for both %-formatting and float.__format__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Sat Feb 23 10:10:34 2013
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Sat, 23 Feb 2013 09:10:34 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1361610634.33.0.487485571743.issue10213@psf.upfronthosting.co.za>


Dirkjan Ochtman added the comment:

I guess option 3 would be the best (in that people get more usable libraries). Option 2 seems okay as well. I don't much like 1 or 4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Sat Feb 23 11:11:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2013 10:11:47 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361614307.91.0.802196814407.issue17232@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for Remove instead of Removes

For the online docs, :const:`__debug__` should work (resolving to http://docs.python.org/3/library/constants.html#__debug__, which is currently described using some slightly brain-bending phrasing)

We should also tweak the output of "python -h" (the help string is in ./Modules/main.c)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Sat Feb 23 11:12:26 2013
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 23 Feb 2013 10:12:26 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361614346.86.0.398357722385.issue17267@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


----------
nosy: +maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Sat Feb 23 11:30:27 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 10:30:27 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361615427.87.0.143435445319.issue17263@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Alright, here's what's going on.
When the main thread exits, it triggers the interpreter shutdown, which clears all the tstates in PyInterpreterState_Clear():
"""
void
PyInterpreterState_Clear(PyInterpreterState *interp)
{
    PyThreadState *p;
    HEAD_LOCK();
    for (p = interp->tstate_head; p != NULL; p = p->next)
        PyThreadState_Clear(p);
"""

PyThreadState_Clear() clears the TLS dict:
"""
void
PyThreadState_Clear(PyThreadState *tstate)
{
    if (Py_VerboseFlag && tstate->frame != NULL)
        fprintf(stderr,
          "PyThreadState_Clear: warning: thread still has a frame\n");

    Py_CLEAR(tstate->frame);

    Py_CLEAR(tstate->dict);
"""

This deallocation of the TLS dict But when the TLS object is deallocated, if it releases the GIL, this can make other threads runnable, while the interpreter is shutting down (and the tstate are in an unusable state), so all  bets are off. Note that this can only happen if there are daemon threads, which is the case in your testcase.

Basically, the problem is that arbitrary code can be run while the interpreter is shutting down because of the TLS deallocation.

I'm not sure about how to handle it, but one possibility to limit such problems would be to not deallocate the tstate if a thread is currently still active:

"""
diff --git a/Python/pystate.c b/Python/pystate.c
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -230,9 +230,12 @@
 void
 PyThreadState_Clear(PyThreadState *tstate)
 {
-    if (Py_VerboseFlag && tstate->frame != NULL)
-        fprintf(stderr,
-          "PyThreadState_Clear: warning: thread still has a frame\n");
+    if (tstate->frame != NULL) {
+        if (Py_VerboseFlag)
+            fprintf(stderr,
+                    "PyThreadState_Clear: warning: thread still has a frame\n");
+        return;
+    }
 
     Py_CLEAR(tstate->frame);
 
"""

But this would leak to memory leak in some cases...

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 11:38:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 10:38:23 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361615903.66.0.607703989117.issue17263@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Albert, this happens because daemon threads continue running during interpreter shutdown. I suppose the problem goes away if you make the thread non-daemonic?

This shouldn't be a problem in Python 3 where Python threads cannot switch during shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 11:55:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 10:55:38 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361615903.66.0.607703989117.issue17263@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3jroBv5Cm5dD=OgSrsGJtKzZa=2QCvCqwH0kTEcEummw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> This shouldn't be a problem in Python 3 where Python threads cannot switch
> during shutdown.

What happens if the GIL is relased during shutdown?

Also, I'm a bit worried about this code:
"""
void
PyThreadState_Clear(PyThreadState *tstate)
{
    if (Py_VerboseFlag && tstate->frame != NULL)
        fprintf(stderr,
          "PyThreadState_Clear: warning: thread still has a frame\n");

    Py_CLEAR(tstate->frame);

    Py_CLEAR(tstate->dict);
"""

The TLS dict is deallocated after having cleared the frame, which
could lead to surprises, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 11:58:38 2013
From: report at bugs.python.org (Carlo Bramini)
Date: Sat, 23 Feb 2013 10:58:38 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1361617118.13.0.0108750405467.issue10560@psf.upfronthosting.co.za>


Carlo Bramini added the comment:

I have downloaded the latest sources with HG and, with the only exception of the variable "cookie" now conditionally declared with an "#ifdef HAVE_SXS", yes, all these fixes are still actual.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sat Feb 23 12:03:11 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 11:03:11 +0000
Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue
In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za>
Message-ID: <1361617391.04.0.948168118406.issue10886@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

I'm closing, since issue #17025 proposes to do this as part of performance optimization.

----------
nosy: +neologix
status: open -> closed
superseder:  -> reduce multiprocessing.Queue contention

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10886>
_______________________________________

From report at bugs.python.org  Sat Feb 23 12:08:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 11:08:05 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361617685.94.0.43335482387.issue17263@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> What happens if the GIL is relased during shutdown?

In PyEval_RestoreThread(), any thread other than the main thread trying to take the GIL will immediately exit:

        take_gil(tstate);
        if (_Py_Finalizing && tstate != _Py_Finalizing) {
            drop_gil(tstate);
            PyThread_exit_thread();
            assert(0);  /* unreachable */
        }

> The TLS dict is deallocated after having cleared the frame, which
> could lead to surprises, no?

I don't know. Can you think of a situation where there is a problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 13:16:50 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 23 Feb 2013 12:16:50 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1361621810.68.0.362248620234.issue10560@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

yes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sat Feb 23 13:40:08 2013
From: report at bugs.python.org (Roumen Petrov)
Date: Sat, 23 Feb 2013 12:40:08 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1361607855.98.0.644801291496.issue12641@psf.upfronthosting.co.za>
Message-ID: <5128B8A6.7010908@roumenpetrov.info>


Roumen Petrov added the comment:

> Dan added the comment:
>
> Guys, this looks really bad and inconveniences a lot of users. You install the latest MinGW and Distutils from their default location, try using them on **anything that requires compilation**, and get the cryptic gcc -mno-cygwin error (after having to edit the obscure distutils.cfg, of course).
>
> Aren't Python / distutils supposed to be cross-platform? It's already hard enough to find distutils / pip setup instructions for Windows, shouldn't they at least **work**? After removing -mno-cygwin from cygwincompiler.py, I get another obscure -mdll error. This is ridiculous.
Yes . This is reason to pack many changes in one archive 
"issue12641-modernize_cygwin&mingw_compilers.tar.gz 
<http://bugs.python.org/file29030/issue12641-modernize_cygwin%26mingw_compilers.tar.gz>", 
i.e. to remove all checks for tools used in previous mill?nium.

My oldest compilers are :
a)
i386-mingw32msvc-gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
b)
gcc.exe (GCC) 3.4.5 (mingw-vista special r3)
Copyright (C) 2004 Free Software Foundation, Inc.

Check for -m{no-}cygwin flags is optional. I can not found reason this 
patch to be applied, as with implementation of compiler customization 
this is for developer guide.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sat Feb 23 13:59:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 12:59:56 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1361624396.92.0.226136211238.issue5033@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/issue5033>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:20:00 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Feb 2013 13:20:00 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361625600.43.0.749393200519.issue17232@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

+1, I've been bothered by this description of "optimization" for a long time. 

Terry's patch LGTM

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:21:24 2013
From: report at bugs.python.org (Alex)
Date: Sat, 23 Feb 2013 13:21:24 +0000
Subject: [issue17280] path.basename and ntpath.basename functions returns an
	incorrect file name in Windows 7
Message-ID: <1361625684.2.0.806923079144.issue17280@psf.upfronthosting.co.za>


New submission from Alex:

1. I created file ("C:\Users\Alkor\Desktop\a3434.raw") on my desktop 
2. Tried to get the file name from the absolute path

Actual result:
C:\Users\Alkor>python
Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> print os.path.basename ("C:\Users\Alkor\Desktop\a3434.raw")
Desktop3434.raw

The same for ntpath module:
>>> import ntpath
>>> print ntpath.basename ("C:\Users\Alkor\Desktop\a3434.raw")
Desktop3434.raw

Expected result:
a3434.raw

Environment:
Windows 7 x64 SP1 Ultimate
python 2.7.3150 (64-bit)

----------
components: Windows
messages: 182739
nosy: Ternovoy, brian.curtin, loewis, tim.golden
priority: normal
severity: normal
status: open
title: path.basename and ntpath.basename functions returns an incorrect file name in Windows 7
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17280>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:23:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Feb 2013 13:23:42 +0000
Subject: [issue17280] path.basename and ntpath.basename functions returns an
	incorrect file name in Windows 7
In-Reply-To: <1361625684.2.0.806923079144.issue17280@psf.upfronthosting.co.za>
Message-ID: <1361625822.13.0.0245971695392.issue17280@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> print os.path.basename ("C:\Users\Alkor\Desktop\a3434.raw")

Ah, it's a common trap of the Python syntax (and PHP, and C, and ... languages). "\" is a special character, you have to escape it: "\\".

"C:\\Users\\Alkor\\Desktop\\a3434.raw"

or simply use the "raw" string syntax:

r"C:\Users\Alkor\Desktop\a3434.raw"

----------
nosy: +haypo
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17280>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:25:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Feb 2013 13:25:58 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1361625958.96.0.656942756626.issue10560@psf.upfronthosting.co.za>


STINNER Victor added the comment:

-    HINSTANCE hKernel32 = GetModuleHandleW(L"kernel32.dll");
+    HINSTANCE hKernel32 = GetModuleHandle(TEXT("KERNEL32"));

I prefer to be explicit and force the usage of the wide character API, espacially in Python 3.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:34:48 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Sat, 23 Feb 2013 13:34:48 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361626488.18.0.0987623061956.issue17232@psf.upfronthosting.co.za>


Maciej Fijalkowski added the comment:

Also IMO -OO should stop talking about optimizations. Maybe "Do what -O does and discard docstrings"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:37:01 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 23 Feb 2013 13:37:01 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
	interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1361626621.41.0.706713509403.issue2704@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

+1000

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
_______________________________________

From report at bugs.python.org  Sat Feb 23 14:59:12 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Feb 2013 13:59:12 +0000
Subject: [issue15438] document that math.pow is inappropriate for integers
In-Reply-To: <1343127470.28.0.0904481675827.issue15438@psf.upfronthosting.co.za>
Message-ID: <1361627952.86.0.144034451583.issue15438@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks, Ezio;  I didn't get around to dealing with this as quickly as I meant to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15438>
_______________________________________

From report at bugs.python.org  Sat Feb 23 15:22:20 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Sat, 23 Feb 2013 14:22:20 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361629340.56.0.980017692694.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Note that in my original application where I encountered this (with sqlite), the backtrace looks slightly different. It is at shutdown, but not at interpreter shutdown - the main thread is still running.

https://github.com/albertz/music-player/issues/23

I was trying to reproduce it in a similar way with this test case but in the test case, so far I could only reproduce the crash when it does the interpreter shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 15:34:38 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 23 Feb 2013 14:34:38 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361630078.19.0.105269888369.issue17277@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch (on the default branch) reverts one of the changes made in r72488 to
introduce the new PyFrame_GetLineNumber() function (issue 5954): tb_lineno is
now back again the result of the call to PyCode_Addr2Line() instead of the
call to PyFrame_GetLineNumber().

The other changes made by r72488 in _warnings.c and ceval.c should also
probably be reverted as well.

The patch updates bdb set_continue() for consistency.

The patch adds a test to test_sys_settrace.

----------
keywords: +patch
Added file: http://bugs.python.org/file29170/backtrace_lno.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Sat Feb 23 15:43:55 2013
From: report at bugs.python.org (Kevin Lyda)
Date: Sat, 23 Feb 2013 14:43:55 +0000
Subject: [issue17281] Broken links at pypi
Message-ID: <1361630635.92.0.90935154891.issue17281@psf.upfronthosting.co.za>


New submission from Kevin Lyda:

The pypi entry for distutils2 has a comical set of broken links (docs and contributing): https://pypi.python.org/pypi/Distutils2

The following two paragraphs have broken links. Adding a link checker to your browser isn't the worst idea.

The Distutils2 codebase is a fork of Distutils. It is not backward compatible with Distutils and does not depend on it. It provides more features and implements new packaging standards. In Python 3.3, Distutils2 is included in the standard library under the module name "packaging". Documentation is provided at http://docs.python.org/dev/packaging 404 --for ease of maintenance, it is not duplicated in this repository. You can use the Packaging documentation to use Distutils2; only the package name is different (packaging vs. distutils2), all modules, classes and functions have the same name.

If you want to contribute, please have a look at DEVNOTES.txt or http://wiki.python.org/Distutils2/Contributing 404 .

----------
assignee: eric.araujo
components: Distutils2
messages: 182747
nosy: alexis, eric.araujo, lyda, tarek
priority: normal
severity: normal
status: open
title: Broken links at pypi
type: behavior
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17281>
_______________________________________

From report at bugs.python.org  Sat Feb 23 15:53:29 2013
From: report at bugs.python.org (Andreas Pelme)
Date: Sat, 23 Feb 2013 14:53:29 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1361631209.9.0.903911295187.issue5033@psf.upfronthosting.co.za>


Andreas Pelme added the comment:

This bug still exists in 2.7 and 3.4.

If SQLITE_VERSION in sqlite3.h (/usr/include/sqlite3.h on Mac OS) ends with beta, such as
 
#define SQLITE_VERSION        "3.7.12beta"

make will fail.

The regex changed suggested above fixes this. The attached patch contains that fix and makes the build work.

----------
keywords: +patch
nosy: +Andreas.Pelme
Added file: http://bugs.python.org/file29171/issue5033.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Sat Feb 23 16:06:48 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 15:06:48 +0000
Subject: [issue16695] Clarify fnmatch & glob docs about the handling of
	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <1361632008.92.0.462129913634.issue16695@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

I modified the docstring for the glob and iglob to note that the match does not work exactly like fnmatch.

Should this be extended to the documentation too?

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file29172/issue16695.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16695>
_______________________________________

From report at bugs.python.org  Sat Feb 23 16:19:21 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 23 Feb 2013 15:19:21 +0000
Subject: [issue17280] path.basename and ntpath.basename functions returns an
	incorrect file name in Windows 7
In-Reply-To: <1361625684.2.0.806923079144.issue17280@psf.upfronthosting.co.za>
Message-ID: <1361632761.48.0.364817534968.issue17280@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17280>
_______________________________________

From report at bugs.python.org  Sat Feb 23 16:32:12 2013
From: report at bugs.python.org (=?utf-8?q?Andreas_=C3=85kerlund?=)
Date: Sat, 23 Feb 2013 15:32:12 +0000
Subject: [issue900112] cgi.fieldStorage doesn't grok standards env. variables
Message-ID: <1361633532.11.0.241642124655.issue900112@psf.upfronthosting.co.za>


Andreas ?kerlund added the comment:

Submited a patch against 2.7 that adds all environment variables starting with "HTTP_", strips of the prefix and converts it to lower case. Also added a small test case.

----------
keywords: +patch
nosy: +thezulk
Added file: http://bugs.python.org/file29173/issue900112.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue900112>
_______________________________________

From report at bugs.python.org  Sat Feb 23 16:40:24 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 15:40:24 +0000
Subject: [issue16403] update distutils docs to say that maintainer replaces
	author
In-Reply-To: <1352029026.5.0.383021349699.issue16403@psf.upfronthosting.co.za>
Message-ID: <1361634024.97.0.430517982846.issue16403@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Added a patch with documentation change

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file29174/issue16403.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16403>
_______________________________________

From report at bugs.python.org  Sat Feb 23 16:44:27 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 15:44:27 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361634267.12.0.946344773326.issue15305@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Simplify to single build/test directory, and disambiguate by TEMPFN.

Test suite run on Mac OS X (./python.exe -m test -j3) without error. Some files created by tests do not use TESTFN, so may have build bots identify issues.

----------
keywords: +patch
nosy: +gmwils
Added file: http://bugs.python.org/file29175/Issue15305.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Sat Feb 23 16:50:45 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 15:50:45 +0000
Subject: [issue16695] Clarify fnmatch & glob docs about the handling of
	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <1361634645.54.0.604313165634.issue16695@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Added documentation changes to the glob documentation too, not only docstring.

----------
Added file: http://bugs.python.org/file29176/issue16695_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16695>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:02:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Feb 2013 16:02:19 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361635339.71.0.508079880293.issue16801@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note: Nick Coghlan's idea of having Named Value support in Python just came up again on python-dev, and this would be a perfect application for it (pretty much exactly Terry's proposal in msg178542).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:25:09 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Sat, 23 Feb 2013 16:25:09 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1361636709.86.0.671719379015.issue17117@psf.upfronthosting.co.za>


G?k?en Eraslan added the comment:

The patch is attached. Is it correct?

----------
keywords: +patch
nosy: +G?k?en.Eraslan
Added file: http://bugs.python.org/file29177/python-issue-17117.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17117>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:28:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 16:28:34 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <3ZCvxF4R6zzSh9@mail.python.org>


Roundup Robot added the comment:

New changeset 8b177aea9ddd by Petri Lehtinen in branch '2.7':
Issue #5033: Fix building of the sqlite3 extension module
http://hg.python.org/cpython/rev/8b177aea9ddd

New changeset 73d5dd480558 by Petri Lehtinen in branch '3.2':
Issue #5033: Fix building of the sqlite3 extension module
http://hg.python.org/cpython/rev/73d5dd480558

New changeset c613eb716c8e by Petri Lehtinen in branch '3.3':
Issue #5033: Fix building of the sqlite3 extension module
http://hg.python.org/cpython/rev/c613eb716c8e

New changeset 19b3aaf79e45 by Petri Lehtinen in branch 'default':
Issue #5033: Fix building of the sqlite3 extension module
http://hg.python.org/cpython/rev/19b3aaf79e45

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:29:20 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 16:29:20 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1361636960.84.0.281690252659.issue5033@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
nosy: +petri.lehtinen
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:35:46 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 23 Feb 2013 16:35:46 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361637346.0.0.260903727805.issue16801@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:45:05 2013
From: report at bugs.python.org (Martin Melin)
Date: Sat, 23 Feb 2013 16:45:05 +0000
Subject: [issue1375011] Improper handling of duplicate cookies
Message-ID: <1361637905.61.0.303579463648.issue1375011@psf.upfronthosting.co.za>


Martin Melin added the comment:

Attached is a patch with Viraj's original fix except using a set instead of a dict as suggested by Bj?rn. This patch also includes a test case and a note in the docs about this behavior.

Since Cookie has been moved and the code has been cleaned up somewhat between 2.7 and 3.2 I'm attaching patches for both branches.

Of course, a decision still needs to be made whether or not this should be applied; the behavior is more correct now, but I don't know if it is worth potentially breaking applications that have come to expect the old behavior. There doesn't seem to be a consensus in #1372650 but I thought having a complete patch would be a good thing regardless.

----------
nosy: +mmelin
Added file: http://bugs.python.org/file29178/issue1375011-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1375011>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:45:57 2013
From: report at bugs.python.org (Martin Melin)
Date: Sat, 23 Feb 2013 16:45:57 +0000
Subject: [issue1375011] Improper handling of duplicate cookies
Message-ID: <1361637957.2.0.996255298669.issue1375011@psf.upfronthosting.co.za>


Martin Melin added the comment:

Just adding the 3.2 patch

----------
Added file: http://bugs.python.org/file29179/issue1375011-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1375011>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:47:27 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 16:47:27 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361629340.56.0.980017692694.issue17263@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3F4PaC-_4m8NarQATVAPCu7Vp9o20HbseCq31+2N+GrA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Note that in my original application where I encountered this (with sqlite), the backtrace looks slightly different. It is at shutdown, but not at interpreter shutdown - the main thread is still running.

Could you post a traceback of this crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:56:00 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Sat, 23 Feb 2013 16:56:00 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361638560.37.0.941242004655.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Here is one. Others are in the issue report on GitHub.

In Thread 5, the PyObject_SetAttr is where some attribute containing a threading.local object is set to None. This threading.local object had a reference to a sqlite connection object (in some TLS contextes). This should also be the actual crashing thread. I use faulthandler which makes it look like Thread 0 crashed in the crash reporter.

I had this crash about 5% of the time - but totally unpredictable. But it was always happening in exactly that line where the attribute was set to None.


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff8a54e0fa __psynch_cvwait + 10
1   libsystem_c.dylib               0x00007fff85daaf89 _pthread_cond_wait + 869
2   org.python.python               0x000000010006f54e PyThread_acquire_lock + 96
3   org.python.python               0x000000010001d8e3 PyEval_RestoreThread + 61
4   org.python.python               0x0000000100075bf3 0x100009000 + 445427
5   org.python.python               0x0000000100020041 PyEval_EvalFrameEx + 7548
6   org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
7   org.python.python               0x0000000100024661 0x100009000 + 112225
8   org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
9   org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
10  org.python.python               0x0000000100024661 0x100009000 + 112225
11  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
12  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
13  org.python.python               0x000000010005df78 0x100009000 + 348024
14  org.python.python               0x000000010001caba PyObject_Call + 97
15  _objc.so                        0x0000000104615898 0x104600000 + 88216
16  libffi.dylib                    0x00007fff8236e8a6 ffi_closure_unix64_inner + 508
17  libffi.dylib                    0x00007fff8236df66 ffi_closure_unix64 + 70
18  com.apple.AppKit                0x00007fff84f63f3f -[NSApplication _docController:shouldTerminate:] + 75
19  com.apple.AppKit                0x00007fff84f63e4e __91-[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:]_block_invoke_0 + 159
20  com.apple.AppKit                0x00007fff84f63cea -[NSDocumentController(NSInternal) _closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 1557
21  com.apple.AppKit                0x00007fff84f636ae -[NSDocumentController(NSInternal) __closeAllDocumentsWithDelegate:shouldTerminateSelector:] + 265
22  com.apple.AppKit                0x00007fff84f6357f -[NSApplication _shouldTerminate] + 772
23  com.apple.AppKit                0x00007fff84f9134f -[NSApplication(NSAppleEventHandling) _handleAEQuit] + 403
24  com.apple.AppKit                0x00007fff84d40261 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 660
25  com.apple.Foundation            0x00007fff867e112b -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 308
26  com.apple.Foundation            0x00007fff867e0f8d _NSAppleEventManagerGenericHandler + 106
27  com.apple.AE                    0x00007fff832eeb48 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 307
28  com.apple.AE                    0x00007fff832ee9a9 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 37
29  com.apple.AE                    0x00007fff832ee869 aeProcessAppleEvent + 318
30  com.apple.HIToolbox             0x00007fff8e19f8e9 AEProcessAppleEvent + 100
31  com.apple.AppKit                0x00007fff84d3c916 _DPSNextEvent + 1456
32  com.apple.AppKit                0x00007fff84d3bed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
33  com.apple.AppKit                0x00007fff84d33283 -[NSApplication run] + 517
34  libffi.dylib                    0x00007fff8236dde4 ffi_call_unix64 + 76
35  libffi.dylib                    0x00007fff8236e619 ffi_call + 853
36  _objc.so                        0x000000010461a663 PyObjCFFI_Caller + 1980
37  _objc.so                        0x000000010462f43e 0x104600000 + 193598
38  org.python.python               0x000000010001caba PyObject_Call + 97
39  org.python.python               0x0000000100020225 PyEval_EvalFrameEx + 8032
40  org.python.python               0x00000001000245eb 0x100009000 + 112107
41  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
42  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
43  org.python.python               0x000000010001dad7 PyEval_EvalCode + 54
44  org.python.python               0x0000000100054933 0x100009000 + 309555
45  org.python.python               0x00000001000549ff PyRun_FileExFlags + 165
46  org.python.python               0x00000001000543e9 PyRun_SimpleFileExFlags + 410
47  albertzeyer.MusicPlayer         0x0000000100001f54 main + 682 (main.m:67)
48  albertzeyer.MusicPlayer         0x0000000100001c6d _start + 203
49  albertzeyer.MusicPlayer         0x0000000100001ba1 start + 33


Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib          0x00007fff8a54ed16 kevent + 10
1   libdispatch.dylib               0x00007fff88230dea _dispatch_mgr_invoke + 883
2   libdispatch.dylib               0x00007fff882309ee _dispatch_mgr_thread + 54

Thread 2:
0   libsystem_kernel.dylib          0x00007fff8a54e0fa __psynch_cvwait + 10
1   libsystem_c.dylib               0x00007fff85daaf89 _pthread_cond_wait + 869
2   org.python.python               0x000000010006f54e PyThread_acquire_lock + 96
3   org.python.python               0x000000010001d8e3 PyEval_RestoreThread + 61
4   _sqlite3.so                     0x000000010a4041f1 pysqlite_connection_dealloc + 76
5   org.python.python               0x00000001000729f3 0x100009000 + 432627
6   org.python.python               0x00000001000729f3 0x100009000 + 432627
7   org.python.python               0x0000000100052b55 PyThreadState_Clear + 136
8   org.python.python               0x000000010007610a 0x100009000 + 446730
9   libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
10  libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

Thread 3:
0   libsystem_kernel.dylib          0x00007fff8a54e0fa __psynch_cvwait + 10
1   libsystem_c.dylib               0x00007fff85daaf89 _pthread_cond_wait + 869
2   org.python.python               0x000000010006f54e PyThread_acquire_lock + 96
3   org.python.python               0x000000010001d8e3 PyEval_RestoreThread + 61
4   _objc.so                        0x00000001046234a3 0x104600000 + 144547
5   org.python.python               0x00000001000a4194 0x100009000 + 635284
6   org.python.python               0x0000000100021a49 PyEval_EvalFrameEx + 14212
7   org.python.python               0x00000001000245eb 0x100009000 + 112107
8   org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
9   org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
10  org.python.python               0x000000010005df78 0x100009000 + 348024
11  org.python.python               0x000000010001caba PyObject_Call + 97
12  org.python.python               0x000000010001ec59 PyEval_EvalFrameEx + 2452
13  org.python.python               0x00000001000245eb 0x100009000 + 112107
14  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
15  org.python.python               0x00000001000245eb 0x100009000 + 112107
16  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
17  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
18  org.python.python               0x000000010005df78 0x100009000 + 348024
19  org.python.python               0x000000010001caba PyObject_Call + 97
20  org.python.python               0x000000010003719a 0x100009000 + 188826
21  org.python.python               0x000000010001caba PyObject_Call + 97
22  org.python.python               0x0000000100023dfc PyEval_CallObjectWithKeywords + 177
23  org.python.python               0x0000000100076010 0x100009000 + 446480
24  libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
25  libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

Thread 4:
0   libsystem_kernel.dylib          0x00007fff8a54e0fa __psynch_cvwait + 10
1   libsystem_c.dylib               0x00007fff85daaf89 _pthread_cond_wait + 869
2   org.python.python               0x000000010006f54e PyThread_acquire_lock + 96
3   org.python.python               0x000000010001d8e3 PyEval_RestoreThread + 61
4   org.python.python               0x0000000100053351 PyGILState_Ensure + 93
5   _objc.so                        0x0000000104609b6e 0x104600000 + 39790
6   libobjc.A.dylib                 0x00007fff880c6230 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464
7   com.apple.CoreFoundation        0x00007fff8ec15342 _CFAutoreleasePoolPop + 34
8   com.apple.Foundation            0x00007fff867e003d -[NSAutoreleasePool release] + 154
9   com.apple.CoreFoundation        0x00007fff8ebed85a CFRelease + 170
10  _objc.so                        0x000000010462349b 0x104600000 + 144539
11  org.python.python               0x00000001000a4194 0x100009000 + 635284
12  org.python.python               0x0000000100021a49 PyEval_EvalFrameEx + 14212
13  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
14  org.python.python               0x0000000100024661 0x100009000 + 112225
15  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
16  org.python.python               0x00000001000245eb 0x100009000 + 112107
17  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
18  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
19  org.python.python               0x000000010005df78 0x100009000 + 348024
20  org.python.python               0x000000010001caba PyObject_Call + 97
21  org.python.python               0x000000010001ec59 PyEval_EvalFrameEx + 2452
22  org.python.python               0x00000001000245eb 0x100009000 + 112107
23  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
24  org.python.python               0x00000001000245eb 0x100009000 + 112107
25  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
26  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
27  org.python.python               0x000000010005df78 0x100009000 + 348024
28  org.python.python               0x000000010001caba PyObject_Call + 97
29  org.python.python               0x000000010003719a 0x100009000 + 188826
30  org.python.python               0x000000010001caba PyObject_Call + 97
31  org.python.python               0x0000000100023dfc PyEval_CallObjectWithKeywords + 177
32  org.python.python               0x0000000100076010 0x100009000 + 446480
33  libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
34  libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

Thread 5:
0   org.python.python               0x000000010007575e 0x100009000 + 444254
1   org.python.python               0x0000000100071cbe 0x100009000 + 429246
2   org.python.python               0x0000000100071bcd PyDict_SetItem + 145
3   org.python.python               0x0000000100079a55 PyObject_GenericSetAttr + 327
4   org.python.python               0x0000000100079538 PyObject_SetAttr + 157
5   org.python.python               0x000000010001f303 PyEval_EvalFrameEx + 4158
6   org.python.python               0x00000001000245eb 0x100009000 + 112107
7   org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
8   org.python.python               0x00000001000245eb 0x100009000 + 112107
9   org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
10  org.python.python               0x00000001000245eb 0x100009000 + 112107
11  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
12  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
13  org.python.python               0x000000010005df78 0x100009000 + 348024
14  org.python.python               0x000000010001caba PyObject_Call + 97
15  org.python.python               0x000000010001ec59 PyEval_EvalFrameEx + 2452
16  org.python.python               0x00000001000245eb 0x100009000 + 112107
17  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
18  org.python.python               0x00000001000245eb 0x100009000 + 112107
19  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
20  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
21  org.python.python               0x000000010005df78 0x100009000 + 348024
22  org.python.python               0x000000010001caba PyObject_Call + 97
23  org.python.python               0x000000010003719a 0x100009000 + 188826
24  org.python.python               0x000000010001caba PyObject_Call + 97
25  org.python.python               0x0000000100023dfc PyEval_CallObjectWithKeywords + 177
26  org.python.python               0x0000000100076010 0x100009000 + 446480
27  libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
28  libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

Thread 6:
0   libsystem_kernel.dylib          0x00007fff8a54e386 __semwait_signal + 10
1   libsystem_c.dylib               0x00007fff85e30800 nanosleep + 163
2   libsystem_c.dylib               0x00007fff85e30717 usleep + 54
3   ffmpeg.so                       0x000000010bd7609d PlayerObject::workerProc(PyMutex&, bool&) + 509 (ffmpeg_player_decoding.cpp:1087)
4   ffmpeg.so                       0x000000010bd78ac2 boost::function2<void, PyMutex&, bool&>::operator()(PyMutex&, bool&) const + 28 (function_template.hpp:759)
5   ffmpeg.so                       0x000000010bd78736 PyThread_thread(void*) + 25 (ffmpeg_utils.cpp:98)
6   libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
7   libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

Thread 7:
0   libsystem_kernel.dylib          0x00007fff8a54e322 __select + 10
1   time.so                         0x00000001007f9d83 0x1007f9000 + 3459
2   org.python.python               0x0000000100020041 PyEval_EvalFrameEx + 7548
3   org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
4   org.python.python               0x000000010005df78 0x100009000 + 348024
5   org.python.python               0x000000010001caba PyObject_Call + 97
6   org.python.python               0x000000010001ec59 PyEval_EvalFrameEx + 2452
7   org.python.python               0x00000001000245eb 0x100009000 + 112107
8   org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
9   org.python.python               0x00000001000245eb 0x100009000 + 112107
10  org.python.python               0x00000001000200d2 PyEval_EvalFrameEx + 7693
11  org.python.python               0x000000010001e281 PyEval_EvalCodeEx + 1956
12  org.python.python               0x000000010005df78 0x100009000 + 348024
13  org.python.python               0x000000010001caba PyObject_Call + 97
14  org.python.python               0x000000010003719a 0x100009000 + 188826
15  org.python.python               0x000000010001caba PyObject_Call + 97
16  org.python.python               0x0000000100023dfc PyEval_CallObjectWithKeywords + 177
17  org.python.python               0x0000000100076010 0x100009000 + 446480
18  libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
19  libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

Thread 8:: com.apple.audio.IOThread.client
0   libsystem_kernel.dylib          0x00007fff8a54c686 mach_msg_trap + 10
1   libsystem_kernel.dylib          0x00007fff8a54bc42 mach_msg + 70
2   com.apple.audio.CoreAudio       0x00007fff825a117a HALB_MachPort::SendMessageWithReply(unsigned int, unsigned int, unsigned int, unsigned int, mach_msg_header_t*, bool, unsigned int) + 98
3   com.apple.audio.CoreAudio       0x00007fff825a1108 HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 42
4   com.apple.audio.CoreAudio       0x00007fff8259f8db HALC_ProxyIOContext::IOWorkLoop() + 1209
5   com.apple.audio.CoreAudio       0x00007fff8259f391 HALC_ProxyIOContext::IOThreadEntry(void*) + 83
6   com.apple.audio.CoreAudio       0x00007fff8259f24b HALB_IOThread::Entry(void*) + 75
7   libsystem_c.dylib               0x00007fff85da6742 _pthread_start + 327
8   libsystem_c.dylib               0x00007fff85d93181 thread_start + 13

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:56:54 2013
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Skoglund?=)
Date: Sat, 23 Feb 2013 16:56:54 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1361638614.52.0.338591689494.issue17130@psf.upfronthosting.co.za>


Bj?rn Skoglund added the comment:

Hello, first patch, be kind.

I opted for option 2 so there is top keywords filename_ and sort_ filtered out before calling func.

The test in test_profile seems to call runctx but runcall and run are never tested. Not sure if this is missing or intended.

----------
keywords: +patch
nosy: +bjorns
Added file: http://bugs.python.org/file29180/issue17130.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:58:31 2013
From: report at bugs.python.org (Hugo Hallman)
Date: Sat, 23 Feb 2013 16:58:31 +0000
Subject: [issue8489] Support UTF8SMTP as part of RFC 5336 in smptlib
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1361638711.54.0.422345630539.issue8489@psf.upfronthosting.co.za>


Hugo Hallman added the comment:

Can not reproduce the problem in 2.7
Attaching a patch with test cases proving that the problem is solved.
Patch based on current tip 2.7.

----------
keywords: +patch
nosy: +hhallman
Added file: http://bugs.python.org/file29181/issue8489.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Sat Feb 23 17:59:22 2013
From: report at bugs.python.org (Martin Melin)
Date: Sat, 23 Feb 2013 16:59:22 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1361638762.23.0.685968937195.issue7504@psf.upfronthosting.co.za>


Martin Melin added the comment:

FYI, this looks like the same issue as #1375011

----------
nosy: +mmelin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:00:03 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 17:00:03 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361638560.37.0.941242004655.issue17263@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1XCB2Ee_zRu=YGx2nu-GvnnBe3nEV47OtWQkb2Xa6BDg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Here is one. Others are in the issue report on GitHub.

Yes, I've seen it, but I'd need a backtrace with line numbers (like
the one you posted above).
thread 5 is crashing, but I don't know where.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:00:48 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 17:00:48 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361638848.11.0.0202081683166.issue11671@psf.upfronthosting.co.za>


Devin Cook added the comment:

Should now be compliant with this part of the spec:

"Each header_value must not include any control characters, including carriage returns or linefeeds, either embedded or at the end. (These requirements are to minimize the complexity of any parsing that must be performed by servers, gateways, and intermediate response processors that need to inspect or modify response headers.)"

----------
keywords: +patch
nosy: +devin
Added file: http://bugs.python.org/file29182/header_newlines.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:06:22 2013
From: report at bugs.python.org (Andreas Pelme)
Date: Sat, 23 Feb 2013 17:06:22 +0000
Subject: [issue17176] Document imp.NullImporter is NOT used anymore by import
In-Reply-To: <1360525827.54.0.547409827798.issue17176@psf.upfronthosting.co.za>
Message-ID: <1361639182.33.0.585722911867.issue17176@psf.upfronthosting.co.za>


Andreas Pelme added the comment:

This seems like an oversight from

http://bugs.python.org/issue15473

The release notes for 3.3 added a note about this:
"Because None is now inserted into sys.path_importer_cache, if you are clearing out entries in the dictionary of paths that do not have a finder, you will need to remove keys paired with values of None and imp.NullImporter to be backwards-compatible. This will lead to extra overhead on older versions of Python that re-insert None into sys.path_importer_cache where it repesents the use of implicit finders, but semantically it should not change anything."

But the relevant docs for NullImporter (http://docs.python.org/2/library/imp.html#imp.NullImporter) and sys.path_importer_cache (http://docs.python.org/2/library/sys.html#sys.path_importer_cache) did not get updated.

We have verified that the release notes in 3.4 is correct, and NullImporter is never used.

We are however not sure about the correct wording for the documentation fix.

----------
nosy: +Andreas.Pelme

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17176>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:06:41 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:06:41 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361639201.34.0.169799205369.issue8890@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Patch for 2.7, with most references to /tmp removed or replaced.

References remain in Doc/install/index.rst and Doc/library/rexec.rst as they seem to make sense in context.

----------
nosy: +gmwils
Added file: http://bugs.python.org/file29183/Issue8890.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:07:12 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Sat, 23 Feb 2013 17:07:12 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1361639232.95.0.406477231458.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Attached patch file for the 2.7 branch. They not only touch find(), but also findtext(), which has the mistake in the documentation. Also does some related changes in the module's code comments.

----------
keywords: +patch
nosy: +hheimbuerger
Added file: http://bugs.python.org/file29184/issue11367_branch27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:07:55 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Sat, 23 Feb 2013 17:07:55 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1361639275.83.0.585654057356.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Almost identical patch for 3.2, just differs in line numbers.

----------
Added file: http://bugs.python.org/file29185/issue11367_branch32.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:11:26 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Sat, 23 Feb 2013 17:11:26 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361639486.23.0.839810493262.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Sadly, that is quite complicated or almost impossible. It needs the MacOSX system Python and that one lacks debugging information.

I just tried with the CPython vom hg-2.7. But it seems the official Python doesn't have objc bindings (and I also need Cocoa bindings) so I can't easily run this right now (and another GUI is not yet implemented).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:14:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Feb 2013 17:14:43 +0000
Subject: [issue8489] Support UTF8SMTP as part of RFC 5336 in smptlib
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1361639683.03.0.458676239903.issue8489@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, this issue changed into a feature request for UTF8SMTP support, which I do intend to implement at some point.  

It does indeed appear like the original problem (not converting unicode strings into ASCII) was fixed in 2.7 at some point, though, which is good news, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:15:23 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Sat, 23 Feb 2013 17:15:23 +0000
Subject: [issue17116] xml.parsers.expat.(errors|model) don't set the
	__loader__ attribute
In-Reply-To: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za>
Message-ID: <1361639723.99.0.276889635274.issue17116@psf.upfronthosting.co.za>


G?k?en Eraslan added the comment:

Should this be done in Modules/pyexpat.c file or in Lib/xml/parsers/expat.py? If modifying expat.py is sufficient, then attached simple patch does the job. By the way I couldn't find the test you are referring to. Is it in Lib/test/test_importlib of somewhere else?

----------
keywords: +patch
nosy: +gkcn
Added file: http://bugs.python.org/file29186/python-issue-17116.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17116>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:25:15 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:25:15 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1361640315.13.0.575720197968.issue13952@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Patch against 2.7 to add csv to the internal list. It is popular enough as a format, that it should work even if the system mime files are stale.

----------
keywords: +patch
nosy: +gmwils
Added file: http://bugs.python.org/file29187/issue13952.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13952>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:26:30 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 17:26:30 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361640390.16.0.969263127419.issue15305@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Looks good to me, and all tests also pass on my Ubuntu 12.10.

Chris: Would you be willing to commit this and watch the buildbots do their job? Or do the buildbots even use the -j option?

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:27:37 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sat, 23 Feb 2013 17:27:37 +0000
Subject: [issue17115] __loader__ = None should be fine
In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za>
Message-ID: <1361640457.91.0.390682635185.issue17115@psf.upfronthosting.co.za>


Changes by G?kcen Eraslan <gokcen.eraslan at gmail.com>:


----------
nosy: +gkcn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17115>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:27:55 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sat, 23 Feb 2013 17:27:55 +0000
Subject: [issue17099] Raise ValueError when __loader__ not defined for
	importlib.find_loader()
In-Reply-To: <1359726277.47.0.865712090918.issue17099@psf.upfronthosting.co.za>
Message-ID: <1361640475.15.0.212673498087.issue17099@psf.upfronthosting.co.za>


Changes by G?kcen Eraslan <gokcen.eraslan at gmail.com>:


----------
nosy: +gkcn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17099>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:31:56 2013
From: report at bugs.python.org (Lowe Thiderman)
Date: Sat, 23 Feb 2013 17:31:56 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <1361640716.03.0.348426685625.issue14720@psf.upfronthosting.co.za>


Lowe Thiderman added the comment:

> Can convert_timestamp(val) be implemented as datetime.datetime.strptime(val.decode(), '%Y-%m-%d %H:%M:%S.%f')?

No. The microseconds are not always included, as can be seen by the current implementation. Nice idea though!

----------
nosy: +thiderman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:34:20 2013
From: report at bugs.python.org (Lowe Thiderman)
Date: Sat, 23 Feb 2013 17:34:20 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <1361640860.91.0.568235203764.issue14720@psf.upfronthosting.co.za>


Lowe Thiderman added the comment:

Add patch for 2.7 branch with regression test.

----------
keywords: +patch
Added file: http://bugs.python.org/file29188/issue14720.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:38:33 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 17:38:33 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1361641113.95.0.918851516468.issue11063@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

The implementation does not actually end up in infinite loop, just repeating the loading of the CDLL is slow.

I added caching to that and fixed the ctypes imports too.

----------
nosy: +nailor
Added file: http://bugs.python.org/file29189/issue11063_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:45:31 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:45:31 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361641531.51.0.308528664679.issue8890@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Attaching patch for 3.2 (Issue8890-3.2.patch)

----------
Added file: http://bugs.python.org/file29190/Issue8890-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:46:11 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:46:11 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361641571.15.0.180807521678.issue8890@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Attaching patch for 3.3 that also works for 3.4/default (Issue8890-3.3.patch)

----------
Added file: http://bugs.python.org/file29191/Issue8890-3.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:46:18 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 17:46:18 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361641578.6.0.96258068591.issue11671@psf.upfronthosting.co.za>


Devin Cook added the comment:

backported patch to 2.7

----------
Added file: http://bugs.python.org/file29192/header_newlines_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:51:37 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 17:51:37 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361641897.23.0.324036736428.issue11671@psf.upfronthosting.co.za>


Devin Cook added the comment:

backported patch to 2.6

----------
Added file: http://bugs.python.org/file29193/header_newlines_2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:56:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 17:56:31 +0000
Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a
	list
In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>
Message-ID: <3ZCxtk4pB6zSjX@mail.python.org>


Roundup Robot added the comment:

New changeset 4e2bfe6b227a by Petri Lehtinen in branch 'default':
Issue #15132: Allow a list for the defaultTest argument of unittest.TestProgram
http://hg.python.org/cpython/rev/4e2bfe6b227a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15132>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:57:04 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 17:57:04 +0000
Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a
	list
In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>
Message-ID: <1361642224.76.0.55525565069.issue15132@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15132>
_______________________________________

From report at bugs.python.org  Sat Feb 23 18:58:20 2013
From: report at bugs.python.org (=?utf-8?q?Andreas_=C3=85kerlund?=)
Date: Sat, 23 Feb 2013 17:58:20 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1361642300.59.0.53828441209.issue3991@psf.upfronthosting.co.za>


Andreas ?kerlund added the comment:

This is a patch against 3.2 adding urllib.parse.quote_uri

It splits the URI in 5 parts (protocol, authentication, hostname, port and path) then runs urllib.parse.quote on the path and encodes the hostname to punycode if it's not in ascii.

It's not perfect, but should be usable in most cases.
I created some test cases aswell.

----------
nosy: +thezulk
Added file: http://bugs.python.org/file29194/issue3991.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:12:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 18:12:44 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <3ZCyFR6YR7zShN@mail.python.org>


Roundup Robot added the comment:

New changeset 6911df35b7b6 by Petri Lehtinen in branch '2.7':
Issue #14720: sqlite3: Convert datetime microseconds correctly
http://hg.python.org/cpython/rev/6911df35b7b6

New changeset 46d5317a51fb by Petri Lehtinen in branch '3.2':
Issue #14720: sqlite3: Convert datetime microseconds correctly
http://hg.python.org/cpython/rev/46d5317a51fb

New changeset 46c96693296f by Petri Lehtinen in branch '3.3':
Issue #14720: sqlite3: Convert datetime microseconds correctly
http://hg.python.org/cpython/rev/46c96693296f

New changeset 6342055ac220 by Petri Lehtinen in branch 'default':
Issue #14720: sqlite3: Convert datetime microseconds correctly
http://hg.python.org/cpython/rev/6342055ac220

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:13:51 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 18:13:51 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <1361643231.7.0.388612984264.issue14720@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
nosy: +petri.lehtinen
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:24:38 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 18:24:38 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1361643878.6.0.132581121071.issue12226@psf.upfronthosting.co.za>


Changes by Devin Cook <devin.c.cook at gmail.com>:


----------
nosy: +devin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:38:00 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Sat, 23 Feb 2013 18:38:00 +0000
Subject: [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1361644680.15.0.107505878967.issue16802@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Here's a suggestion for a documentation addition. Comments on tone and content are welcome, and I'm willing to update it and submit modified patch files.

This adds the following note:
      If a file descriptor *fileno* is specified, the other arguments
      are ignored and and the socket with this file descriptor is returned. Unlike
      :meth:`fromfd`, this does not cause a duplication of the file descriptor
      and therefore supports the special case of closing detached socket handles
      on Windows using ``socket.socket(fileno=handle).close()``.

----------
keywords: +patch
nosy: +hheimbuerger
Added file: http://bugs.python.org/file29195/issue16802.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16802>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:39:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 18:39:04 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <3ZCyqq3dgPzPkT@mail.python.org>


Roundup Robot added the comment:

New changeset 488957f9b664 by Petri Lehtinen in branch '2.7':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/488957f9b664

New changeset 7556601180c8 by Petri Lehtinen in branch '3.2':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/7556601180c8

New changeset 18e20e146396 by Petri Lehtinen in branch '3.3':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/18e20e146396

New changeset 6b0ca4cb7e4e by Petri Lehtinen in branch 'default':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/6b0ca4cb7e4e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:40:07 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 18:40:07 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361644807.78.0.660928083912.issue8890@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:53:41 2013
From: report at bugs.python.org (Andy Holst)
Date: Sat, 23 Feb 2013 18:53:41 +0000
Subject: [issue15566] tarfile.TarInfo.frombuf documentation is out of date
In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za>
Message-ID: <1361645621.33.0.188191043887.issue15566@psf.upfronthosting.co.za>


Andy Holst added the comment:

The documentation updated for the tarfile.rst document. The arguments encoding and errors are added to tarfile.TarInfo.frombuf method. Patch uploaded.

----------
keywords: +patch
nosy: +StealthAsimov
Added file: http://bugs.python.org/file29196/issue15566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15566>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:58:01 2013
From: report at bugs.python.org (Martin Melin)
Date: Sat, 23 Feb 2013 18:58:01 +0000
Subject: [issue16709] unittest discover order is filesystem specific - hard to
	reproduce
In-Reply-To: <1355797737.36.0.999533489695.issue16709@psf.upfronthosting.co.za>
Message-ID: <1361645881.64.0.243875530358.issue16709@psf.upfronthosting.co.za>


Martin Melin added the comment:

Not sure if there was anything more to it than this, but please find an attempt to add this attached.

----------
keywords: +patch
nosy: +mmelin
Added file: http://bugs.python.org/file29197/issue16709.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16709>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:58:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 18:58:19 +0000
Subject: [issue16695] Clarify fnmatch & glob docs about the handling of
	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <3ZCzG31x8nzSkP@mail.python.org>


Roundup Robot added the comment:

New changeset 2b96dcdac419 by Petri Lehtinen in branch '2.7':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/2b96dcdac419

New changeset b4434cbca953 by Petri Lehtinen in branch '3.2':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/b4434cbca953

New changeset 3e8b29512b2e by Petri Lehtinen in branch '3.3':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/3e8b29512b2e

New changeset 3fd9970d9e65 by Petri Lehtinen in branch 'default':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/3fd9970d9e65

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16695>
_______________________________________

From report at bugs.python.org  Sat Feb 23 19:59:02 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 18:59:02 +0000
Subject: [issue16695] Clarify fnmatch & glob docs about the handling of
	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <1361645942.54.0.989633393392.issue16695@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
nosy: +petri.lehtinen
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16695>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:08:25 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 19:08:25 +0000
Subject: [issue16709] unittest discover order is filesystem specific - hard to
	reproduce
In-Reply-To: <1355797737.36.0.999533489695.issue16709@psf.upfronthosting.co.za>
Message-ID: <1361646505.65.0.352928318491.issue16709@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

The patch looks good to me.

----------
nosy: +petri.lehtinen
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16709>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:14:07 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 23 Feb 2013 19:14:07 +0000
Subject: [issue16709] unittest discover order is filesystem specific - hard to
	reproduce
In-Reply-To: <1355797737.36.0.999533489695.issue16709@psf.upfronthosting.co.za>
Message-ID: <1361646847.57.0.136614076611.issue16709@psf.upfronthosting.co.za>


Michael Foord added the comment:

As we're specifying this behaviour in the documentation it would be nice to test it.

----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16709>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:19:38 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 19:19:38 +0000
Subject: [issue16041] poplib: unlimited readline() from connection
In-Reply-To: <1348569563.2.0.69634867698.issue16041@psf.upfronthosting.co.za>
Message-ID: <1361647178.13.0.178669564207.issue16041@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Added a functionality that raises error_proto('line too long') if we read over _MAXLINE characters. Defaults _MAXLINE to 2048. The patch is written on top of 2.7

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file29198/issue16041.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16041>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:20:18 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 23 Feb 2013 19:20:18 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1361647218.57.0.773496497256.issue17130@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I already posted a patch in issue 9285.
Maybe we should close this one as a duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:24:27 2013
From: report at bugs.python.org (=?utf-8?q?Dennis_M=C3=A5rtensson?=)
Date: Sat, 23 Feb 2013 19:24:27 +0000
Subject: [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1361647467.34.0.590180706532.issue17188@psf.upfronthosting.co.za>


Dennis M?rtensson added the comment:

We have added the from None to the documentation with a explanation and some example code.

----------
keywords: +patch
nosy: +me at dennis.is
Added file: http://bugs.python.org/file29199/patch17188.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17188>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:35:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 19:35:42 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361648142.63.0.0274483148191.issue17263@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I have two questions:
- how do you know the crash really happens because of thread 5?
- when the thread.local object is being deleted, has another thread just started looking up its attributes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:37:26 2013
From: report at bugs.python.org (Joar Wandborg)
Date: Sat, 23 Feb 2013 19:37:26 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361648246.8.0.649237439002.issue17267@psf.upfronthosting.co.za>


Joar Wandborg added the comment:

Patch submitted, please review.

----------
keywords: +patch
nosy: +joar
Added file: http://bugs.python.org/file29200/issue17267.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:38:54 2013
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Skoglund?=)
Date: Sat, 23 Feb 2013 19:38:54 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1361648334.94.0.466972416495.issue17130@psf.upfronthosting.co.za>


Bj?rn Skoglund added the comment:

Look at that. Sorry, totally missed it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:43:57 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sat, 23 Feb 2013 19:43:57 +0000
Subject: [issue17093] Make importlib.abc more inheritance-friendly
In-Reply-To: <1359666401.55.0.375165619272.issue17093@psf.upfronthosting.co.za>
Message-ID: <1361648637.62.0.676895481695.issue17093@psf.upfronthosting.co.za>


Changes by G?kcen Eraslan <gokcen.eraslan at gmail.com>:


----------
nosy: +gkcn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17093>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:45:33 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 19:45:33 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1361648733.87.0.0180981224742.issue16037@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Here's a patch that limits the headers to 100. If more than _MAXHEADERS headers are read, this raises exception TooMuchHeaders.

The patch is for 2.7, I'll cook one for 3.2 too.

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file29201/issue16037_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:52:12 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 19:52:12 +0000
Subject: [issue11259] asynchat does not check if terminator is negative integer
In-Reply-To: <1298220002.68.0.352394054223.issue11259@psf.upfronthosting.co.za>
Message-ID: <1361649132.58.0.983892154936.issue11259@psf.upfronthosting.co.za>


Devin Cook added the comment:

I agree that this is probably a bug, but can't think of any instances where this in itself would cause a security issue. By sending something like a negative Content-Length, you do indeed get data returned that doesn't really match the data sent on the wire. If you're able to manipulate the Content-Length, though, instead of sending a negative value num, you could instead send len(data) + num.

Here's a simple example I was able to come up with:

Server reads data and runs "echo -n > {data}" (or any write the file specified in "data").
Client is supposed to send Content-Length, then that many bytes, expected to be a file that should be written to.
Client instead sends "-4\n/etc/passwd.bak".
Server runs "echo -n > /etc/passwd".

So that's certainly unexpected bahavior. However, this is a fairly low-level module, and doesn't actually do anything with the data it collects. That's left to the subclass, and subclasses should be responsible for validating any data read off the wire before using it.

Attached is a patch to tip, including a new test case.

----------
nosy: +devin
type: security -> behavior
Added file: http://bugs.python.org/file29202/asynchat_tip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11259>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:52:37 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 19:52:37 +0000
Subject: [issue16037] httplib: header parsing is not delimited
In-Reply-To: <1348568722.91.0.654032066819.issue16037@psf.upfronthosting.co.za>
Message-ID: <1361649157.7.0.829765591896.issue16037@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

...and here's the patch for 3.2

----------
Added file: http://bugs.python.org/file29203/issue16037_py32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16037>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:57:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 19:57:42 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361649462.19.0.492599755816.issue17263@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Another question: are threads being started or stopped while the thread local object is being deleted?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 20:58:01 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 19:58:01 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361649481.05.0.425235089786.issue17267@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Added some comments to Rietveld.

----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:02:49 2013
From: report at bugs.python.org (David Lam)
Date: Sat, 23 Feb 2013 20:02:49 +0000
Subject: [issue8489] Support UTF8SMTP as part of RFC 5336 in smptlib
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1361649769.2.0.610999370563.issue8489@psf.upfronthosting.co.za>


David Lam added the comment:

looks like RFC 6531 obsoletes 5336  -->   http://datatracker.ietf.org/doc/rfc6531/

(6531 says its the "Proposed Standard", whereas 5336 says its "Experimental" etc etc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:10:21 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 20:10:21 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361650221.59.0.819663092938.issue10572@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Patch attached to move sqlite3 tests under Lib/test, and remove Lib/test/test_sqlite.py.

Naming of files has been kept the same in the move from Lib/sqlite/test, to allow for easier merging of future patches.

----------
keywords: +patch
nosy: +gmwils
Added file: http://bugs.python.org/file29204/issue10572-sqlite3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:11:25 2013
From: report at bugs.python.org (Manuel Jacob)
Date: Sat, 23 Feb 2013 20:11:25 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361650285.12.0.592820868791.issue17223@psf.upfronthosting.co.za>


Manuel Jacob added the comment:

http://docs.python.org/3/library/array.html states that the 'u' type code is deprecated together with the rest of the Py_UNICODE API (which includes PyUnicode_FromUnicode), so keeping this using PyUnicode_FromUnicode should be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:12:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 20:12:03 +0000
Subject: [issue16403] update distutils docs to say that maintainer replaces
	author
In-Reply-To: <1352029026.5.0.383021349699.issue16403@psf.upfronthosting.co.za>
Message-ID: <3ZD0v64hLBzSmX@mail.python.org>


Roundup Robot added the comment:

New changeset 14144373fdcd by Petri Lehtinen in branch '2.7':
Issue #16403: Document how distutils uses the maintainer field in PKG-INFO
http://hg.python.org/cpython/rev/14144373fdcd

New changeset b65b6a0ebd44 by Petri Lehtinen in branch '3.2':
Issue #16403: Document how distutils uses the maintainer field in PKG-INFO
http://hg.python.org/cpython/rev/b65b6a0ebd44

New changeset af4c08b10702 by Petri Lehtinen in branch '3.3':
Issue #16403: Document how distutils uses the maintainer field in PKG-INFO
http://hg.python.org/cpython/rev/af4c08b10702

New changeset 9de4602a80b9 by Petri Lehtinen in branch 'default':
Issue #16403: Document how distutils uses the maintainer field in PKG-INFO
http://hg.python.org/cpython/rev/9de4602a80b9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16403>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:13:40 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 20:13:40 +0000
Subject: [issue16403] update distutils docs to say that maintainer replaces
	author
In-Reply-To: <1352029026.5.0.383021349699.issue16403@psf.upfronthosting.co.za>
Message-ID: <1361650420.78.0.940305897843.issue16403@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
nosy: +petri.lehtinen
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16403>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:15:33 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 20:15:33 +0000
Subject: [issue10340] asyncore doesn't properly handle EINVAL on OSX
In-Reply-To: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>
Message-ID: <1361650533.67.0.949400495081.issue10340@psf.upfronthosting.co.za>


Devin Cook added the comment:

This looks resolved. Can it be closed?

----------
nosy: +devin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:21:07 2013
From: report at bugs.python.org (Joar Wandborg)
Date: Sat, 23 Feb 2013 20:21:07 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361650867.72.0.644193121103.issue17267@psf.upfronthosting.co.za>


Joar Wandborg added the comment:

New patch adressing the review comments.

----------
Added file: http://bugs.python.org/file29205/issue17267.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:25:23 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 20:25:23 +0000
Subject: [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1361651123.08.0.258039372904.issue17188@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

The patch should add something to the "The from clause is used for exception..." paragraph, to state that None is also allowed.

It also adds things in a confusing order. I think the new example should go below other examples, and the changedversion and addedversion directives should be the last thing in the section.

----------
nosy: +petri.lehtinen
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17188>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:27:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 20:27:20 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361651240.1.0.519843162096.issue16801@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy called subclassing 'particular and cumbersome'.
'Cumbersome' is an opinion. I consider subclassing elegant. The ease of doing so and specializing only what one needs to is a major feature of Python. It only took me a couple of minutes to whip up solutions for two different cases.

I think 'particular' is wrong. Subclassing is a general solution for a particular class of values. As I illustrated, it results in the value getting its custom representation *everywhere*. Other solutions seem to give it its custom representation only in the particular context of standard signature displays, and its 'regular' not-so-good representation when directly accessed. To me, that is much worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:30:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 20:30:27 +0000
Subject: [issue7504] Same name cookies
In-Reply-To: <1260798869.28.0.314761148717.issue7504@psf.upfronthosting.co.za>
Message-ID: <1361651427.82.0.810569243119.issue7504@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Which also has patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7504>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:35:02 2013
From: report at bugs.python.org (=?utf-8?q?Andreas_=C3=85kerlund?=)
Date: Sat, 23 Feb 2013 20:35:02 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361651702.75.0.0524945451278.issue17267@psf.upfronthosting.co.za>


Andreas ?kerlund added the comment:

Well I have also made a patch for this, using the datetime operator code as much as possible.. this is for version 3.4..

----------
nosy: +thezulk
Added file: http://bugs.python.org/file29206/issue17267-3.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:50:31 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 23 Feb 2013 20:50:31 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1361652630.99.0.891129664543.issue1470548@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

The change in 2.7 branch breaks some software, including a test of Django (produce_xml_fragment from https://github.com/django/django/blob/1.4.5/tests/regressiontests/test_utils/tests.py).
The problem seems to not occur with Python 3.2, 3.3 and 3.4.

Before 010b455de0e0:
>>> from StringIO import StringIO
>>> from xml.sax.saxutils import XMLGenerator
>>> stream = StringIO()
>>> xml = XMLGenerator(stream, encoding='utf-8')
>>> xml.startElement("foo", {"aaa": "1.0", "bbb": "2.0"})
>>> xml.characters("Hello")
>>> xml.endElement("foo")
>>> xml.startElement("bar", {"ccc": "3.0", "ddd": "4.0"})
>>> xml.endElement("bar")
>>> stream.getvalue()
'<foo aaa="1.0" bbb="2.0">Hello</foo><bar ccc="3.0" ddd="4.0"></bar>'
>>>

After 010b455de0e0:
>>> from StringIO import StringIO
>>> from xml.sax.saxutils import XMLGenerator
>>> stream = StringIO()
>>> xml = XMLGenerator(stream, encoding='utf-8')
>>> xml.startElement("foo", {"aaa": "1.0", "bbb": "2.0"})
>>> xml.characters("Hello")
>>> xml.endElement("foo")
>>> xml.startElement("bar", {"ccc": "3.0", "ddd": "4.0"})
>>> xml.endElement("bar")
>>> stream.getvalue()
''
>>>

----------
nosy: +Arfrever, benjamin.peterson, larry
priority: normal -> release blocker
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:54:13 2013
From: report at bugs.python.org (Birk Nilson)
Date: Sat, 23 Feb 2013 20:54:13 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361652852.99.0.698292427745.issue16121@psf.upfronthosting.co.za>


Birk Nilson added the comment:

The implementation incremented the line number immediately when a newline was detected, even before the token had been processed completely - causing the issue Arfrever posted.

This also caused the unexpected behavior of a tokens line number including the amount of lines within the token itself. In other words '"a \n b \n c" \n d' would result in the token "a \n b \n c" to have the line number #3, followed by "d" being on the expected line #4. In my patch, the expected behavior of seeing the first token on line #1 and the second on #4 is introduced.

I also added the testLineNumbers method in the test suite - included in the patch.

----------
keywords: +patch
nosy: +birknilson
Added file: http://bugs.python.org/file29207/issue16121.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sat Feb 23 21:59:56 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 20:59:56 +0000
Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace
In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za>
Message-ID: <1361653196.1.0.707408650248.issue16446@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

I took Xavier's patch and ported in on the 2.7. It'll probably go as is for 3.2. 

The functionality seems to be working and tests pass.

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file29208/issue16446.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16446>
_______________________________________

From report at bugs.python.org  Sat Feb 23 22:04:25 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 21:04:25 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361653465.78.0.465291175421.issue10572@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Patch attached to move Lib/lib2to3/tests to Lib/test/test_lib2to3.

----------
Added file: http://bugs.python.org/file29209/issue10572-lib2to3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Sat Feb 23 22:15:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 21:15:42 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <3ZD2JZ0Wx5zNRp@mail.python.org>


Roundup Robot added the comment:

New changeset e54ee8d2c16b by Petri Lehtinen in branch '2.7':
Issue #16121: Fix line number accounting in shlex
http://hg.python.org/cpython/rev/e54ee8d2c16b

New changeset f1d19fdb254f by Petri Lehtinen in branch '3.2':
Issue #16121: Fix line number accounting in shlex
http://hg.python.org/cpython/rev/f1d19fdb254f

New changeset 560e53fcf2b0 by Petri Lehtinen in branch '3.3':
Issue #16121: Fix line number accounting in shlex
http://hg.python.org/cpython/rev/560e53fcf2b0

New changeset f48c3c7a3205 by Petri Lehtinen in branch 'default':
Issue #16121: Fix line number accounting in shlex
http://hg.python.org/cpython/rev/f48c3c7a3205

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sat Feb 23 22:16:40 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 21:16:40 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361654200.49.0.389653813533.issue16121@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
nosy: +petri.lehtinen
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sat Feb 23 22:37:21 2013
From: report at bugs.python.org (Devin Cook)
Date: Sat, 23 Feb 2013 21:37:21 +0000
Subject: [issue16632] Enable DEP and ASLR
In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za>
Message-ID: <1361655441.36.0.298859582108.issue16632@psf.upfronthosting.co.za>


Changes by Devin Cook <devin.c.cook at gmail.com>:


----------
nosy: +devin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16632>
_______________________________________

From report at bugs.python.org  Sat Feb 23 22:52:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Feb 2013 21:52:18 +0000
Subject: [issue8489] Support RFC 6531 in smptlib
In-Reply-To: <1271877469.99.0.897777864709.issue8489@psf.upfronthosting.co.za>
Message-ID: <1361656338.14.0.563490868908.issue8489@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the pointer.  I keep reading "SMTPUTF8" as "SMTPUFF", but otherwise at a quick glance it looks like an improvement.

----------
title: Support UTF8SMTP as part of RFC 5336 in smptlib -> Support RFC 6531 in smptlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8489>
_______________________________________

From report at bugs.python.org  Sat Feb 23 22:58:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Feb 2013 21:58:49 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361656729.28.0.281352701703.issue16121@psf.upfronthosting.co.za>


R. David Murray added the comment:

Something in this change seems to have broken netrc:

http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.3/builds/520

----------
nosy: +r.david.murray
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sat Feb 23 23:15:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 22:15:11 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <3ZD3dB5xPLzMvc@mail.python.org>


Roundup Robot added the comment:

New changeset 34f759fa5484 by Petri Lehtinen in branch '2.7':
Revert "Issue #16121: Fix line number accounting in shlex"
http://hg.python.org/cpython/rev/34f759fa5484

New changeset cda4a9dc415a by Petri Lehtinen in branch '3.2':
Revert "Issue #16121: Fix line number accounting in shlex"
http://hg.python.org/cpython/rev/cda4a9dc415a

New changeset 15f3fd6070b7 by Petri Lehtinen in branch '3.3':
Revert "Issue #16121: Fix line number accounting in shlex"
http://hg.python.org/cpython/rev/15f3fd6070b7

New changeset 1b0a6c1f8a08 by Petri Lehtinen in branch 'default':
Revert "Issue #16121: Fix line number accounting in shlex"
http://hg.python.org/cpython/rev/1b0a6c1f8a08

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sat Feb 23 23:16:51 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 22:16:51 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361657811.7.0.099877836762.issue16121@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Reverted the patch because of the broken netrc tests. This has to be investigated further.

----------
resolution: fixed -> 
stage: committed/rejected -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sat Feb 23 23:27:34 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 22:27:34 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361648142.63.0.0274483148191.issue17263@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2SEonbgXCmrwjAjCmXYZJMv76vfUpji=1yQa68iHzhwg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> - how do you know the crash really happens because of thread 5?

All other threads are blocked on locks or condition variables, it's
the only runnable thread.

> Another question: are threads being started or stopped while the thread local object is being deleted?

>From the stack trace, thread 2 is being stopped.

I guess the problem is similar to above: thread 2 is in the middle of
stopping, its TLS dict is deallocated, which triggers the thread local
object deallocation, which releases the GIL. Thread 5 becomes running,
and must somehow access thread 2 tstate.
It would be much easier with a backtrace, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 23:35:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 22:35:38 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <CAH_1eM2SEonbgXCmrwjAjCmXYZJMv76vfUpji=1yQa68iHzhwg@mail.gmail.com>
Message-ID: <1361658728.3600.7.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> > - how do you know the crash really happens because of thread 5?
> 
> All other threads are blocked on locks or condition variables, it's
> the only runnable thread.

Hm, you are right.

> > Another question: are threads being started or stopped while the thread local object is being deleted?
> 
> >From the stack trace, thread 2 is being stopped.
> 
> I guess the problem is similar to above: thread 2 is in the middle of
> stopping, its TLS dict is deallocated, which triggers the thread local
> object deallocation, which releases the GIL. Thread 5 becomes running,
> and must somehow access thread 2 tstate.

I've read the code several times and I find it unlikely that it's the
cause of the problem:
- the thread state's thread-local dict (tstate->dict) is deallocated
using Py_CLEAR(), meaning it's unreachable from other threads when
deallocating one of the values releases the GIL
- the thread-local object's deallocator checks that tstate->dict is
non-NULL before using it; the only thing that could go wrong is if
PyDict_GetItem() releases the GIL, which sounds unlikely on tstate->dict

(also, I've checked that threadmodule.c holds the GIL when inserting and
removing thread states from the interpreter's thread states list; it
would be more future-proof for local_dealloc to use pystate.c's
HEAD_LOCK() and HEAD_UNLOCK() APIs, though)

I'm wondering if there's something else interfering here. My attempts at
writing a stress-test script have failed to produce any crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sat Feb 23 23:37:54 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Feb 2013 22:37:54 +0000
Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess
In-Reply-To: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za>
Message-ID: <1361659074.77.0.158916501329.issue16945@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16945>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:16:14 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 23 Feb 2013 23:16:14 +0000
Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a
	list
In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>
Message-ID: <1361661374.51.0.547613242476.issue15132@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, Jyrki and Petri.  I just noticed that a "Changed in version" should probably be added at the end of this section:

http://docs.python.org/dev/library/unittest.html#unittest.main

*defaultTest* should probably also be documented in the text (it currently appears only in the documentation signature), though this part of my comment need not be done as part of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15132>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:17:41 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 23 Feb 2013 23:17:41 +0000
Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a
	list
In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>
Message-ID: <1361661461.11.0.68352577844.issue15132@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I can take care of the Changed in version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15132>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:30:37 2013
From: report at bugs.python.org (Birk Nilson)
Date: Sat, 23 Feb 2013 23:30:37 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361662237.29.0.661231400412.issue16121@psf.upfronthosting.co.za>


Birk Nilson added the comment:

Sorry about that. Rookie mistake. I'm investigating it now and will get back with a revised & fully tested patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:33:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 23:33:41 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
In-Reply-To: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>
Message-ID: <1361662421.49.0.382536180962.issue17278@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a reproducer.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file29210/stressheapq.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:33:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 23:33:59 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
In-Reply-To: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>
Message-ID: <1361662439.34.0.794908613496.issue17278@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

And a patch (for 2.7).

----------
keywords: +patch
versions: +Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29211/heapq_race.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:47:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 23:47:28 +0000
Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a
	list
In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>
Message-ID: <3ZD5gg4dKBzP02@mail.python.org>


Roundup Robot added the comment:

New changeset 4285d13fd3dc by Chris Jerdonek in branch 'default':
Add a "Changed in version" to the docs for issue #15132.
http://hg.python.org/cpython/rev/4285d13fd3dc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15132>
_______________________________________

From report at bugs.python.org  Sun Feb 24 00:50:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2013 23:50:28 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
In-Reply-To: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>
Message-ID: <1361663428.96.0.506510913499.issue17278@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch with tests.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file29212/heapq_race2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:11:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2013 00:11:41 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1361664701.83.0.00341834218673.issue17100@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Attaching proof of concept patch for rotate_at() and rotate_after().
I am now conviced that bare rotate() isn't very useful.

----------
keywords: +patch
Added file: http://bugs.python.org/file29213/od_rotate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17100>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:14:54 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 00:14:54 +0000
Subject: [issue17282] document the defaultTest parameter to unittest.main()
Message-ID: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to document the defaultTest parameter to unittest.main():

http://docs.python.org/dev/library/unittest.html#unittest.main

Note that it is not enough simply to say that *defaultTest* is a "default test name or iterable of test names."  The documentation should also say when *defaultTest* is used based on the value of the *module* and *argv* arguments, etc.

This issue is an offshoot of issue 15132.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 182839
nosy: chris.jerdonek, docs at python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: document the defaultTest parameter to unittest.main()
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17282>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:15:59 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 00:15:59 +0000
Subject: [issue15132] Let unittest.TestProgram()'s defaultTest argument be a
	list
In-Reply-To: <1340353530.68.0.240528814016.issue15132@psf.upfronthosting.co.za>
Message-ID: <1361664959.85.0.444097485603.issue15132@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> *defaultTest* should probably also be documented in the text

I created issue 17282 for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15132>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:38:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 00:38:38 +0000
Subject: [issue675976] mhlib does not obey MHCONTEXT env var
Message-ID: <1361666318.71.0.254971774488.issue675976@psf.upfronthosting.co.za>


R. David Murray added the comment:

The mailbox module provides tools for accessing an MH folder, but it does not do anything itself about folder management.  That would be the province of a program using the mailbox module to implement an MUA.  So, since mhlib is no more, this enhancement request is no longer valid.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue675976>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:45:51 2013
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 24 Feb 2013 00:45:51 +0000
Subject: [issue16942] urllib still doesn't support persistent connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361666751.93.0.126666219736.issue16942@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16942>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:49:11 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 24 Feb 2013 00:49:11 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361666951.91.0.802595852992.issue16612@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Okay, I have finally addressed all the comments so far.  Changes described below are my patch #2.  They're also checked in to https://bitbucket.org/larry/python-clinic/ .

* Antoine, Nick, et al: I've converted clinic.txt into a PEP.  I've
  already sent it to the PEP maintainer dudes.

* Chris Jerdonek: I've taken a stab at clearing up "parameter" versus
  "argument".  Please give it a fresh once-over (and let me know if
  I miscounted the angels dancing on the head of that pin :-p ).

* Bradley Froehle: I've added an experimental(!) extension mechanism,
  exactly for path_t arguments.  Please see Modules/posixmodule.c
  to see what it looks like.  (I knew I'd have a use for the [python]
  sections someday!)

* Antoine: I've implemented shunting the bulk of Argument Clinic's
  output into a separate file.  Please see Modules/zlibmodule.c
  and Modules/zlibmodule_clinic.c for more.

* Stefan Krah: I look forward to reading your PEP.  Hopefully I've saved
  you some work in the rationale, if referring to mine works for you.

I don't suppose we can get some decisions made and some code checked in before the PyCon sprints...?

----------
Added file: http://bugs.python.org/file29214/larry.clinic.patch.2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Sun Feb 24 01:50:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 00:50:41 +0000
Subject: [issue694374] Recursive regular expressions
Message-ID: <1361667041.31.0.223049400141.issue694374@psf.upfronthosting.co.za>


R. David Murray added the comment:

Agreed that this is unlikely to ever get implemented given that Matthew doesn't think it should be.

----------
assignee: niemeyer -> 
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue694374>
_______________________________________

From report at bugs.python.org  Sun Feb 24 02:04:50 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 01:04:50 +0000
Subject: [issue747320] rfc2822 formatdate functionality duplication
Message-ID: <1361667890.2.0.631205440391.issue747320@psf.upfronthosting.co.za>


R. David Murray added the comment:

I notice that logging has been updated.  Only http.server's date_time_string remains (email.utils.formatdate does support the GMT form).

----------
components: +email
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue747320>
_______________________________________

From report at bugs.python.org  Sun Feb 24 02:08:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 01:08:24 +0000
Subject: [issue783528] Inconsistent results with super and __getattribute__
Message-ID: <1361668104.97.0.505003334014.issue783528@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> super() and property inheritance behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue783528>
_______________________________________

From report at bugs.python.org  Sun Feb 24 02:10:54 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 01:10:54 +0000
Subject: [issue846817] control-c is being sent to child thread rather than main
Message-ID: <1361668254.29.0.0878310555351.issue846817@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue846817>
_______________________________________

From report at bugs.python.org  Sun Feb 24 02:18:50 2013
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 24 Feb 2013 01:18:50 +0000
Subject: [issue16942] urllib still doesn't support persistent connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361668730.11.0.302226233003.issue16942@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I've changed FileCookieJar to use the ABCMeta metaclass and updated the concrete implementations. If this patch looks sufficient, I'll make an update to the docs as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file29215/cookiejar_16942.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16942>
_______________________________________

From report at bugs.python.org  Sun Feb 24 02:53:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Feb 2013 01:53:01 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361670781.33.0.576202819259.issue17279@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Such a list might differentiate between classes that are intentionally not subclassed and those for which subclassing simply has not yet been enabled. That might help eliminate the latter list.

When I suggested on the python-ideas 'range' thread that people should best get what they wanted with a range subclass, if that were made possible, Nick C. replied "I wasn't even aware you *couldn't* subclass it (I'd never tried).". Indeed, why would he with no doc.

The types module doc could also use an addition.
Attached subclassable.py produces these lists:
Among named builtin classes, these cannot be subclassed:
bool, memoryview, range, slice, 
Among types classes, these can be subclassed:
ModuleType, SimpleNamespace,

----------
Added file: http://bugs.python.org/file29216/subclassable.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17279>
_______________________________________

From report at bugs.python.org  Sun Feb 24 03:09:40 2013
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 24 Feb 2013 02:09:40 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1361671780.82.0.28297868843.issue12455@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Sun Feb 24 03:25:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Feb 2013 02:25:07 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361672707.34.0.135579138027.issue17279@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The list given is for 3.3. 3.2 and 2.7 do not have SimpleNamespace. I do not have and currently cannot build 3.4 to test, but as of this moment, I expect it to be the same. In 2.7, range is xrange. Its types module includes aliases for builtins, such as IntType, so "Among classes that do not have built-in names" would need to be prefixed.

I simple sentence for types should be easy to place. I am not sure about the built-ins list. The bool entry already has "Class bool cannot be subclassed further. Its only instances are False and True (see Boolean Values).", so a general list would be repeating that part. I am thinking of a minimal sentence for the other three entries. "This class cannot be subclassed."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17279>
_______________________________________

From report at bugs.python.org  Sun Feb 24 03:52:36 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 24 Feb 2013 02:52:36 +0000
Subject: [issue694374] Recursive regular expressions
Message-ID: <1361674356.84.0.395077071558.issue694374@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

FYI, I did eventually add it to my regex implementation. It was quite challenging!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue694374>
_______________________________________

From report at bugs.python.org  Sun Feb 24 04:22:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Feb 2013 03:22:15 +0000
Subject: [issue17275] io.BufferedWriter shows wrong type in argument error
	message
In-Reply-To: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>
Message-ID: <3ZDBRV39zBzSs8@mail.python.org>


Roundup Robot added the comment:

New changeset d6a26cd93825 by R David Murray in branch '3.2':
#17275: Fix class name in init errors in C bufferedio classes.
http://hg.python.org/cpython/rev/d6a26cd93825

New changeset aae2bb2e3195 by R David Murray in branch '3.3':
Merge #17275: Fix class name in init errors in C bufferedio classes.
http://hg.python.org/cpython/rev/aae2bb2e3195

New changeset df57314b93d1 by R David Murray in branch '2.7':
#17275: Fix class name in init errors in C bufferedio classes.
http://hg.python.org/cpython/rev/df57314b93d1

New changeset 96f08a22f562 by R David Murray in branch 'default':
Merge #17275: Fix class name in init errors in C bufferedio classes.
http://hg.python.org/cpython/rev/96f08a22f562

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17275>
_______________________________________

From report at bugs.python.org  Sun Feb 24 04:23:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 03:23:57 +0000
Subject: [issue17275] io.BufferedWriter shows wrong type in argument error
	message
In-Reply-To: <1361533910.18.0.171514836206.issue17275@psf.upfronthosting.co.za>
Message-ID: <1361676237.08.0.583223397157.issue17275@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Manuel.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17275>
_______________________________________

From report at bugs.python.org  Sun Feb 24 04:40:21 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 03:40:21 +0000
Subject: [issue16401] mention PKG-INFO in the documentation
In-Reply-To: <1352024381.32.0.925896266965.issue16401@psf.upfronthosting.co.za>
Message-ID: <1361677221.89.0.503980699889.issue16401@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

FYI, the fix for issue 16403 adds I believe the first mention of PKG-INFO to the docs (as an aside when discussing the maintainer field).  However, a description of PKG-INFO, etc. should still be added somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16401>
_______________________________________

From report at bugs.python.org  Sun Feb 24 05:24:56 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Sun, 24 Feb 2013 04:24:56 +0000
Subject: [issue17273] multiprocessing.pool.Pool task/worker handlers are not
	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361679896.5.0.69308389213.issue17273@psf.upfronthosting.co.za>


Arun Babu Neelicattu added the comment:

Terry, I think the best place to make a note of this would be at [1,2].

As for what should be noted, something along the lines of what Richard mentioned should suffice.

"A pool should only be used by the process that created it (unless you use a managed pool)."

I am not certain what the best way to phrase this would be, but it would also be helpful to note that this will cause unexpected behavior if a script imports a module that uses a Pool and forks (ie. uses Process() or another Pool()). This is how I bumped into this issue.

Hope this helps.

[1] http://docs.python.org/2/library/multiprocessing.html#using-a-pool-of-workers
[2] http://docs.python.org/3/library/multiprocessing.html#using-a-pool-of-workers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17273>
_______________________________________

From report at bugs.python.org  Sun Feb 24 05:28:00 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 04:28:00 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361680080.35.0.747146945245.issue15305@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I would be happy to commit and watch the buildbots, once I have confidence in the patch though.  Question: I noticed that the following was changed in Lib/test/regrtest.py:

-    with support.temp_cwd(TESTCWD, quiet=True):
+    with support.temp_cwd(quiet=True, path=TESTCWD):

But the corresponding change wasn't made in Lib/test/__main__.py (which I believe is the code path used by Geoff's `./python.exe -m test -j3` invocation):

http://hg.python.org/cpython/file/96f08a22f562/Lib/test/__main__.py#l12

Those two code chunks should really share code by the way (even the code comment is copied verbatim), which would help in not needing to update code in two places as in this issue/patch.  Perhaps that should even be done first as part of a separate issue (to separate this into smaller changes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Sun Feb 24 06:57:28 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 05:57:28 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
Message-ID: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As discussed here:

http://bugs.python.org/issue15305#msg182853

this issue is for Lib/test/__main__.py to share code with Lib/test/regrtest.py to minimize duplication of code:

http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l1594
http://hg.python.org/cpython/file/96f08a22f562/Lib/test/__main__.py#l12

----------
components: Tests
keywords: easy
messages: 182854
nosy: chris.jerdonek, ezio.melotti, gmwils, michael.foord, petri.lehtinen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Lib/test/__main__.py should share code with regrtest.py
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Sun Feb 24 07:00:22 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 06:00:22 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361685622.36.0.796905559575.issue15305@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Those two code chunks should really share code by the way

I created issue 17283 for this (it's okay to fix the current issue before this one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Sun Feb 24 09:22:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Feb 2013 08:22:44 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <1361694164.59.0.684684903911.issue14720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

convert_timestamp() can silently return wrong result if seconds saved with more than millisecond precision (i.e. '2012-04-04 15:06:00.000123456'). I propose or truncate fractional part to 6 digits ('{:0<6.6}') or explicitly raise an exception if len(timepart_full[1]) > 6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Sun Feb 24 09:23:50 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Feb 2013 08:23:50 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361694230.38.0.772154798346.issue16121@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

> I'm investigating it now and will get back with a revised &
> fully tested patch.

Sounds good. FWIW, it only broke on 3.x and default branches, and you can probably reproduce it on my own machine, too, by applying the patch and then running test_netrc.

This is what shlex documentation says about lineno:

> shlex.lineno
>     Source line number (count of newlines seen so far plus one).

This is a bit vague, as it doesn't really state whether newlines should be treated "greedily" (consumbed before the next token is read) or "lazily" (consumed only when the next token is read).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Sun Feb 24 09:33:13 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Feb 2013 08:33:13 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1361694164.59.0.684684903911.issue14720@psf.upfronthosting.co.za>
Message-ID: <20130224083310.GA4439@chang>


Petri Lehtinen added the comment:

Serhiy Storchaka wrote:
> convert_timestamp() can silently return wrong result if seconds
> saved with more than millisecond precision (i.e. '2012-04-04
> 15:06:00.000123456'). I propose or truncate fractional part to 6
> digits ('{:0<6.6}') or explicitly raise an exception if
> len(timepart_full[1]) > 6.

That's a good point. Also, '2012-04-04 15:06:00.1234567' fails with a
ValueError when executing the SELECT statement, because the
microsecond part is not in range 0-999999.

Truncating the fractional part to 6 characters sounds good to me,
because that way we get the best possible precision without failing
abruptly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Sun Feb 24 09:37:39 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 08:37:39 +0000
Subject: [issue17284] create mercurial section in devguide's committing.rst
Message-ID: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As discussed in issue 14468, this issue is to reorder the sections in the devguide's committing.rst to create a section dedicated to using Mercurial when committing.  The attached patch is adapted from the "2-move_two_sections.diff" patch of that issue.

----------
components: Devguide
files: mercurial-section-1.patch
keywords: easy, patch
messages: 182859
nosy: chris.jerdonek, eric.araujo, ezio.melotti, ncoghlan, pitrou, sandro.tosi, terry.reedy, tshepang
priority: normal
severity: normal
stage: patch review
status: open
title: create mercurial section in devguide's committing.rst
type: enhancement
Added file: http://bugs.python.org/file29217/mercurial-section-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17284>
_______________________________________

From report at bugs.python.org  Sun Feb 24 09:39:18 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 08:39:18 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361695158.15.0.717373234065.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

As discussed above and because this comment thread is getting very long, I'm going to start proposing smaller issues off of this one.  In this way we can start committing as we reach agreement, and hash out any disagreements in more focused contexts around smaller patches.  I will copy the nosy list unless I hear otherwise from anyone.

> Patch 2 could indeed committed separately,

I created issue 17284 for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Sun Feb 24 09:48:52 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sun, 24 Feb 2013 08:48:52 +0000
Subject: [issue13952] mimetypes doesn't recognize .csv
In-Reply-To: <1328550236.31.0.476108753678.issue13952@psf.upfronthosting.co.za>
Message-ID: <1361695732.48.0.07580532991.issue13952@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy: +petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13952>
_______________________________________

From report at bugs.python.org  Sun Feb 24 10:08:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Feb 2013 09:08:15 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1361696895.2.0.789660746595.issue1470548@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for report. Here is a patch which fixes this bug.

----------
Added file: http://bugs.python.org/file29218/XMLGenerator_fragment-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Sun Feb 24 10:19:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Feb 2013 09:19:56 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361697596.46.0.0269710641319.issue16801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It's cumbersome and burdensome because you need for every nonstandard default value:

1) define a class with __repr__();
2) instantiate a sentinel;
3) check for the sentinel in the function and replace it but an actual value.

    class _ExternalAttrDefault:
        def __repr__():
            return '(stat.S_IRUSR|stat.S_IRUSR)<<16'

    _external_attr_default = _ExternalAttrDefault()

    def open(self, name, mode='r', external_attr=_external_attr_default):
        if external_attr is _external_attr_default:
            external_attr = (stat.S_IRUSR|stat.S_IRUSR)<<16
        ...

Instead of just:

    def open(self, name, mode='r', external_attr=(stat.S_IRUSR|stat.S_IRUSR)<<16):
        """
        Foo.open(name, mode='r', external_attr=(stat.S_IRUSR|stat.S_IRUSR)<<16)
        """
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Sun Feb 24 10:32:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Feb 2013 09:32:59 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361698379.06.0.778756474464.issue16801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It's particular because there are functions whose signatures can't be expressed with valid Python syntax (dict, range, operator.methodcaller, many curses functions). They required other solution and this more general solution is applicable for the problem of nonstandard representation of default values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Sun Feb 24 10:41:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Feb 2013 09:41:43 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1361698903.08.0.370267722465.issue17100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps for consistency with popitem() and move_to_end() it is worth to merge rotate_at() and rotate_after() in one method (rotate_to()? move_to()?) with a boolean parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17100>
_______________________________________

From report at bugs.python.org  Sun Feb 24 10:47:20 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Feb 2013 09:47:20 +0000
Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess
In-Reply-To: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za>
Message-ID: <1361699240.48.0.740422635588.issue16945@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


Added file: http://bugs.python.org/file29219/cgi_subprocess-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16945>
_______________________________________

From report at bugs.python.org  Sun Feb 24 10:59:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 24 Feb 2013 09:59:18 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361699958.37.0.0876386476494.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I'm going to start proposing smaller issues off of this one

I still fail to understand what are you trying to achieve.  If you want to further dissect my patches, hand picking chunks and reorder them in order to obtain even more patches, I'll just close this issue and let you do what you think it's best -- but I'm not going to spend more time on this.

Otherwise I will commit my patches as they are, either all together or one by one or anything in the middle -- you pick the granularity you like most.  After that it's done you can open other issues to further improve what we have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Sun Feb 24 11:27:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2013 10:27:06 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1361698903.08.0.370267722465.issue17100@psf.upfronthosting.co.za>
Message-ID: <1361701417.3480.0.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> Perhaps for consistency with popitem() and move_to_end() it is worth
> to merge rotate_at() and rotate_after() in one method (rotate_to()?
> move_to()?) with a boolean parameter.

Yes, perhaps. rotate_to(last=False) sounds ok, but perhaps a native
English speaker can suggest a better name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17100>
_______________________________________

From report at bugs.python.org  Sun Feb 24 12:34:51 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 24 Feb 2013 11:34:51 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361705691.46.0.793470875154.issue17277@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The proposed patch fixes the backtrace line numbers issue, but it does not fix
PyFrame_GetLineNumber() which is the recommended way to get the frame line
number.

As mentionned in the original message, testing for f->f_trace to implement the
f_lineno getter is not correct. The f_lineno setter is also wrong in allowing to
modify f_lineno when the frame is not the one that is being traced (pdb prevents
that to happen though, in do_jump()).

I am working on another patch that should fix the issue by changing
PyFrame_GetLineNumber() and the f_lineno accessors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Sun Feb 24 12:43:50 2013
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 24 Feb 2013 11:43:50 +0000
Subject: [issue17285] subprocess.check_output incorrectly state that output is
	always bytes
Message-ID: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur:

Documentation states:

>>> help( subprocess.check_output )
check_output(*popenargs, timeout=None, **kwargs)
    Run command with arguments and return its output as a byte string.

But the most common usage is:
>>> subprocess.check_output( 'echo test', shell=True, universal_newlines=True )
'test\n'

Which obviously output a text string, not a byte string.

IMHO, one of the example should also be modified to show the existence of this flag, as it is what user want 90% of the times.

----------
assignee: docs at python
components: Documentation
messages: 182868
nosy: Baptiste.Lepilleur, docs at python
priority: normal
severity: normal
status: open
title: subprocess.check_output incorrectly state that output is always bytes
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17285>
_______________________________________

From report at bugs.python.org  Sun Feb 24 12:44:52 2013
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Sun, 24 Feb 2013 11:44:52 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
	VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1361706292.15.0.630133625423.issue7511@psf.upfronthosting.co.za>


Takayuki SHIMIZUKAWA added the comment:

FYI. I was able to build both 32bit/64bit.

Python 2.7.3 (32bit)
WinXP Professional SP3 (x86)
Visual Studio C++ Express 2008 SP1
Microsoft Windows SDK 2008

invoke Windows SDK's `CMD Shell` and do following:

C:\tmp> setenv /x64 /release
C:\tmp> set libpath=dummy
C:\tmp> python setup.py build --plat-name=win-amd64 build_ext --library_dirs=C:\Python27\libs-amd64

details is here: http://www.freia.jp/taka/blog/python-win32-binary-building-and-x64-cross-compiling-on-32bit-platform/index.html

----------
nosy: +shimizukawa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Sun Feb 24 12:50:04 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2013 11:50:04 +0000
Subject: [issue17192] libffi-3.0.12 import
In-Reply-To: <1360677172.63.0.353475776128.issue17192@psf.upfronthosting.co.za>
Message-ID: <1361706604.18.0.990515948372.issue17192@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Updating 3.x branches is fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17192>
_______________________________________

From report at bugs.python.org  Sun Feb 24 12:52:57 2013
From: report at bugs.python.org (Giovanni Bajo)
Date: Sun, 24 Feb 2013 11:52:57 +0000
Subject: [issue12226] use HTTPS by default for uploading packages to pypi
In-Reply-To: <1306860665.45.0.32361907398.issue12226@psf.upfronthosting.co.za>
Message-ID: <1361706777.57.0.0295727115498.issue12226@psf.upfronthosting.co.za>


Giovanni Bajo added the comment:

Please notice that a redesign of PyPI and package security is ongoing in catalog-sig.

----------
nosy: +Giovanni.Bajo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sun Feb 24 13:20:55 2013
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 24 Feb 2013 12:20:55 +0000
Subject: [issue17286] Make subprocess handling text output with
	universal_newlines more obious
Message-ID: <1361708455.88.0.426093416103.issue17286@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur:

It tooks me a while to figure out that using universal_newlines was the solution to "tell" subprocess that I wanted text string output instead of byte string.

A search on stackoverflow shows that this issue is common and the solution nearly unknown (answer is usually to decode the byte string manually)...

Because dealing with text output is IMHO the most common use case, the subprocess documentation should make it easier to "find" the recipe.

I would suggest changing the documentation so that the universal_newlines is made obvious as it is very important:
1) the first /bin/vikings example be modified to show the use of this flag (at the top of the documentation, most people copy/past that):
  >>> p = subprocess.Popen(args, universal_newlines=True) # Success!
  and at a small comment below the example to explain that flag
2) change other example similarly when that make sense, IMHO:
   - ifconfig example
   - one of the subprocess.check_output example
   - subprocess.check_output() example, consider separating the byte string / text string example for increased visibility
3) consider adding a section with an obvious title "Dealing with binary and text input/output", providing examples and pointer to the correct documentation (I would place it after the convenience functions section for visibility). I think this would help attracting "eye" on this large piece of documentation.

----------
assignee: docs at python
components: Documentation
messages: 182872
nosy: Baptiste.Lepilleur, docs at python
priority: normal
severity: normal
status: open
title: Make subprocess handling text output with universal_newlines more obious
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17286>
_______________________________________

From report at bugs.python.org  Sun Feb 24 13:40:24 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Sun, 24 Feb 2013 12:40:24 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1361709624.42.0.904639279986.issue11063@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

Jyrki, roundup doesn?t seem to recognize you patch so we can?t review it in Rietveld. Could you re-try, maybe using hg?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sun Feb 24 13:49:20 2013
From: report at bugs.python.org (Elazar Gershuni)
Date: Sun, 24 Feb 2013 12:49:20 +0000
Subject: [issue17287] slice inconsistency
Message-ID: <1361710160.02.0.405810839131.issue17287@psf.upfronthosting.co.za>


New submission from Elazar Gershuni:

slice behavior is not consistent for negative lower or upper arguments, which could be surprising:

>>> 'hello'[:-2]
'hel'
>>> 'hello'[:-1]
'hell'
>>> 'hello'[:-0]
''

this is obvious when written as literal, but not so obvious when using variables in expressions like 'fullname[:-len(lastname)]'. same goes for 'lower'.

----------
components: None
messages: 182874
nosy: elazar
priority: normal
severity: normal
status: open
title: slice inconsistency
type: enhancement
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17287>
_______________________________________

From report at bugs.python.org  Sun Feb 24 14:16:36 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 24 Feb 2013 13:16:36 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1361711796.05.0.30025480402.issue11063@psf.upfronthosting.co.za>


Changes by Jyrki Pulliainen <jyrki at dywypi.org>:


Removed file: http://bugs.python.org/file29189/issue11063_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sun Feb 24 14:17:13 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 24 Feb 2013 13:17:13 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1361711833.0.0.440611063501.issue11063@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Here's a second take on the patch

----------
Added file: http://bugs.python.org/file29220/issue11063_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Sun Feb 24 14:25:06 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sun, 24 Feb 2013 13:25:06 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361712306.88.0.945752729205.issue15305@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Both are called at different points when running './python.exe -m test -j3':
1. In __main__.py, this is called once at the start of the test run. By putting TESTCWD as the first/name arg, the directory is created.
2. In regrtest.py, the main file is called per test.

The support.temp_cwd command was raising a warning if the directory already existed. I've updated this to no longer raise a warning, although it will still try to create it. Passing it in explicitly as the path= argument would have it not try to create the directory.

----------
Added file: http://bugs.python.org/file29221/issue15305-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Sun Feb 24 16:08:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 15:08:06 +0000
Subject: [issue17285] subprocess.check_output incorrectly state that output is
	always bytes
In-Reply-To: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>
Message-ID: <1361718486.31.0.0632312411523.issue17285@psf.upfronthosting.co.za>


R. David Murray added the comment:

IMO the statement should read "and return the stdout data".  The point is that check_output calls Popen and accepts all its arguments except for stdout, which it handles itself and returns as the result.  It would probably be good to then follow that up with something like "This will be bytes unless universal_newlines is set True".

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17285>
_______________________________________

From report at bugs.python.org  Sun Feb 24 16:14:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 15:14:36 +0000
Subject: [issue17287] slice inconsistency
In-Reply-To: <1361710160.02.0.405810839131.issue17287@psf.upfronthosting.co.za>
Message-ID: <1361718876.85.0.0209223432846.issue17287@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the report, but this is working as designed, and is a fundamental part of the design of slices.

That said, I have no idea what you are referring to by saying it is inconsistent, and what is "upper" and "lower" referring to?

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17287>
_______________________________________

From report at bugs.python.org  Sun Feb 24 17:57:43 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 24 Feb 2013 16:57:43 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361725063.54.0.568830411689.issue17277@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> fix the issue by changing PyFrame_GetLineNumber() and the f_lineno accessors

The new patch named traced_frame.patch has been uploaded.

Also, now it is not allowed anymore to set the f_lineno attribute of a frame
that is not the frame being traced, as f_lasti is invalidated anyway on
returning to the evaluation of that frame.

----------
Added file: http://bugs.python.org/file29222/traced_frame.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Sun Feb 24 18:26:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 24 Feb 2013 17:26:53 +0000
Subject: [issue17288] cannot jump from a return after setting f_lineno
Message-ID: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

On python 3.3 and the default branch, the jump from a 'return' fails although
the change to f_lineno is validated, see below.

This problem does not occur with python 2.7.

$ python return.py
> /tmp/return.py(8)<module>()
-> foo()
(Pdb) break 5
Breakpoint 1 at /tmp/return.py:5
(Pdb) continue
> /tmp/return.py(5)foo()
-> lineno = 5
(Pdb) step
--Return--
> /tmp/return.py(5)foo()->None
-> lineno = 5
(Pdb) jump 4
> /tmp/return.py(4)foo()->None
-> lineno = 4
(Pdb) where
  /tmp/return.py(8)<module>()
-> foo()
> /tmp/return.py(4)foo()->None
-> lineno = 4
(Pdb) step
--Return--
> /tmp/return.py(8)<module>()->None
-> foo()
(Pdb)

----------
components: Interpreter Core
files: return.py
messages: 182880
nosy: xdegaye
priority: normal
severity: normal
status: open
title: cannot jump from a return after setting f_lineno
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29223/return.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Sun Feb 24 18:31:50 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 24 Feb 2013 17:31:50 +0000
Subject: [issue17288] cannot jump from a return after setting f_lineno
In-Reply-To: <1361726813.15.0.719765769531.issue17288@psf.upfronthosting.co.za>
Message-ID: <1361727110.61.0.65313239219.issue17288@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Oops, it occurs too with python 2.7.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17288>
_______________________________________

From report at bugs.python.org  Sun Feb 24 18:32:30 2013
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 24 Feb 2013 17:32:30 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361727150.19.0.395581090507.issue17279@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17279>
_______________________________________

From report at bugs.python.org  Sun Feb 24 18:32:42 2013
From: report at bugs.python.org (Bradley Froehle)
Date: Sun, 24 Feb 2013 17:32:42 +0000
Subject: [issue17289] readline.set_completer_delims() doesn't play well with
	others
Message-ID: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za>


New submission from Bradley Froehle:

The `readline.set_completer_delims` doesn't play well with others because
it assumes that only it ever allocates or modifies the
rl_completer_word_break_characters buffer.  If other programs modify this
value, for example changing it from heap allocated space to stack
allocated space, the results can be catastrophic.

To remind you, the function essentially works as:

    set_completer_delims(PyObject *self, PyObject *args)
    {
        // ...
        free((void*) rl_completer_word_break_characters;
        rl_completer_word_break_characters = strdup(break_chars);
        // ...
    }

where `break_chars` is the user provided string.

Take, for example, R as another programs which changes the readline
completer strings.  When an embedded R instance is initialized (say, using
`r2py`) something similar to the following takes place::

    static void
    set_rl_completer_word_break_characters(const char *new)
    {
        static char[201] buffer;
        strncpy(buffer, new, 200);
        rl_completer_word_break_characters = buffer;
    }

    static void
    initialize_embedded_R(...)
    {
        // ...
        set_rl_completer_word_break_characters(...);
    }

As you might expect the next trip through `readline.set_completer_delims`
after initializing R will be catastrophic when we attempt to free a stack
allocate buffer.

I think we should consider modifying the `readline.set_completer_delims`
to store the allocated buffers in the module state::

    set_completer_delims(PyObject *self, PyObject *args)
    {
        // ...
        free(_readlinestate_global->break_chars);
        rl_completer_word_break_characters = strdup(break_chars);
        _readlinestate_global->break_chars = rl_completer_word_break_characters;
        // ...
    }

This would prevent the segfault and memory leaks, and would render weird
hacks (like https://bitbucket.org/lgautier/rpy2/commits/408bae913653 in
the r2py code) unnecessary.

----------
components: Extension Modules
messages: 182882
nosy: bfroehle
priority: normal
severity: normal
status: open
title: readline.set_completer_delims() doesn't play well with others
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17289>
_______________________________________

From report at bugs.python.org  Sun Feb 24 19:17:56 2013
From: report at bugs.python.org (Carlo Bramini)
Date: Sun, 24 Feb 2013 18:17:56 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1361729876.44.0.281755885526.issue10560@psf.upfronthosting.co.za>


Carlo Bramini added the comment:

Hello,
no problem, the fix on GetModuleHandle() can be avoided without problems if you want. Anyways, although nowadays the "hybrid" operating systems like Windows 9x/ME are dead and burried, in this particular case I would still suggest to use directly GetModuleHandleA(), because the instance to find is just "KERNEL32" and it is not made by esoteric characters. Normally, as developer for Windows platform, I would surely agree to use the wide char version, but due to the highly portable nature of Python, with my experience I learned that some particular conditions can make the cross compiling for Windows easier, if you do not explicitely add "-fshort-wchar".
BTW, the ".dll" in the string of the parameter is redundant as you can see from MSDN page of GetModuleHandle(), there are also few other points in the sources of Python that can be "optimized", but afterall these are just "fine" improvements, not so much important if they are compared to other things...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sun Feb 24 20:20:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Feb 2013 19:20:10 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1361733610.95.0.238468123497.issue17117@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Yep, the patch looks right, G?kcen! If you want to update the tests and docs that would be great, but obviously don't feel obliged to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17117>
_______________________________________

From report at bugs.python.org  Sun Feb 24 20:24:43 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Feb 2013 19:24:43 +0000
Subject: [issue17176] Document imp.NullImporter is NOT used anymore by import
In-Reply-To: <1360525827.54.0.547409827798.issue17176@psf.upfronthosting.co.za>
Message-ID: <1361733883.92.0.554102236128.issue17176@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The docs for NullImporter need to not mention that it is used with sys.path_importer_cache since it isn't. As for sys.path_importer_cache, it should say that None is inserted and not NullImporter. Both need a versionchanged notation of the switch from None to NullImporter, but sys.path_importer_cache needs a special mention that to be fully backwards-compatible to check for both None and NullImporter.

And just to make sure you are looking at the right docs, Andreas, your links were to the Python 2.7 docs. If you look at the top of the docs you will see a dropdown which lets you switch to the 3.3 or 3.4 docs easily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17176>
_______________________________________

From report at bugs.python.org  Sun Feb 24 20:27:21 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sun, 24 Feb 2013 19:27:21 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1361734041.18.0.343080636277.issue17117@psf.upfronthosting.co.za>


G?kcen Eraslan added the comment:

Of course. I have also commented on issue#17116 but I couldn't find the pyexpat test you mentioned. I would like to fix #17116 and #17115

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17117>
_______________________________________

From report at bugs.python.org  Sun Feb 24 20:27:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Feb 2013 19:27:49 +0000
Subject: [issue17116] xml.parsers.expat.(errors|model) don't set the
	__loader__ attribute
In-Reply-To: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za>
Message-ID: <1361734069.45.0.456912715145.issue17116@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The comment is out of date; I removed the test because it was constantly failing.

As for the patch, it looks correct, but I plan to make a change to Python so that __loader__ is set by default (see the dependent issue #17115). If I don't get to that change I will commit the patch, else it will implicitly get fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17116>
_______________________________________

From report at bugs.python.org  Sun Feb 24 20:32:18 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 24 Feb 2013 19:32:18 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1361734338.05.0.304977601061.issue17117@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Issue #17116 will be fixed by issue #17715 if you decide to tackle it. That bug will require C-level changes to the module type; just FYI.

Please consider a PSF contributor form, G?kcen, if you plan to continue to submit code (your importlib.util fixes are simple enough to not require anything yet, but tests added to that plus anything you do for issue #17115 will require the form in order for me to commit your code). Instructions can be found at http://www.python.org/psf/contrib/ .

And obviously thanks for taking a look at all of this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17117>
_______________________________________

From report at bugs.python.org  Sun Feb 24 20:36:12 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sun, 24 Feb 2013 19:36:12 +0000
Subject: [issue17117] Update importlib.util.module_for_loader/set_loader to
	set when __loader__ = None
In-Reply-To: <1359910174.55.0.468649614578.issue17117@psf.upfronthosting.co.za>
Message-ID: <1361734572.52.0.491495314956.issue17117@psf.upfronthosting.co.za>


G?kcen Eraslan added the comment:

I have already given my form to akheron during a Python sprint, I think he will submit it to PSF within a few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17117>
_______________________________________

From report at bugs.python.org  Sun Feb 24 21:10:00 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 24 Feb 2013 20:10:00 +0000
Subject: [issue15128] inspect raises exception when frames are misleading
	about source line numbers
In-Reply-To: <1340301668.18.0.785702018205.issue15128@psf.upfronthosting.co.za>
Message-ID: <1361736600.26.0.141030795158.issue15128@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Use of IOError might be a bit problematic. The find & get return IOError if they can't find the source, but for mismatch if the line is not found is not to me an IOError.

Btw, to be able to merge your patch, you need to sign the contributor agreement in here: http://www.python.org/psf/contrib/contrib-form-python/

----------
nosy: +nailor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15128>
_______________________________________

From report at bugs.python.org  Sun Feb 24 21:26:17 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 24 Feb 2013 20:26:17 +0000
Subject: [issue11480] Cannot copy a class with a metaclass other than type
In-Reply-To: <1300007060.0.0.461224143225.issue11480@psf.upfronthosting.co.za>
Message-ID: <1361737577.44.0.762903771214.issue11480@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Hi, to be able to include your patch, could you sign the contributor form, please: http://www.python.org/psf/contrib/ ?

----------
nosy: +nailor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11480>
_______________________________________

From report at bugs.python.org  Sun Feb 24 21:47:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2013 20:47:19 +0000
Subject: [issue13684] httplib tunnel infinite loop
In-Reply-To: <1325260587.05.0.642107056326.issue13684@psf.upfronthosting.co.za>
Message-ID: <1361738839.37.0.34140845656.issue13684@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13684>
_______________________________________

From report at bugs.python.org  Sun Feb 24 21:52:51 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Feb 2013 20:52:51 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1361739171.7.0.291001023982.issue1470548@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

This patch works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Sun Feb 24 21:53:23 2013
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 24 Feb 2013 20:53:23 +0000
Subject: [issue11480] Cannot copy a class with a metaclass other than type
In-Reply-To: <1300007060.0.0.461224143225.issue11480@psf.upfronthosting.co.za>
Message-ID: <1361739203.54.0.52586797262.issue11480@psf.upfronthosting.co.za>


Daniel Urban added the comment:

I did, and I've been told that it has been added to the bug tracker: http://mail.python.org/pipermail/python-committers/2012-May/001987.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11480>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:03:08 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sun, 24 Feb 2013 21:03:08 +0000
Subject: [issue11480] Cannot copy a class with a metaclass other than type
In-Reply-To: <1300007060.0.0.461224143225.issue11480@psf.upfronthosting.co.za>
Message-ID: <1361739788.73.0.578361882975.issue11480@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Oh, my bad. The * was not just showing next to your name. Maybe someone with more access rights can help?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11480>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:34:32 2013
From: report at bugs.python.org (netrick)
Date: Sun, 24 Feb 2013 21:34:32 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
Message-ID: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>


New submission from netrick:

Firstly, just to mention - the issue that I will describe doesn't exist in python 2.7. It is python3 and windows related (python 3.3 for sure, didn't test previous). I also tested it on 2 different PCs (one fresh windows install, second long running with different hardware), so it's not my OS messed up.

So - the issue appears with every gui script I tried (PySide and tkinter, various codes).  Basically when I have the script saved as "*.py", everything is great but there is unwanted console. So I save the script as "*.pyw" to run it using "pythonw" without console. When I run it  there is indeed no console, but for the first 10-15 seconds no matter what I do the cursor is "loading cursor", everywhere in Windows. (see the screen I uploaded to this issue). I can click everything but the cursor won't return to normal for about 15 secs. Of course, the cursor is normal when using standard python 3.3 (with console) or pythonw 2.7.

The code pasted from 3.3 documentation which reproduces the problem:

#START CODE
import tkinter as tk

class Application(tk.Frame):
    def __init__(self, master=None):
        tk.Frame.__init__(self, master)
        self.pack()
        self.createWidgets()

    def createWidgets(self):
        self.hi_there = tk.Button(self)
        self.hi_there["text"] = "Hello World\n(click me)"
        self.hi_there["command"] = self.say_hi
        self.hi_there.pack(side="top")

        self.QUIT = tk.Button(self, text="QUIT", fg="red",
                                            command=root.destroy)
        self.QUIT.pack(side="bottom")

    def say_hi(self):
        print("hi there, everyone!")

root = tk.Tk()
app = Application(master=root)
app.mainloop()
#END CODE

To sum up, the issue is present with pythonw 3.3 on Windows XP 32 bit.
BUT! When I typed in terminal:

ftype Python.File=C:\Python33\pythonw.exe "%1" %*

then every .py file started to be run using pythonw. What matters is in that case, there is no loading cursor at all! Add to it that in python 2.7 the issue doesn't exist and I think that in recent windows packages something with extensions is messed up. I have no idea what, but this stops me from using python3 for serious GUI development on windows (which is something I really want to do).

I wanted to write some commercial GUI apps using python, but I can't say my customers to type that line in terminal. Also, they won't accept terminal or 15 sec loading cursor. It's just unwanted thing. Right now I have to use python 2.7, but I like python 3 much more. I think it's something with the way ".pyw" extension is handled as something adds that loading cursor.

Python is the best, I hope that you will be able to fix it!

----------
components: Installation, Tkinter, Windows
files: AZb4toA.jpg
messages: 182895
nosy: netrick
priority: normal
severity: normal
status: open
title: pythonw - loading cursor bug when launching scripts
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file29224/AZb4toA.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:37:00 2013
From: report at bugs.python.org (Riley)
Date: Sun, 24 Feb 2013 21:37:00 +0000
Subject: [issue17291] Login-data raising EOFError
Message-ID: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>


New submission from Riley:

When running Pywikipediabot and retrieving a password I get the following error:
Password for user RileyBot on wiktionary:en: 
/usr/lib/python2.7/getpass.py:83: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
Traceback (most recent call last):
  File "globalfunc1.py", line 250, in <module>
    main()
  File "globalfunc1.py", line 244, in main
    bot.run()
  File "globalfunc1.py", line 197, in run
    sandboxPage.put(translatedContent, translatedMsg)
  File "/home/riley/pywikipedia/wikipedia.py", line 1990, in put
    sysop=sysop)
  File "/home/riley/pywikipedia/wikipedia.py", line 1863, in _getActionUser
    self.site().forceLogin(sysop = sysop)
  File "/home/riley/pywikipedia/wikipedia.py", line 5861, in forceLogin
    if loginMan.login(retry = True):
  File "/home/riley/pywikipedia/login.py", line 307, in login
    password = True)
  File "/home/riley/pywikipedia/wikipedia.py", line 8927, in input
    data = ui.input(question, password)
  File "/home/riley/pywikipedia/userinterfaces/terminal_interface_base.py", line 129, in input
    text = getpass.getpass('')
  File "/usr/lib/python2.7/getpass.py", line 83, in unix_getpass
    passwd = fallback_getpass(prompt, stream)
  File "/usr/lib/python2.7/getpass.py", line 118, in fallback_getpass
    return _raw_input(prompt, stream)
  File "/usr/lib/python2.7/getpass.py", line 135, in _raw_input
    raise EOFError
EOFError

While this may have something to do with Pywikipediabot, it all comes down to python. Help?

----------
components: None
messages: 182896
nosy: Riley
priority: normal
severity: normal
status: open
title: Login-data raising EOFError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17291>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:37:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2013 21:37:24 +0000
Subject: [issue17291] Login-data raising EOFError
In-Reply-To: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>
Message-ID: <1361741844.96.0.470680459847.issue17291@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17291>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:46:09 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Feb 2013 21:46:09 +0000
Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames
In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za>
Message-ID: <1361742369.91.0.828071909678.issue17094@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Thanks, it's surprising this was never noticed before.
Your patch has two issues:
- it doesn't clear the thread state before deleting it, which would leak the frame, thread-specific dict, etc
- it only clears the thread states after the current thread state: if the current thread is not at the head of the linked list - if it's not the most recently created thread - some thread states won't get cleared

I'm attaching a patch doing the cleanup in PyEval_ReInitThreads(), with test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17094>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:46:59 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Feb 2013 21:46:59 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361742419.44.0.221272761026.issue17290@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +brian.curtin, terry.reedy, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Sun Feb 24 22:59:37 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Feb 2013 21:59:37 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361658728.3600.7.camel@localhost.localdomain>
Message-ID: <CAH_1eM2MwYqcAnwtPaSKqCDn=XCndE6_Sp2UCgj_rzDZ-w=amA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I don't know how OS X crash report works, but it seems to have at
least some debug info available, since some ymbols are resolved in the
backtrace.
You might be able to get more info with gdb, with something like:
"""
gdb /path/to/python
(gdb) info line *<crash address>
(gdb) disassemble <crash address>
"""

Otherwise, is there are way to run your code on Linux?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Sun Feb 24 23:16:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 22:16:38 +0000
Subject: [issue1613500] Write mode option for fileinput module.
Message-ID: <1361744198.47.0.993572170811.issue1613500@psf.upfronthosting.co.za>


R. David Murray added the comment:

As far as I can see from a quick look, the problem this patch addresses still exists in Python3, and in Python3 it be (more of?) a bug.  That is, the output file is opened in text mode, regardless of whether the input mode was text or bytes.  I'm not sure about the solution; it seems like it makes more sense to deduce the output mode from the input mode.

The test changes, though, are obsolete.

----------
assignee: BreamoreBoy -> 
nosy: +r.david.murray
versions: +Python 3.5 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1613500>
_______________________________________

From report at bugs.python.org  Sun Feb 24 23:19:05 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 22:19:05 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361744345.44.0.775703254238.issue15305@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I don't think support.temp_cwd() should be changed for this issue (or needs to be).  Also, changing it in the proposed way could mask errors in the test suite since tests were written against the current behavior.

regrtest.py and __main__.py should both behave the same with respect to creating the temp dir, etc. since both invocations should work from the command-line:

http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Sun Feb 24 23:26:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 22:26:07 +0000
Subject: [issue17291] Login-data raising EOFError
In-Reply-To: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>
Message-ID: <1361744767.01.0.580145437795.issue17291@psf.upfronthosting.co.za>


R. David Murray added the comment:

My guess would be that stdin is closed.  I doubt that it is a python problem.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17291>
_______________________________________

From report at bugs.python.org  Sun Feb 24 23:36:15 2013
From: report at bugs.python.org (Joar Wandborg)
Date: Sun, 24 Feb 2013 22:36:15 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361745375.15.0.200229428244.issue17267@psf.upfronthosting.co.za>


Joar Wandborg added the comment:

I am adding yet another patch. This time it has

- TZ-aware tests (datetimetester.TestTimeTZ).
- C time_subtract method.
- Pure time.__sub__ method.

in addition to the previous

- Tests for time + timedelta
- C time_add
- Pure time.__add__

There's one issue though, and that is that I have not quite figured out TZ-aware cross-TZ `time - timedelta` i.e.

    time(0, tzinfo=est) - timedelta(hours=1) * 5 == time(0, tzinfo=utc)

fails.

I have included a failing test for it.

----------
Added file: http://bugs.python.org/file29225/issue17267-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Sun Feb 24 23:47:28 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 24 Feb 2013 22:47:28 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1361746048.73.0.699298013565.issue17226@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

Alan, I was about to file a bug as well because I'm not even getting a libintl dependency to be acknowledged under these build conditions.  What versions of gettext and GCC are you using?

Ned, not sure if it matters, but the libintl page does specify that -liconv must also be linked as it is a dependency:

http://www.gnu.org/software/gettext/FAQ.html#integrating_undefined

----------
nosy: +Jeffrey.Armstrong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Sun Feb 24 23:57:36 2013
From: report at bugs.python.org (Jeffrey Armstrong)
Date: Sun, 24 Feb 2013 22:57:36 +0000
Subject: [issue17226] libintl should also check for libiconv
In-Reply-To: <1361203207.64.0.112739633546.issue17226@psf.upfronthosting.co.za>
Message-ID: <1361746656.12.0.451668244026.issue17226@psf.upfronthosting.co.za>


Jeffrey Armstrong added the comment:

I would suggest a more straightforward patch.  My understanding is that the standard library on the m68k-atari-mint platform does not include the necessary gettext functionality.  This functionality is present in glibc, however.  A more direct test might be to see if gettext is available in the standard library.  If so, proceed.  If not, attempt to link in libintl and its dependency:

--- a/configure.ac	Sat Feb 23 18:52:51 2013 +0100
+++ b/configure.ac	Sun Feb 24 17:59:41 2013 -0500
@@ -2180,6 +2180,14 @@
 	[Define to 1 if libintl is needed for locale functions.])
         LIBS="-lintl $LIBS"])
 
+# search for gettext in either libc or libintl
+AC_CHECK_FUNC(gettext, [],
+	[AC_CHECK_LIB(intl, gettext, 
+                  [LIBS="$LIBS -lintl -liconv"],
+                  [AC_MSG_ERROR([unable to find the gettext() function])],
+                  [-liconv])
+    ])
+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17226>
_______________________________________

From report at bugs.python.org  Mon Feb 25 00:10:52 2013
From: report at bugs.python.org (netrick)
Date: Sun, 24 Feb 2013 23:10:52 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361747452.44.0.665883289842.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

I just want to add that it *may* be the issue with the new windows launcher introtuced in 3.3. Because in 2.7 everything runs great and running through "pythonw" command works flawlessy as well. I think it's worth to look into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 00:55:33 2013
From: report at bugs.python.org (Birk Nilson)
Date: Sun, 24 Feb 2013 23:55:33 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361750133.0.0.548347532537.issue16121@psf.upfronthosting.co.za>


Birk Nilson added the comment:

After investigating the issue I have a couple of proposals.

Although a bit vague, the documentation of shlex.lineo seems to suggest that it should be incremented immediately on finding a newline character. Changing this to allow wrapped lines within a token without incrementing the line number changes the existing shlex API. Something I believe should be avoided since netrc relies on the existing behavior and third-party modules might too.

Instead I recommend the following steps.
Step #1: Fix the immediate issue of getting different line numbers for the same input depending on whether posix=(True|False), but keep the current - greedy - behavior of shlex.lineo.
Step #2: A separate patch introduces shlex.wrapped_lineo which does not increment the lineno immediately, but prior to reading the next token - as introduced in my previous patch.

Step #2 should arguably be introduced in a separate issue - if at all - since it is a new feature to the shlex API.

I will provide a patch for #1 within the next day or two along with one for #2 if you guys think it is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Mon Feb 25 01:04:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Feb 2013 00:04:34 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1361750674.87.0.592762086645.issue16121@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is it necessarily a bug if the behavior is different with posix=True or False?  If I understand correctly, non-posix mode is a backward compatibility mode, and really nobody "should" be using non-posix mode any more :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Mon Feb 25 01:26:54 2013
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 25 Feb 2013 00:26:54 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1361752014.69.0.866676289311.issue10952@psf.upfronthosting.co.za>


Changes by Atsuo Ishimoto <ishimoto at gembook.org>:


----------
nosy: +ishimoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Mon Feb 25 01:40:44 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Feb 2013 00:40:44 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361752844.97.0.436440905916.issue16801@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Your indeed cumbersome and overly specific process has almost nothing to do with what I proposed and gave two examples of. Please reread and understand msg178542 before you criticize it.

Class octint pythonically solves the octal mode display problem that started this issue, and in my opinion about as elegantly as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Mon Feb 25 02:09:46 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 25 Feb 2013 01:09:46 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
In-Reply-To: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>
Message-ID: <1361754586.21.0.583062496675.issue17283@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching patch.

The use of "global TEMPDIR" isn't ideal.  Alternatively, TEMPDIR's value when sysconfig.is_python_build() is true can be set when initially setting TEMPDIR:

http://hg.python.org/cpython/file/96f08a22f562/Lib/test/regrtest.py#l203

----------
keywords: +patch
Added file: http://bugs.python.org/file29226/issue-17283-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Mon Feb 25 02:09:52 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 25 Feb 2013 01:09:52 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
In-Reply-To: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>
Message-ID: <1361754592.53.0.606627619511.issue17283@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Mon Feb 25 02:17:57 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 Feb 2013 01:17:57 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361755077.76.0.703275165443.issue16801@psf.upfronthosting.co.za>


Larry Hastings added the comment:

FWIW I think the octint class is a great idea.  It's nice and localized, and it should have no performance impact and only a small maintenance impact.  It'll also preserve the readability of the default if you pull it out with inspect.getfullargspec / inspect.Signature and repr it.  I'm not sure how IDLE et all produce their tooltips, but whatever technique they use octint should work there.  Heck, it should even survive calculations for default values (as I mentioned in the original post), assuming that int + octint = octint.

Is there a significant downside to octint that I'm missing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Mon Feb 25 03:51:34 2013
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Mon, 25 Feb 2013 02:51:34 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1361760694.06.0.297040436495.issue10952@psf.upfronthosting.co.za>


Atsuo Ishimoto added the comment:

Converting identifiers to NFKC is problematic to work with FULLWIDTH letters such as '?'(FULLWIDTH LATIN SMALL LETTER A).

We can create module named '???.py', but this module could not be imported on all platforms I know.

>>> import ???
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'aaa'

Talking about Japanese environment, I don't see benefit to normalize variable names. FULLWIDTH/HALFWIDTH compatibility characters are commonly used here, and they are recognized different characters.  It would be too late to argue, but converting to normal form NKC instead of NFKC would be better. Python distinguishes small letters and large letters, but doesn't distinguish fullwidth and halfwidth. This is a pretty surprising behavior to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Mon Feb 25 04:03:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Feb 2013 03:03:01 +0000
Subject: [issue10952] Don't normalize module names to NFKC?
In-Reply-To: <1295488499.02.0.313090900295.issue10952@psf.upfronthosting.co.za>
Message-ID: <1361761381.23.0.999056668966.issue10952@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10952>
_______________________________________

From report at bugs.python.org  Mon Feb 25 04:19:48 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Feb 2013 03:19:48 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361762388.85.0.107480034626.issue17223@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Even if deprecated it should continue to work (if possible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 25 04:23:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Feb 2013 03:23:04 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361762584.32.0.643359038334.issue10572@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Naming of files has been kept the same in the move from
> Lib/sqlite/test, to allow for easier merging of future patches.

This should be done with "hg mv" -- this will also allow to change the name while preserving the history if that's desirable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Feb 25 04:42:20 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 25 Feb 2013 03:42:20 +0000
Subject: [issue16406] move the "Uploading Packages" section to
	distutils/packageindex.rst
In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za>
Message-ID: <1361763740.0.0.74460415329.issue16406@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Attaching an improved patch.

This patch improves the introductory wording, adds some additional hyperlinks, and changes the order of one of the inserted sections.

----------
Added file: http://bugs.python.org/file29227/issue-16406-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16406>
_______________________________________

From report at bugs.python.org  Mon Feb 25 05:15:41 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 25 Feb 2013 04:15:41 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
In-Reply-To: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>
Message-ID: <1361765741.51.0.0443296851351.issue17283@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Here is a new patch which does not use the global keyword.

----------
Added file: http://bugs.python.org/file29228/issue-17283-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Mon Feb 25 05:54:47 2013
From: report at bugs.python.org (Nathan Binkert)
Date: Mon, 25 Feb 2013 04:54:47 +0000
Subject: [issue17292] Autonumbering in string.Formatter doesn't work
Message-ID: <1361768087.85.0.505159219434.issue17292@psf.upfronthosting.co.za>


New submission from Nathan Binkert:

Autonumbering with string.format does not work as it does in str.format:

>>> '{}'.format(1)
'1'
>>> import string
>>> string.Formatter().format('{}', 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/nate/src/python3/Lib/string.py", line 164, in format
    return self.vformat(format_string, args, kwargs)
  File "/Users/nate/src/python3/Lib/string.py", line 168, in vformat
    result = self._vformat(format_string, args, kwargs, used_args, 2)
  File "/Users/nate/src/python3/Lib/string.py", line 190, in _vformat
    obj, arg_used = self.get_field(field_name, args, kwargs)
  File "/Users/nate/src/python3/Lib/string.py", line 253, in get_field
    obj = self.get_value(first, args, kwargs)
  File "/Users/nate/src/python3/Lib/string.py", line 210, in get_value
    return kwargs[key]

----------
components: Library (Lib)
messages: 182916
nosy: binkert
priority: normal
severity: normal
status: open
title: Autonumbering in string.Formatter doesn't work
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17292>
_______________________________________

From report at bugs.python.org  Mon Feb 25 06:09:52 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 Feb 2013 05:09:52 +0000
Subject: [issue17292] Autonumbering in string.Formatter doesn't work
In-Reply-To: <1361768087.85.0.505159219434.issue17292@psf.upfronthosting.co.za>
Message-ID: <1361768992.03.0.401441208283.issue17292@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17292>
_______________________________________

From report at bugs.python.org  Mon Feb 25 06:28:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Feb 2013 05:28:26 +0000
Subject: [issue8936] webbrowser regression on windows
In-Reply-To: <1275968801.71.0.456370362373.issue8936@psf.upfronthosting.co.za>
Message-ID: <1361770106.01.0.673110893306.issue8936@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The regression issue is red herring. An issue should propose new behavior (based on an understanding of the doc and actual current behavior). Then ask: "Is the proposed behavior better than the current behavior?", and "Is the current behavior a bug?". After reading the doc and the code, I am convinced that current behavior is close to the implied wanted behavior, and that it is not a bug.

The doc says
 webbrowser.open(url, new=0, autoraise=True)
    Display url using the default browser.

What does 'default browswer' mean? Near the top, the doc says "If the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers,". So the 'default browser' is actually the 'default browser list'. What open() does is to try each in turn and stop when one says it succeeded. So the doc should say 'using the first default browser that claims to succeed.'

What does 'default browser list' mean? It depends on the platform *and* the software loaded on the particular machine when webbrowser is first imported in a particular instance of the interpreter. The 'platform' part is in the quote above, the rest is not. I will open a separate doc issue.

On Windows, the list starts with 'default Windows browser', which calls os.startfile(), which, I believe, does call the user default browser. Next is Internet Explorer -- if available at that time on the particular machine! If the user-default browser rejects the url, then IE is tried.

On my win7 machine today, I have Firefox the default and IE available. Firefox rejects 127.0.0.1:8080 with an 'Unable to connect' error box. IE 'accepts' it in the sense that it displays an information starting 'The webpage cannot be displayed'. For 'invalid.xxx', IE displays the page for a German domain registrar. I strongly suspect that the change Anatoly saw was a difference in IE, out of Python's control.

Georg, if you think I got it wrong, please correct.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8936>
_______________________________________

From report at bugs.python.org  Mon Feb 25 06:29:44 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 25 Feb 2013 05:29:44 +0000
Subject: [issue17291] Login-data raising EOFError
In-Reply-To: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>
Message-ID: <1361770184.67.0.222904379121.issue17291@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

yeah that looks like stdin was closed or was /dev/null.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17291>
_______________________________________

From report at bugs.python.org  Mon Feb 25 06:49:10 2013
From: report at bugs.python.org (Riley)
Date: Mon, 25 Feb 2013 05:49:10 +0000
Subject: [issue17291] Login-data raising EOFError
In-Reply-To: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>
Message-ID: <1361771350.86.0.15177441529.issue17291@psf.upfronthosting.co.za>


Riley added the comment:

The script is being run from a cronjob with saved login data. And thus, there is no stdin for cronjobs as there's no attached terminal. Reopening.

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17291>
_______________________________________

From report at bugs.python.org  Mon Feb 25 06:52:37 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 25 Feb 2013 05:52:37 +0000
Subject: [issue17291] Login-data raising EOFError
In-Reply-To: <1361741820.39.0.315848674206.issue17291@psf.upfronthosting.co.za>
Message-ID: <1361771557.69.0.595426045452.issue17291@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

File "/home/riley/pywikipedia/userinterfaces/terminal_interface_base.py", line 129, in input
    text = getpass.getpass('')

you can't call getpass without stdin or a terminal and expect it to do anything.  your problem is in the pywikipedia code, not Python's getpass module.

http://docs.python.org/2/library/getpass.html

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17291>
_______________________________________

From report at bugs.python.org  Mon Feb 25 07:08:47 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Feb 2013 06:08:47 +0000
Subject: [issue16801] Preserve original representation for integers / floats
	in docstrings
In-Reply-To: <1356699853.91.0.313275944642.issue16801@psf.upfronthosting.co.za>
Message-ID: <1361772527.45.0.535325328719.issue16801@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Sorry, as with all similar subclasses, class op subclass = class unless one explicitly subclasses the answer or overrides the __op__ method to do that for you.

class octint(int):
    'int that displays as octal'
    def __str__(self):
        return oct(self)
    __repr__ = __str__

mode = octint(0o640)
print(mode + 4, octint(mode+4))

def __add__(self, other):
    return octint(int.__add__(self, other))
    # octint(self+other) is infinite recursion 

octint.__add__ = __add__
print(mode+4)
>>> 
420 0o644
0o644

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16801>
_______________________________________

From report at bugs.python.org  Mon Feb 25 07:18:45 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Feb 2013 06:18:45 +0000
Subject: [issue10799] Improve webbrowser (.open) doc and behavior
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1361773125.86.0.708751118208.issue10799@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Before closing #8936, I realized that perhaps my user default browser *is* being called but is returning an error code. It does not really matter, where the error code comes from. I think 'using the default browser' should be expanded to ''using the first default browser that claims to succeed.'. Also, 'default browser list' should be explained in a sentence before the one about over-riding it with an env. var. It depends on the software on the machine at import in addition to the platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10799>
_______________________________________

From report at bugs.python.org  Mon Feb 25 07:21:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Feb 2013 06:21:18 +0000
Subject: [issue10799] Improve webbrowser (.open) doc and behavior
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1361773278.49.0.42127907607.issue10799@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I no longer think we should touch the url; just pass it to each browser in turn, as needed, and let the user get the result.

----------
versions: +Python 3.3, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10799>
_______________________________________

From report at bugs.python.org  Mon Feb 25 07:43:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Feb 2013 06:43:13 +0000
Subject: [issue16997] subtests
In-Reply-To: <1358543231.78.0.354364612897.issue16997@psf.upfronthosting.co.za>
Message-ID: <1361774593.69.0.189264294869.issue16997@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

My day job these days is to work on the Beaker test system (http://beaker-project.org).

I realised today that it actually includes a direct parallel to Antoine's proposed subtest concept: whereas in unittest, each test currently has exactly one result, in Beaker a given task may have *multiple* results. The overall result of the task is then based on the individual results (so if any result is a failure, the overall test is a failure).

"tasks" are the smallest addressable unit in deciding what to run, but each task may report multiple results, allowing fine-grained reporting of what succeeded and what failed.

That means there's a part of Antoine's patch I disagree with: the change to eliminate the derived "overall" result attached to the aggregate test. I think Beaker's model, where there's a single result for the overall task (so you can ignore the individual results if you don't care), and the individual results are reported separately (if you do care), will make it easier to provide something that integrates cleanly with existing test runners.

The complexity involved in attempting to get expectedFailure() to behave as expected is also a strong indication that there are still problems with the way these results are being aggregated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16997>
_______________________________________

From report at bugs.python.org  Mon Feb 25 08:29:08 2013
From: report at bugs.python.org (=?utf-8?q?Aivars_Kalv=C4=81ns?=)
Date: Mon, 25 Feb 2013 07:29:08 +0000
Subject: [issue17293] uuid.getnode() MAC address on AIX
Message-ID: <1361777348.15.0.791534887595.issue17293@psf.upfronthosting.co.za>


New submission from Aivars Kalv?ns:

uuid.getnode() on AIX returned random integer. This patch finds MAC in output of `netstat -ia`.
Tested on AIX 5.2

----------
components: Library (Lib)
files: aix_mac.patch
keywords: patch
messages: 182925
nosy: aivarsk
priority: normal
severity: normal
status: open
title: uuid.getnode() MAC address on AIX
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file29229/aix_mac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17293>
_______________________________________

From report at bugs.python.org  Mon Feb 25 08:50:24 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Mon, 25 Feb 2013 07:50:24 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361778624.73.0.498020488521.issue10572@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

The move will need to be done by someone with commit access. These patches came from using hg mv.

After doing the move, there is some cleanup needed in each. These changes are included in the attached patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Feb 25 10:12:28 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 25 Feb 2013 09:12:28 +0000
Subject: [issue17292] Autonumbering in string.Formatter doesn't work
In-Reply-To: <1361768087.85.0.505159219434.issue17292@psf.upfronthosting.co.za>
Message-ID: <1361783548.22.0.836307109789.issue17292@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

This is a duplicate of issue 13598. I'll add you to nosy over there.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17292>
_______________________________________

From report at bugs.python.org  Mon Feb 25 10:13:23 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 25 Feb 2013 09:13:23 +0000
Subject: [issue13598] string.Formatter doesn't support empty curly braces "{}"
In-Reply-To: <1323835162.4.0.792542335688.issue13598@psf.upfronthosting.co.za>
Message-ID: <1361783603.68.0.216926836452.issue13598@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +binkert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13598>
_______________________________________

From report at bugs.python.org  Mon Feb 25 11:38:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 10:38:38 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>
Message-ID: <3ZF04Y6MrTzSxM@mail.python.org>


Roundup Robot added the comment:

New changeset 422169310b7c by Giampaolo Rodola' in branch 'default':
Fix #17197: profile/cProfile modules refactored so that code of run() and runctx() utility functions is not duplicated in both modules.
http://hg.python.org/cpython/rev/422169310b7c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Mon Feb 25 11:43:23 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Feb 2013 10:43:23 +0000
Subject: [issue17197] c/profile refactoring
In-Reply-To: <1360708809.53.0.302633878748.issue17197@psf.upfronthosting.co.za>
Message-ID: <1361789003.29.0.303278292188.issue17197@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee:  -> giampaolo.rodola
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17197>
_______________________________________

From report at bugs.python.org  Mon Feb 25 12:17:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Feb 2013 11:17:38 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361791058.44.0.992711270987.issue15083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which converts all etree doctests to unittests.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file29230/test_xml_etree.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Mon Feb 25 12:32:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 11:32:14 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <3ZF1GP2mPrzSwK@mail.python.org>


Roundup Robot added the comment:

New changeset d707e3345a74 by Serhiy Storchaka in branch '2.7':
Issue #1470548: Do not buffer XMLGenerator output.
http://hg.python.org/cpython/rev/d707e3345a74

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Mon Feb 25 12:49:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 11:49:19 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <3ZF1f64sqLzQkF@mail.python.org>


Roundup Robot added the comment:

New changeset 1c03e499cdc2 by Serhiy Storchaka in branch '3.2':
Issue #1470548: Add test for fragment producing with XMLGenerator.
http://hg.python.org/cpython/rev/1c03e499cdc2

New changeset 5a4b3094903f by Serhiy Storchaka in branch '3.3':
Issue #1470548: Add test for fragment producing with XMLGenerator.
http://hg.python.org/cpython/rev/5a4b3094903f

New changeset 810d70fb17a2 by Serhiy Storchaka in branch 'default':
Issue #1470548: Add test for fragment producing with XMLGenerator.
http://hg.python.org/cpython/rev/810d70fb17a2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Mon Feb 25 12:50:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Feb 2013 11:50:36 +0000
Subject: [issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)
Message-ID: <1361793036.13.0.190838976757.issue1470548@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1470548>
_______________________________________

From report at bugs.python.org  Mon Feb 25 13:07:22 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Feb 2013 12:07:22 +0000
Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace
In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za>
Message-ID: <1361794042.06.0.749176588524.issue16446@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

There is an error in my patch (already fixed in pdb-clone) and in Jyrki's patch.
Running Jyrki's patch on quit.py produces the following output where the line
number in the last entry of the backtrace is incorrect (should be line 9 instead
of line 7):

$ python quit.py
--Return--
> /tmp/quit.py(4)bar()->None
-> pdb.Pdb().set_trace()
(Pdb) quit
Traceback (most recent call last):
  File "quit.py", line 11, in <module>
    foo()
  File "quit.py", line 7, in foo
    bar()
ZeroDivisionError: integer division or modulo by zero

This problem does not occur when issue 17277 is fixed.
Meanwhile the attached patch, based on Jyrki's patch and based on the 2.7
branch, fixes this.

----------
Added file: http://bugs.python.org/file29231/quit.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16446>
_______________________________________

From report at bugs.python.org  Mon Feb 25 13:08:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Feb 2013 12:08:53 +0000
Subject: [issue16446] pdb raises BdbQuit on 'quit' when started with set_trace
In-Reply-To: <1352416193.43.0.475440625813.issue16446@psf.upfronthosting.co.za>
Message-ID: <1361794133.82.0.825030933084.issue16446@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch changes the semantics of the quit command: quit behaves like the gdb
detach command when pdb is started with set_trace.

----------
Added file: http://bugs.python.org/file29232/branch-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16446>
_______________________________________

From report at bugs.python.org  Mon Feb 25 14:11:26 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 25 Feb 2013 13:11:26 +0000
Subject: [issue17294] compile-flag for single-execution to return value
	instead of printing it
Message-ID: <1361797886.48.0.856864897447.issue17294@psf.upfronthosting.co.za>


New submission from Albert Zeyer:

`compile(s, "<interactive>", "single")` would generate a code object which prints the value of the evaluated string if that is an expression. This is what you would normally want in a REPL.

Instead of printing the value, it might make more sense to return it and to leave it to the developer - there are many cases where it shouldn't end up on stdout but somewhere else.

There could be an additional compile-flag which would make a code-object returning the value instead of printing it.

Note that I have come up with a workaround:

def interactive_py_compile(source, filename="<interactive>"):
    c = compile(source, filename, "single")

    # we expect this at the end:
    #   PRINT_EXPR     
    #   LOAD_CONST
    #   RETURN_VALUE    
    import dis
    if ord(c.co_code[-5]) != dis.opmap["PRINT_EXPR"]:
        return c
    assert ord(c.co_code[-4]) == dis.opmap["LOAD_CONST"]
    assert ord(c.co_code[-1]) == dis.opmap["RETURN_VALUE"]

    code = c.co_code[:-5]
    code += chr(dis.opmap["RETURN_VALUE"])

    CodeArgs = [
        "argcount", "nlocals", "stacksize", "flags", "code",
        "consts", "names", "varnames", "filename", "name",
        "firstlineno", "lnotab", "freevars", "cellvars"]
    c_dict = dict([(arg, getattr(c, "co_" + arg)) for arg in CodeArgs])
    c_dict["code"] = code

    import types
    c = types.CodeType(*[c_dict[arg] for arg in CodeArgs])
    return c


My related StackOverflow question:
http://stackoverflow.com/questions/15059372/python-use-of-eval-in-interactive-terminal-how-to-get-return-value-what-compi

----------
components: Interpreter Core
messages: 182934
nosy: Albert.Zeyer
priority: normal
severity: normal
status: open
title: compile-flag for single-execution to return value instead of printing it
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17294>
_______________________________________

From report at bugs.python.org  Mon Feb 25 14:37:22 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 25 Feb 2013 13:37:22 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361799442.43.0.308714279488.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

The symbols are there because it is a library which exports all the symbols. Other debugging information are not there and I don't know any place where I can get them.

It currently cannot work on Linux in the same way because the GUI is Cocoa only right now. I'm trying to get it to run with another Python on Mac, though.

Note that in threadmodule.c, in local_clear, we are iterating through all threads:

    /* Remove all strong references to dummies from the thread states */
    if (self->key
        && (tstate = PyThreadState_Get())
        && tstate->interp) {
        for(tstate = PyInterpreterState_ThreadHead(tstate->interp);
            tstate;
            tstate = PyThreadState_Next(tstate))
            if (tstate->dict &&
                PyDict_GetItem(tstate->dict, self->key))
                PyDict_DelItem(tstate->dict, self->key);
    }

In PyDict_DelItem, if the GIL is released and meanwhile, the list of threadstates is altered, is that a problem for this loop? So maybe tstate becomes invalid there.

I also noticed this part in another backtrace of the same crash:

Thread 2:
0   libsystem_kernel.dylib          0x00007fff8a54e0fa __psynch_cvwait + 10
1   libsystem_c.dylib               0x00007fff85daaf89 _pthread_cond_wait + 869
2   org.python.python               0x000000010006f54e PyThread_acquire_lock + 96
3   org.python.python               0x000000010001d8e3 PyEval_RestoreThread + 61
4   org.python.python               0x0000000100053351 PyGILState_Ensure + 93
5   _objc.so                        0x0000000103b89b6e 0x103b80000 + 39790
6   libobjc.A.dylib                 0x00007fff880c6230 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464
7   libobjc.A.dylib                 0x00007fff880c85a2 (anonymous namespace)::AutoreleasePoolPage::tls_dealloc(void*) + 42
8   libsystem_c.dylib               0x00007fff85dad4fe _pthread_tsd_cleanup + 240
9   libsystem_c.dylib               0x00007fff85da69a2 _pthread_exit + 146
10  libsystem_c.dylib               0x00007fff85da674d _pthread_start + 338
11  libsystem_c.dylib               0x00007fff85d93181 thread_start + 13


This seems to be a non-Python thread, so PyGILState_Ensure would have created a new threadstate and this would have altered the list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Mon Feb 25 14:44:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 13:44:44 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <3ZF4CH578RzMZr@mail.python.org>


Roundup Robot added the comment:

New changeset 2528e4aea338 by Serhiy Storchaka in branch 'default':
Issue #17220: Little cleanup of _bootstrap.py.
http://hg.python.org/cpython/rev/2528e4aea338

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 25 14:59:09 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 25 Feb 2013 13:59:09 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361800749.81.0.0619372296704.issue15083@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Serhiy, thanks for working on this! I didn't read the whole patch yet - will tinker with it a bit more when applying. Did you prepare the patch vs. 3.3 or default? The two are still synced and I'd be happy to apply it to both branches.

Now, the real reason I wanted to get rid of doctests is to make the global environment clean in test_xml_etree. The next logical step is to make all test classes in test_xml_etree accept the ET module in some way and store it, using it to get classes & function. I.e. no more global "ET" and "pyET" at all. Would you like to add this to your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Mon Feb 25 14:59:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Feb 2013 13:59:27 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361800767.94.0.0711797288919.issue17220@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:01:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Feb 2013 14:01:54 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1361800914.98.0.672250091296.issue12915@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Something to consider with these functions: it is probably desirable to also support the popular alternate notation which uses an explicit ":" to separate the module name from the reference within the module.

For example, setuptools entry points and nose test references both use that format.

The alternate notation should be fairly easy to both detect and handle through "name.partition(':')"

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:02:38 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Mon, 25 Feb 2013 14:02:38 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361800958.34.0.2264085305.issue17290@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Advice: anything that's not a photo should be PNG.
Temporary fix is to change the cursor see [0]
^0 http://effbot.org/zone/tkinter-busy.htm

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:06:44 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 25 Feb 2013 14:06:44 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1361801204.85.0.0944837966682.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Henrik, there's no need to provide more information in 3.2 and 2.7 than in 3.3 and default. Could you just align your patches with those (i.e. same wording in the documentation)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:08:08 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 14:08:08 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361801288.74.0.761627793777.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Well actually it IS a photo, so I think it can remain .jpg (because on print screen there is no cursor). Thanks for the temporary solution, altough I'm not sure if pyside/pygame etc will allow me to change busy cursor too.

Is there any chance for this to be fully fixed? It is a regression as it isn't present in previous releases, my bet is new windows launcher which does some work in the background.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:11:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Feb 2013 14:11:16 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361801476.5.0.681054804608.issue15083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This patch is for default branch. It applied to 3.3 too.

> The next logical step is to make all test classes in test_xml_etree accept the ET module in some way and store it, using it to get classes & function. I.e. no more global "ET" and "pyET" at all. Would you like to add this to your patch?

I was going to do this on the next step, but if you prefer I can prepare a single patch. But it seems to me that more simple patches are easier to review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:19:14 2013
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 25 Feb 2013 14:19:14 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1361801954.89.0.182753505098.issue4331@psf.upfronthosting.co.za>


Ulrich Eckhardt added the comment:

There is at least one thing that is missing in the patch, it lacks the necessary tests. The partialbug.py demonstrates the issue, it could be used as a base. However, even then, there is still one thing that is problematic: The fact that partial() returns something that behaves like a static method is documented and changing that is not backward compatible.

I still think that something like this should become part of Python though. Jack Diederich argues that you can use lambda to achieve the same, but that is not always true. If you want to bind an argument to the current value of a variable instead of a constant, lambda fails. You need the closure created by a function call to bind those variables inside a local function. Having a dedicated function for that is IMHO preferable to people copying the Python-only equivalent of partial() to achieve the same effect or even inventing their own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:26:46 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 25 Feb 2013 14:26:46 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361802406.33.0.94243576257.issue15083@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

No problems. You can go ahead and commit this patch to 3.3 and default, then. I will review it post-commit, since I wanted to tweak some things around anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:26:52 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 25 Feb 2013 14:26:52 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361802412.95.0.156474115975.issue15083@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Mon Feb 25 15:26:56 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 14:26:56 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361802416.48.0.117886285467.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

The issue is NOT present in python 3.2. I'm not expert, but given that it work in 3.2 and works in 3.3 using direct "pythonw" command, I'm almost sure it's new windows launcher. Even if I'm wrong, you guys can be sure that the issue appeared in 3.3 so there are only few possibilities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:02:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Feb 2013 15:02:11 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1361804531.26.0.689053027736.issue4331@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue 11470.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:23:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 15:23:11 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <3ZF6Nt47lNzN3d@mail.python.org>


Roundup Robot added the comment:

New changeset af570205b978 by Serhiy Storchaka in branch '3.3':
Issue #15083: Convert ElementTree doctests to unittests.
http://hg.python.org/cpython/rev/af570205b978

New changeset 5eefc85b8be8 by Serhiy Storchaka in branch 'default':
Issue #15083: Convert ElementTree doctests to unittests.
http://hg.python.org/cpython/rev/5eefc85b8be8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:23:13 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Feb 2013 15:23:13 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <512B81DE.1080603@timgolden.me.uk>


Tim Golden added the comment:

I can't reproduce this running Python 3.3 on Win7. I'll try WinXP later.
I'll also add Mark Hammond & Vinay as they implemented the PEP397 loader.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:24:57 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Feb 2013 15:24:57 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361802416.48.0.117886285467.issue17290@psf.upfronthosting.co.za>
Message-ID: <512B8246.6010002@timgolden.me.uk>


Tim Golden added the comment:

netrick: can you confirm that the same thing occurs when you explicitly
run your code via the pyw command. ie when you do this:

  pyw myprog.pyw

Also, what happens when you run:

  py myprog.pyw

ie when you use the Console launcher to launch the .pyw?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:40:45 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Feb 2013 15:40:45 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361806845.89.0.765441239127.issue17290@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
nosy: +mhammond, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:41:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Feb 2013 15:41:05 +0000
Subject: [issue16986] ElementTree incorrectly parses strings with declared
	encoding not UTF-8
In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za>
Message-ID: <1361806865.84.0.608621016152.issue16986@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for C implementation. Python implementation was fixed in issue17089.

----------
dependencies: +Expat parser parses strings only when XML encoding is UTF-8 -Parameter type error for xml.sax.parseString(string, ...)
keywords: +patch
Added file: http://bugs.python.org/file29233/etree_parse_str.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16986>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:55:02 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 15:55:02 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361807702.63.0.0893483027189.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

My OS is Windows XP so it may be only XP related. So, python 3.3 and my testing:

1) pythonw app.pyw - no bug
2) python app.pyw - no bug
3) pyw app.pyw - no bug
4) py app.pyw - no bug
5) double click on app.pyw - BUG

Tested on 2 different computers with exactly the same results. Both windows xp. Now I'm a little bit lost as running directly "pyw app.pyw" doesn't cause the bug.

However I read that the launcher assigns .pyw files in windows to some .bat script instead of pure pyw.exe. How can we check it? We need to dig into what exactly is started when .pyw script is run through double click.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:55:24 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Feb 2013 15:55:24 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361807724.81.0.741869157403.issue10572@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Mercurial?s diff formats are actually able to represent file creation, deletion and rename.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:59:18 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Feb 2013 15:59:18 +0000
Subject: [issue17130] Add runcall() function to profile.py and cProfile.py
In-Reply-To: <1360025700.9.0.591755654441.issue17130@psf.upfronthosting.co.za>
Message-ID: <1361807958.81.0.447237057504.issue17130@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> Add a profile decorator to profile and cProfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17130>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:59:30 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Feb 2013 15:59:30 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1361807970.05.0.769507025865.issue9285@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bjorns

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Mon Feb 25 16:59:34 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Feb 2013 15:59:34 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1361807974.8.0.893615368635.issue9285@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:01:14 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Feb 2013 16:01:14 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361807702.63.0.0893483027189.issue17290@psf.upfronthosting.co.za>
Message-ID: <512B8AC7.2020909@timgolden.me.uk>


Tim Golden added the comment:

Things may be a little more complicated, because one of two distinct
mechanisms may be invoked to determine what to run when double-clicking:
an Explorer-based mechanism, and a non-Explorer one.
AFAICT, the former falls back to the latter.

To check the latter, the command-line you used earlier:

  assoc .pyw # -> Python.NoConFile

  ftype Python.NoConFile # -> whatever path

To check the former, there's a registry key which escapes me at
the moment but wouldn't be too hard to find. Obviously there's
no reason why either should cause a delay, unless you've previously
done something obscure like associate .pyw files with a network-based
copy of Python or something.

To see the non-Explorer association in action, open a command
shell in the appropriate directory, and just start the program
with: app.pyw (ie without specifying a program).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:04:21 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Mon, 25 Feb 2013 16:04:21 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361808261.4.0.44737174696.issue10572@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Odd. I must be doing something wrong. My test workflow was:
1. hg mv <a> <b>
1a. modify files to resolve issues from the move
2. hg diff > issueNNNN.patch # attached
3. hg revert --all
4. patch -p1 < issueNNNN.patch

Reading the hg docs more, I should have used 'hg patch issueNNNN.patch'. However trying that on a trivial file move, results in a delete/create still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:05:59 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 25 Feb 2013 16:05:59 +0000
Subject: [issue17277] incorrect line numbers in backtrace after removing a
	trace function
In-Reply-To: <1361551369.14.0.772985934528.issue17277@psf.upfronthosting.co.za>
Message-ID: <1361808359.69.0.955224620852.issue17277@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The traced_frame.patch fixes also issue 7238 and issue 16482.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17277>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:08:49 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 16:08:49 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361808529.74.0.580756316149.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

So:
1) "assoc .pyw # -> Python.NoConFile" gives an error that it can't find association for .pyw extension
2) opening terminal in proper directory and typing just "app.pyw" gives error that this is not known command

I did small test. Using normal (from explorer) "open with + always use this program to open this file", firstly I associated .pyw to pythonw.exe - there is no bug when double clicking.

Then, I changed it to "pyw.exe" and the bug reappeared when double clicking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:12:25 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 16:12:25 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361808745.36.0.146127960504.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

I can use assoc command for .py extension but I can't for .pyw. Maybe that's some clue...

The strange thing is that explicit "pyw.exe app.pyw" gives no bug, and associating .pyw files to "pyw.exe" gives the bug when double clicking. Honestly I have no idea what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:17:51 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 16:17:51 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361809071.92.0.413547627537.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

And remember that on the exactly the same computers when I uninstalled python 3.3 and installed python 3.2, everything works flawlessy (because python 3.2 sets .pyw files to open through pythonw.exe).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:23:49 2013
From: report at bugs.python.org (Ulrich Eckhardt)
Date: Mon, 25 Feb 2013 16:23:49 +0000
Subject: [issue11470] Flag inappropriate uses of callable class attributes
In-Reply-To: <1299871329.74.0.464645573136.issue11470@psf.upfronthosting.co.za>
Message-ID: <1361809429.35.0.911390722962.issue11470@psf.upfronthosting.co.za>


Changes by Ulrich Eckhardt <ulrich.eckhardt at dominolaser.com>:


----------
nosy: +eckhardt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11470>
_______________________________________

From report at bugs.python.org  Mon Feb 25 17:24:22 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 25 Feb 2013 16:24:22 +0000
Subject: [issue17295] __slots__ on PyVarObject subclass
Message-ID: <1361809462.28.0.456255129432.issue17295@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

Currently a subclass of a PyVarObject (such as 'int') cannot use a non-empty slots, for example:

>>> class L (int):
...    __slots__ = ('a', 'b')
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: nonempty __slots__ not supported for subtype of 'int'
>>> 

However, subclasses that don't use __slots__ do have an implicit slot: the __dict__ value. Wouldn't it be possible to use the trick used for tp_dictoffset for slots as well, that is use negative values for the slot offsets and access them from the end of the object?

The major problem with an implementation is that PyMember_GetOne has a 'char*' argument instead of a 'PyObject*' one, but that's easily changed (PyMember_GetOne is currently only called in Object/descrobject.c and that call casts PyObject* to char*.  This would be an API change, but AFAIK PyMember_GetOne is not documented at the moment (and changing the argument type would be binary compatible).

I hope to work on a patch in the near future.

----------
components: Interpreter Core
messages: 182959
nosy: ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: __slots__ on PyVarObject subclass
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17295>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:00:16 2013
From: report at bugs.python.org (Andreas Hausmann)
Date: Mon, 25 Feb 2013 17:00:16 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
Message-ID: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>


New submission from Andreas Hausmann:

When pickling/unpickling a class that derives from the builtin class Exception, unpickling results in a

TypeError: ('__init__() takes at least 2 arguments (1 given)', <class '__main__.TestException'>, ())

A standard exception like ValueError can be pickled/unpickled without any problem.

This was observed for versions 2.7.3 and 3.2.3. for both pickle and cPickle.

A script (cpickle) that shows that behavior is included.

This is related (but I do not quite understand how) to the closed Issue1692335.

----------
components: Interpreter Core
files: bug_cpickle.py
messages: 182960
nosy: Andreas.Hausmann, alexandre.vassalotti, belopolsky, benjamin.peterson, bpb, brett.cannon, ehuss, facundobatista, fmitha, georg.brandl, gvanrossum, haypo, jafo, jarpa, jason.coombs, kylev, loewis, lukasz.langa, nnorwitz, pitrou, python-dev, sbt, taleinat, tseaver, zbysz, zseil
priority: normal
severity: normal
status: open
title: Cannot unpickle classes derived from 'Exception'
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file29234/bug_cpickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:04:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Feb 2013 17:04:34 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361811874.98.0.226590173721.issue17296@psf.upfronthosting.co.za>


R. David Murray added the comment:

That issue was only fixed in 3.3.  Does your code work in 3.3?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:14:40 2013
From: report at bugs.python.org (Andreas Hausmann)
Date: Mon, 25 Feb 2013 17:14:40 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361812480.18.0.34383200574.issue17296@psf.upfronthosting.co.za>


Andreas Hausmann added the comment:

I have not tried in 3.3. I have no running installation of 3.3.

I need a solution for 2.7 for a Zope project that was just ported to 2.7. My test for Python3 was halfheartedly on my standard Python3 installation (3.2) after reading Issue1692335.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:23:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Feb 2013 17:23:05 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361812985.94.0.413519636775.issue17296@psf.upfronthosting.co.za>


R. David Murray added the comment:

The reason I ask is because that issue ends with "reopen if you think this should be backported", so a backport is at least within the real of possibility :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:36:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Feb 2013 17:36:21 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361813781.66.0.739872101261.issue17296@psf.upfronthosting.co.za>


R. David Murray added the comment:

I modified your script to run under both python2 and python3.  I get the error for 2.5, 2.6, and 2.7.  The script produces the same output (without the EXCEPTION ## EXCEPTION) under 2.4 and 3.3.

----------
Added file: http://bugs.python.org/file29235/bug_cpickle.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:45:17 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Feb 2013 17:45:17 +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: <1361814317.53.0.889496375216.issue7238@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/issue7238>
_______________________________________

From report at bugs.python.org  Mon Feb 25 18:47:00 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Feb 2013 17:47:00 +0000
Subject: [issue16482] pdb.set_trace() clobbering traceback on error
In-Reply-To: <1353002125.56.0.265106335805.issue16482@psf.upfronthosting.co.za>
Message-ID: <1361814420.21.0.794722774018.issue16482@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/issue16482>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:16:40 2013
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Feb 2013 18:16:40 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361809071.92.0.413547627537.issue17290@psf.upfronthosting.co.za>
Message-ID: <512BAA85.90601@timgolden.me.uk>


Tim Golden added the comment:

I can't reproduce this on XP either. I've tried various combinations of 
.py / .pyw, command line, double-click, etc. and I've not had a single 
problem.

Let's hope someone else can suggest something

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:17:37 2013
From: report at bugs.python.org (=?utf-8?q?Luis_L=C3=B3pez_L=C3=A1zaro?=)
Date: Mon, 25 Feb 2013 18:17:37 +0000
Subject: [issue17297] Issue with return in recursive functions
Message-ID: <1361816257.47.0.388689345116.issue17297@psf.upfronthosting.co.za>


New submission from Luis L?pez L?zaro:

Sorry if I am raising something naive as perhaps I am doing something wrong as I am both an amateur programmer and a newcomer to Python, but version 3.3 appears to have an issue with the return statement in the setting of recursive functions.

When implementing a fruitful recursive function in Python 3.3 (specifically Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32) which depends on conditionals it only returns the result value if the conditions are met in the first iteration.

I am attaching a file in which I have implemented the Euclidean algorithm in 2 slightly different ways. The print statements produce the expected results (for instance with 1000,75) and a print statement placed in the if loop where the return statement is shows the indicator sentence but no value is returned by the function. I have also copied an implementation obtained from a website (function Euclid_LP; obtained from the wiki Literate Programs, http://en.literateprograms.org/Euclidean_algorithm_%28Python%29) and it does not work either.

For the tests, initially I run the program with F5 and invoked the functions from the Python shell. Later I have added a main part of the program prompting for the numbers and calling the functions to later display the results, with no change in the outcome

----------
components: Regular Expressions
files: Chapter 6 MCD Euclidean.py
messages: 182966
nosy: ezio.melotti, luislopezlazaro, mrabarnett
priority: normal
severity: normal
status: open
title: Issue with return in recursive functions
versions: Python 3.3
Added file: http://bugs.python.org/file29236/Chapter 6 MCD Euclidean.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17297>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:23:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 18:23:55 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361816635.4.0.926589571581.issue17223@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If the problem is that PyUnicode_FromUnicode() rejects character outside range [U+0000; U+10ffff], it would be better to use the byte string '\xff' * sizeof_PY_UNICODE. U+66647361 may become valid in a future version of Unicode, I don't thing that U+FFFFFFFF would become valid.

sizeof_PY_UNICODE is ctypes.sizeof(ctypes.c_wchar) since Python 3.3. '\xff' * 4 works on any platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:24:37 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 25 Feb 2013 18:24:37 +0000
Subject: [issue17297] Issue with return in recursive functions
In-Reply-To: <1361816257.47.0.388689345116.issue17297@psf.upfronthosting.co.za>
Message-ID: <1361816677.66.0.956030970894.issue17297@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

This question should've been posted to python-list at python.org, not here.

Your functions are calling themselves, but not returning the result of the call to their own callers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17297>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:29:12 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 25 Feb 2013 18:29:12 +0000
Subject: [issue16935] unittest should understand SkipTest at import time
	during test discovery
In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za>
Message-ID: <1361816952.4.0.785109867478.issue16935@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the review, Ezio.  I've made some changes and here's the new patch.

----------
Added file: http://bugs.python.org/file29237/issue16935.v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16935>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:29:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 18:29:53 +0000
Subject: [issue16632] Enable DEP and ASLR
In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za>
Message-ID: <1361816993.49.0.500340327048.issue16632@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I see a crash in test_capi and a couple of crashes
> in test_faulthandler but these don't seem to be related.

Which kind of crash? faulthandler has functions to make Python crash, crashes are expected :-)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16632>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:31:11 2013
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 25 Feb 2013 18:31:11 +0000
Subject: [issue16632] Enable DEP and ASLR
In-Reply-To: <1354875781.46.0.686705865065.issue16632@psf.upfronthosting.co.za>
Message-ID: <1361817071.06.0.477559559061.issue16632@psf.upfronthosting.co.za>


Changes by Lukas Lueg <lukas.lueg at gmail.com>:


----------
nosy:  -ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16632>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:36:28 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 18:36:28 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361817388.44.0.234508672562.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Well I did fresh install of windows xp and encountered it. On the other pc with xp I tried it is also present. I don't know why I encounter this, I must try more PCs. If you have xp, please try if you can reproduce the issue and post your result here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:37:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Feb 2013 18:37:01 +0000
Subject: [issue17297] Issue with return in recursive functions
In-Reply-To: <1361816257.47.0.388689345116.issue17297@psf.upfronthosting.co.za>
Message-ID: <1361817421.12.0.298511048902.issue17297@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, the bug tracker is not a good place to get help on programming.  python-list, or the python-tutors list, will produce much more useful results for you.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17297>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:37:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 18:37:35 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361817455.03.0.404836600469.issue11671@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+        if bad_header_value_re.search(_value):
+            error_str = "Bad header value: {0!r} (bad char: {1!r})"
+            raise AssertionError(error_str.format(
+                _value, bad_header_value_re.search(_value).group(0)))

Why do you search the character twice? You can do something like:

match = bad_header_value_re.search(_value)
if match is not None:
  ... match..group(0) ...

Why do you only check value? You should also check _params:

parts = "; ".join(parts)
match = bad_header_value_re.search(parts)
...

And you should also check the name.

Should we do the same checks in httplib?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:41:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 18:41:05 +0000
Subject: [issue3991] urllib.request.urlopen does not handle non-ASCII
	characters
In-Reply-To: <1222627636.82.0.587488225038.issue3991@psf.upfronthosting.co.za>
Message-ID: <1361817665.3.0.120375245979.issue3991@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3991>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:44:16 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 25 Feb 2013 18:44:16 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361817856.59.0.0279363173475.issue17290@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Please post, on a machine where the problem is occurring, the contents of the following keys in the registry. What I have shown below is what you should have (allowing for differing locations for Windows):

[HKEY_CLASSES_ROOT\.py]
@="Python.File"

[HKEY_CLASSES_ROOT\.pyc]
@="Python.CompiledFile"

[HKEY_CLASSES_ROOT\.pyo]
@="Python.CompiledFile"

[HKEY_CLASSES_ROOT\.pys]
@="pysFile"

[HKEY_CLASSES_ROOT\.pyw]
@="Python.NoConFile"

[HKEY_CLASSES_ROOT\Python.CompiledFile]
@="Compiled Python File"

[HKEY_CLASSES_ROOT\Python.CompiledFile\DefaultIcon]
@="\"C:\\Windows\\py.exe\",2"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell]

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open]
@="Open"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open\command]
@="\"C:\\Windows\\py.exe\" \"%1\" %*"

[HKEY_CLASSES_ROOT\Python.File]
@="Python File"

[HKEY_CLASSES_ROOT\Python.File\DefaultIcon]
@="\"C:\\Windows\\py.exe\",1"

[HKEY_CLASSES_ROOT\Python.File\shell]

[HKEY_CLASSES_ROOT\Python.File\shell\open]
@="Open"

[HKEY_CLASSES_ROOT\Python.File\shell\open\command]
@="\"C:\\Windows\\py.exe\" \"%1\" %*"

[HKEY_CLASSES_ROOT\Python.NoConFile]
@="Python File (no console)"

[HKEY_CLASSES_ROOT\Python.NoConFile\DefaultIcon]
@="\"C:\\Windows\\py.exe\",1"

[HKEY_CLASSES_ROOT\Python.NoConFile\shell]

[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open]
@="Open"

[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open\command]
@="\"C:\\Windows\\pyw.exe\" \"%1\" %*"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 19:45:31 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 25 Feb 2013 18:45:31 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361817931.86.0.304993755625.issue17290@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

The .pys entry needn't be there - I left it in by mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:01:08 2013
From: report at bugs.python.org (Devin Cook)
Date: Mon, 25 Feb 2013 19:01:08 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361818868.73.0.505825307237.issue11671@psf.upfronthosting.co.za>


Changes by Devin Cook <devin.c.cook at gmail.com>:


Removed file: http://bugs.python.org/file29182/header_newlines.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:12:21 2013
From: report at bugs.python.org (Devin Cook)
Date: Mon, 25 Feb 2013 19:12:21 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361819541.03.0.684129679869.issue11671@psf.upfronthosting.co.za>


Devin Cook added the comment:

The spec doesn't say anything about the header name. It probably should though, as the same issue exists there.

I used two searches because that's how it's done in wsgiref.validate, and it's not a huge deal to do that because the second one will only execute when there's an error. That said, I changed it to how you proposed.

Here's another stab at that patch.

----------
Added file: http://bugs.python.org/file29238/header_newlines_tip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:15:11 2013
From: report at bugs.python.org (Devin Cook)
Date: Mon, 25 Feb 2013 19:15:11 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361819711.76.0.574587218801.issue11671@psf.upfronthosting.co.za>


Changes by Devin Cook <devin.c.cook at gmail.com>:


Removed file: http://bugs.python.org/file29192/header_newlines_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:15:19 2013
From: report at bugs.python.org (Devin Cook)
Date: Mon, 25 Feb 2013 19:15:19 +0000
Subject: [issue11671] Security hole in wsgiref.headers.Headers
In-Reply-To: <1301055298.41.0.957962483368.issue11671@psf.upfronthosting.co.za>
Message-ID: <1361819719.41.0.171029382898.issue11671@psf.upfronthosting.co.za>


Changes by Devin Cook <devin.c.cook at gmail.com>:


Removed file: http://bugs.python.org/file29193/header_newlines_2.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11671>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:30:45 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 19:30:45 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361820645.68.0.275344298948.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Differences:

[HKEY_CLASSES_ROOT\Python.CompiledFile\DefaultIcon]
@="F:\Python33\DLLs\pyc.ico"

[HKEY_CLASSES_ROOT\Python.CompiledFile\shell\open]
value not set

[HKEY_CLASSES_ROOT\Python.File\DefaultIcon]
@="F:\Python33\DLLs\py.ico"

[HKEY_CLASSES_ROOT\Python.File\shell\open]
value not set

[HKEY_CLASSES_ROOT\Python.NoConFile\DefaultIcon]
@="F:\Python33\DLLs\py.ico"

[HKEY_CLASSES_ROOT\Python.NoConFile\shell\open]
value not set

I once agained formatted partition and installed brand new windows, installed drivers and SP3, then python 3.3 and the behaviour is still the same.
As for my python installation, I didn't set anything, just clicked through install. And set install for all users.

Also, I tried another XP machine and the bug was there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:31:56 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 Feb 2013 19:31:56 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361820716.97.0.088330278001.issue16612@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Argument Clinic is now PEP 436.

http://www.python.org/dev/peps/pep-0436/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Mon Feb 25 20:57:14 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 25 Feb 2013 19:57:14 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1361822234.58.0.13734453847.issue13555@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

680959a3ae2e has caused that g-ir-scanner tool from gobject-introspection (which seems to create some pickles and next load them?) fails with MemoryError, e.g. during building of GTK+.
MemoryError occurs only for a subset of pickles.
I attach a small pickle, which allows to reproduce this problem.
Download this pickle and save it in /tmp.

Additional preparation:
$ cd /tmp
$ wget -q http://ftp.gnome.org/pub/gnome/sources/gobject-introspection/1.34/gobject-introspection-1.34.2.tar.xz
$ tar -xJf gobject-introspection-1.34.2.tar.xz
$ sed -e '/^with LibtoolImporter/,/^$/d' -i gobject-introspection-1.34.2/giscanner/xmlwriter.py

Behavior before 680959a3ae2e:
$ PYTHONPATH="gobject-introspection-1.34.2" python2.7 -c 'import cPickle; print(cPickle.load(open("pickle")))'
<giscanner.girparser.GIRParser object at 0x7f506299be90>

Behavior after 680959a3ae2e:
$ PYTHONPATH="gobject-introspection-1.34.2" python2.7 -c 'import cPickle; print(cPickle.load(open("pickle")))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
MemoryError

----------
nosy: +benjamin.peterson
priority: normal -> release blocker
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open
Added file: http://bugs.python.org/file29239/pickle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Mon Feb 25 21:07:22 2013
From: report at bugs.python.org (karl)
Date: Mon, 25 Feb 2013 20:07:22 +0000
Subject: [issue747320] rfc2822 formatdate functionality duplication
Message-ID: <1361822842.01.0.634263636881.issue747320@psf.upfronthosting.co.za>


karl added the comment:

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-7.1.1

quoting from HTTP 1.1 bis

   Prior to 1995, there were three different formats commonly used by
   servers to communicate timestamps.  For compatibility with old
   implementations, all three are defined here.  The preferred format is
   a fixed-length and single-zone subset of the date and time
   specification used by the Internet Message Format [RFC5322].

     HTTP-date    = IMF-fixdate / obs-date

   An example of the preferred format is

     Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

   Examples of the two obsolete formats are

     Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
     Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

   A recipient that parses a timestamp value in an HTTP header field
   MUST accept all three formats.  A sender MUST generate the IMF-
   fixdate format when sending an HTTP-date value in a header field.


What http.server.BaseHTTPRequestHandler.date_time_string is currently doing

>>> import time
>>> timestamp = time.time()
>>> weekdayname = ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun']
>>> monthname = [None,'Jan', 'Feb', 'Mar', 'Apr', 'May', 'Jun','Jul', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec']
>>> year, month, day, hh, mm, ss, wd, y, z = time.gmtime(timestamp)
>>> s = "%s, %02d %3s %4d %02d:%02d:%02d GMT" % (weekdayname[wd],day, monthname[month], year,hh, mm, ss)
>>> s
'Mon, 25 Feb 2013 19:26:34 GMT'



what email.utils.formatdate is doing:

>>> import email.utils
>>> email.utils.formatdate(timeval=None,localtime=False, usegmt=True)
'Mon, 25 Feb 2013 19:40:04 GMT'
>>> import time
>>> ts = time.time()
>>> email.utils.formatdate(timeval=ts,localtime=False, usegmt=True)
'Mon, 25 Feb 2013 19:51:50 GMT'

I createad a patch 
s = email.utils.formatdate(timestamp, False, True)

I didn't touch the log method which has a different format which is anyway not compatible with email.utils.

----------
keywords: +patch
nosy: +karlcow
Added file: http://bugs.python.org/file29240/server.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue747320>
_______________________________________

From report at bugs.python.org  Mon Feb 25 21:14:36 2013
From: report at bugs.python.org (karl)
Date: Mon, 25 Feb 2013 20:14:36 +0000
Subject: [issue7370] BaseHTTPServer reinventing rfc822 date formatting
In-Reply-To: <1258734165.92.0.303692639409.issue7370@psf.upfronthosting.co.za>
Message-ID: <1361823276.58.0.799885342523.issue7370@psf.upfronthosting.co.za>


karl added the comment:

I think it is now fixed by my patch in http://bugs.python.org/issue747320

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7370>
_______________________________________

From report at bugs.python.org  Mon Feb 25 21:51:01 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 Feb 2013 20:51:01 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361825461.09.0.588668724781.issue10572@psf.upfronthosting.co.za>


Ned Deily added the comment:

Geoff, you need to use hg's optional "git" format diff to preserve rename info.  See "hg help diffs".

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:14:32 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 25 Feb 2013 21:14:32 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361826872.12.0.156953024079.issue17220@psf.upfronthosting.co.za>


Zachary Ware added the comment:

2528e4aea338 seems to have broken building on Windows: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1517

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:16:49 2013
From: report at bugs.python.org (karl)
Date: Mon, 25 Feb 2013 21:16:49 +0000
Subject: [issue747320] rfc2822 formatdate functionality duplication
Message-ID: <1361827009.89.0.115137652143.issue747320@psf.upfronthosting.co.za>


karl added the comment:

Made a mistake in the previous server.patch, use server.2.patch

----------
Added file: http://bugs.python.org/file29241/server2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue747320>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:17:14 2013
From: report at bugs.python.org (karl)
Date: Mon, 25 Feb 2013 21:17:14 +0000
Subject: [issue747320] rfc2822 formatdate functionality duplication
Message-ID: <1361827034.48.0.619480329159.issue747320@psf.upfronthosting.co.za>


Changes by karl <karl+pythonbugs at la-grange.net>:


Removed file: http://bugs.python.org/file29240/server.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue747320>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:25:17 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 25 Feb 2013 21:25:17 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361827517.39.0.917288051392.issue17290@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Does the error occur with the standalone launcher downloadable from BitBucket? The "value not set" for shell\open is not good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:26:22 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 25 Feb 2013 21:26:22 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361827582.46.0.179376130301.issue17290@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:33:18 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Feb 2013 21:33:18 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1361827998.8.0.923620450407.issue9285@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Ok, here's an updated patch modeled after:
http://hg.python.org/cpython/rev/422169310b7c

It works fine with cProfile.py but not with profile.py where I get this exception when I try to use the context manager (tests can be run in order to reproduce it):

  File "/home/giampaolo/svn/python/3.4-profile/Lib/profile.py", line 339, in trace_dispatch_return
    assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3])
AssertionError: ('Bad return', ('profile', 0, ''))

I have no clue what this error means.
I wasn't able to add a context manager for profile.Profile for the same reason.
Any clue?

----------
nosy: +arigo
Added file: http://bugs.python.org/file29242/profile3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:33:51 2013
From: report at bugs.python.org (Lukas Lueg)
Date: Mon, 25 Feb 2013 21:33:51 +0000
Subject: [issue9285] Add a profile decorator to profile and cProfile
In-Reply-To: <1279375274.49.0.102313390752.issue9285@psf.upfronthosting.co.za>
Message-ID: <1361828031.14.0.718302029289.issue9285@psf.upfronthosting.co.za>


Changes by Lukas Lueg <lukas.lueg at gmail.com>:


----------
nosy:  -ebfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9285>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:40:50 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 21:40:50 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361828450.34.0.556961756234.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Well I installed python using standard python 3.3.0.msi from python.org, so maybe there is something wrong with setting registry keys?

I downloaded standalone launcher from bitbucket and the results are the same:

1) command line "pyw.exe app.pyw" no bug
2) I assigned that standalone launcher to open .pyw files (tried .pyw1 also for unique extension) and in both cases when double clicked in explorer the bug existed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:43:09 2013
From: report at bugs.python.org (netrick)
Date: Mon, 25 Feb 2013 21:43:09 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361828589.12.0.341756669522.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Of course, the "py.exe" launcher with console (both standalone and from python 3.3) DOES NOT produce the error even when launching with double click. It's only pyw.exe double click thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:48:13 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Feb 2013 21:48:13 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361828893.98.0.616339009257.issue17220@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I dug into http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1517/steps/compile/logs/stdio and found this traceback:

EXEC : Fatal Python error : Py_Initialize: unable to load the file system codec [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj]
  Traceback (most recent call last):
    File "<frozen importlib._bootstrap>", line 1570, in _find_and_load
    File "<frozen importlib._bootstrap>", line 1537, in _find_and_load_unlocked
    File "<frozen importlib._bootstrap>", line 572, in _check_name_wrapper
    File "<frozen importlib._bootstrap>", line 1035, in load_module
    File "<frozen importlib._bootstrap>", line 1016, in load_module
    File "<frozen importlib._bootstrap>", line 536, in module_for_loader_wrapper
    File "<frozen importlib._bootstrap>", line 859, in is_package
    File "<frozen importlib._bootstrap>", line 77, in _path_split
  ValueError: too many values to unpack (expected 2)

Looks like Serhiy forgot to cap the rsplit() call to a single split (which rpartition does implicitly). I'll fix it shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 25 22:58:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Feb 2013 21:58:40 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361829520.22.0.233184000157.issue14468@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I haven't really followed the discussion here, but both patches look ok to me (the committing.rst one, especially, is a welcome cleanup).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:06:26 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Feb 2013 22:06:26 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <1361829986.98.0.554588942155.issue17220@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Found another bug introduced by this patch which I will have a patch for shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:10:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 22:10:21 +0000
Subject: [issue17220] Little enhancements of _bootstrap.py
In-Reply-To: <1361123423.75.0.607342281941.issue17220@psf.upfronthosting.co.za>
Message-ID: <3ZFHQh66HGzNXt@mail.python.org>


Roundup Robot added the comment:

New changeset d98a82f4c9bd by Brett Cannon in branch 'default':
Issue #17220: two fixes for changeset 2528e4aea338.
http://hg.python.org/cpython/rev/d98a82f4c9bd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17220>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:24:54 2013
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Mon, 25 Feb 2013 22:24:54 +0000
Subject: [issue17298] Twisted test failure triggered by change in 2.7 branch
Message-ID: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>


New submission from Glyph Lefkowitz:

As reported in Twisted:

https://twistedmatrix.com/trac/ticket/6314

and as seen on the Twisted buildbot: https://buildbot.twistedmatrix.com/builders/lucid32-py2.7maint/builds/2327/steps/trial/logs/problems

The tip of the 2.7 branch is now failing Twisted's test suite.

The nature of the bug is not immediately obvious, but it looks like certain previously-working pickles are now raising MemoryError when we attempt to load them.

----------
components: Library (Lib)
messages: 182993
nosy: benjamin.peterson, glyph
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Twisted test failure triggered by change in 2.7 branch
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17298>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:25:37 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Feb 2013 22:25:37 +0000
Subject: [issue17298] Twisted test failure triggered by change in 2.7 branch
In-Reply-To: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>
Message-ID: <1361831137.08.0.414024094711.issue17298@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17298>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:28:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 22:28:37 +0000
Subject: [issue17298] Twisted test failure triggered by change in 2.7 branch
In-Reply-To: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>
Message-ID: <1361831317.18.0.357878548128.issue17298@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like #13555.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17298>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:32:32 2013
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Mon, 25 Feb 2013 22:32:32 +0000
Subject: [issue17298] Twisted test failure triggered by change in 2.7 branch
In-Reply-To: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>
Message-ID: <1361831552.75.0.948698995937.issue17298@psf.upfronthosting.co.za>


Glyph Lefkowitz added the comment:

Yes; perhaps that change should be rolled back until a fix for the regression can be added?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17298>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:32:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Feb 2013 22:32:35 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361831555.39.0.823924821511.issue17223@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> If the problem is that PyUnicode_FromUnicode() rejects character
> outside range [U+0000; U+10ffff],

But this used to return two valid characters:
>>> str(array('u', b'asdf'))
"array('u', '??')"

so I think it still should -- unless the operation was already nonsensical and/or there's no way to do the same thing on 3.3+ due to the change introduced by PEP 393.

> it would be better to use the byte string '\xff' * sizeof_PY_UNICODE. 

What for?

> U+66647361 may become valid in a future version of Unicode,

It won't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:33:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 22:33:59 +0000
Subject: [issue17298] Twisted test failure triggered by change in 2.7 branch
In-Reply-To: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>
Message-ID: <1361831639.93.0.606318917749.issue17298@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Yes; perhaps that change should be rolled back until a fix for the regression can be added?

Try on your side to check if it's really a duplicate. If yes, please join the discussion on issue #13555.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17298>
_______________________________________

From report at bugs.python.org  Mon Feb 25 23:47:41 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 25 Feb 2013 22:47:41 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361832461.68.0.951225594455.issue17223@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

We discussed this on IRC, and apparently the seemingly valid result I got on 3.2 was because I had a narrow build.  On a wide 3.2 build I get:
>>> str(array('u', b'asdf'))
"array('u', '\\U66647361')"

Since 3.3+ behaves like a wide build and since \U66647361 is not valid, I now agree that raising an error is the right thing to do.

If possible, even 3.2 should raise an error, rather than returning an invalid codepoint.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 00:20:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 23:20:34 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <3ZFJzj4KBgzP8w@mail.python.org>


Roundup Robot added the comment:

New changeset c354afedb866 by Victor Stinner in branch '3.3':
Issue #17223: Fix PyUnicode_FromUnicode() for string of 1 character outside
http://hg.python.org/cpython/rev/c354afedb866

New changeset a4295ab52427 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17223: Fix PyUnicode_FromUnicode() for string of 1 character
http://hg.python.org/cpython/rev/a4295ab52427

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 00:28:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 25 Feb 2013 23:28:52 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <3ZFK9J1Rg6zP7S@mail.python.org>


Roundup Robot added the comment:

New changeset ebeed44702ec by Victor Stinner in branch '3.3':
Issue #17223: array module: Fix a crasher when converting an array containing
http://hg.python.org/cpython/rev/ebeed44702ec

New changeset 381de621ff6a by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17223: array module: Fix a crasher when converting an array
http://hg.python.org/cpython/rev/381de621ff6a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 00:31:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Feb 2013 23:31:17 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361835077.83.0.116326213149.issue17223@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I think this should be updated to work with the PEP 393 implementation, rather than raising an error.

It was discussed to add new formats for UCS1, UCS2 and UCS4 formats to the array module, but nobody implemented the idea. The "u" format is kept unchanged (use Py_UNICODE / wchar_t) for backward compatibility with Python 3.2.

--

I found another bug while trying Manuel's patch :-/ It's now fixed.

@Manuel: Thanks for your patch!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 00:37:53 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 Feb 2013 23:37:53 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361835473.36.0.0024006225683.issue16612@psf.upfronthosting.co.za>


Larry Hastings added the comment:

A quick note about the extension mechanism.  Currently the only way to extend PyArg_Parse* is via O&.  Therefore, any extended type you add will use O&, and will have a "converter".  So internally all I did was say "if the parameter has a converter, ignore the type and use the O& format unit".

This may not be the perfect extension API, if we change Clinic to using some new yet-to-be-defined API for argument parsing.  But I suspect it's pretty close.  Extension types will need a conversion function from PyObject to their type, they'll need a way of defining the C default value, and they'll need a way of cleaning up afterwards, all of which I already do.  So I guess I'm interested in feedback on the extension API too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Tue Feb 26 00:52:02 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 25 Feb 2013 23:52:02 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361836322.06.0.391966207613.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> I still fail to understand what are you trying to achieve.

My goal is to reach consensus on changes and have them committed.  In its current form, I don't agree with the patch.  The length of the comment thread and the length of the patch has discouraged me from raising most of my comments, because I'm fairly certain my comments will lead to back-and-forth discussion which will make the thread even longer.  That's why I want to break things up.

I want to be clear that I'm not against the goals of the patch, so I'm not trying to "block" or stalemate anything.   I just have concerns I would like to discuss which is what the review process is supposed to allow.  Needless to say, I know what it feels like to have a patch reviewed in detail (which I'm not necessarily planning to do).  On the plus side, it's much better than comments being against the patch outright in any form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 01:14:37 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 26 Feb 2013 00:14:37 +0000
Subject: [issue17289] readline.set_completer_delims() doesn't play well with
	others
In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za>
Message-ID: <1361837677.38.0.169813169839.issue17289@psf.upfronthosting.co.za>


Changes by Thomas Kluyver <takowl at gmail.com>:


----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17289>
_______________________________________

From report at bugs.python.org  Tue Feb 26 01:17:05 2013
From: report at bugs.python.org (Simon Baird)
Date: Tue, 26 Feb 2013 00:17:05 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1361837825.62.0.603231753824.issue12345@psf.upfronthosting.co.za>


Simon Baird added the comment:

https://github.com/search?q=%22TAU+%3D+2+%2A+Math.PI%22&type=Code
https://github.com/search?q=%22TAU+%3D+PI+*+2%22&type=Code

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Tue Feb 26 01:18:39 2013
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 26 Feb 2013 00:18:39 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361837919.21.0.20375882554.issue17290@psf.upfronthosting.co.za>


Mark Hammond added the comment:

The problem is that Explorer displays the IDC_APPSTARTING icon when an app launches, until that app does something ui-ish (eg, creating a window, fetching a windows message).  I could reproduce the problem on XP, and pushed a fix for the launcher to https://bitbucket.org/vinay.sajip/pylauncher/commits/639582f0bebbabbf63fe8746986122173e765baf which solves the problem for me.

I'm not sure what the process is for getting that fix into the Python repo - hopefully Vinay knows :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 01:34:14 2013
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 26 Feb 2013 00:34:14 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361838854.05.0.913202913323.issue17290@psf.upfronthosting.co.za>


Mark Hammond added the comment:

If anyone would like to test the fix out, I've put a 32bit pyw.exe with the fix at http://starship.python.net/crew/skippy/downloads/pyw.exe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 01:48:12 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 26 Feb 2013 00:48:12 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1361836322.06.0.391966207613.issue14468@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fUn2BrALVGixa7VP1jsNxaeBf8mQVBANr+zkGz8A_-tw@mail.gmail.com>


Nick Coghlan added the comment:

Perfect is the enemy of good. I vote for just committing it, then Chris can
propose additional fixes/changes in a subsequent patch.
On 26 Feb 2013 09:52, "Chris Jerdonek" <report at bugs.python.org> wrote:

>
> Chris Jerdonek added the comment:
>
> > I still fail to understand what are you trying to achieve.
>
> My goal is to reach consensus on changes and have them committed.  In its
> current form, I don't agree with the patch.  The length of the comment
> thread and the length of the patch has discouraged me from raising most of
> my comments, because I'm fairly certain my comments will lead to
> back-and-forth discussion which will make the thread even longer.  That's
> why I want to break things up.
>
> I want to be clear that I'm not against the goals of the patch, so I'm not
> trying to "block" or stalemate anything.   I just have concerns I would
> like to discuss which is what the review process is supposed to allow.
>  Needless to say, I know what it feels like to have a patch reviewed in
> detail (which I'm not necessarily planning to do).  On the plus side, it's
> much better than comments being against the patch outright in any form.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue14468>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 01:58:26 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 26 Feb 2013 00:58:26 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361840306.12.0.896082304319.issue17290@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Good catch, Mark!

I'll wait for confirmation that your patched pyw.exe works, then make the changes in the Python repository and also update the standalone launcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 02:04:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 01:04:34 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361840674.12.0.727148963204.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Perfect is the enemy of good. I vote for just committing it, then
> Chris can propose additional fixes/changes in a subsequent patch.

Agreed.

Chris, any preference about the number of commits (8 separate commits, 1-6 + 7-8, 2 on its own)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 02:16:50 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 26 Feb 2013 01:16:50 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361841410.52.0.188915757598.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

For the record, I don't recall *any* changes being made to any of the patches in response to mine or others' comments, other than dividing them up.  So we're not talking about perfection.  If they're going to be committed as is, it might as well be one patch.  I hope there isn't a double standard when it comes to proposing subsequent changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 02:21:22 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Feb 2013 01:21:22 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361841682.35.0.517783576849.issue14468@psf.upfronthosting.co.za>


Ned Deily added the comment:

ISTM, committing changes to the devguide is fundamentally different from committing a change to Python itself.  The devguide has a much smaller and focused audience, does not have compatibility considerations, it's continuously releasable etc etc.  So there's no need to have exactly the same stringent criteria for changes to the devguide.  That doesn't mean that there shouldn't be any review of those changes or that the process devolves to a change storm.  But, surely at this point, it would be easier to get meaningful additional review after the current set of changes are committed rather than continually redoing a large set of patches.  Then others are free to propose their own further changes for review.  I guess the lesson I would take from this is to limit the size and scope of individual changes to the devguide where possible, e.g. "ship" frequently.  This doesn't need to be difficult.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 02:34:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 01:34:04 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361842444.5.0.541607801287.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

OK, I'll commit 1-6 and 7-8 then.  After that we can further improve things starting from there.

> it would be easier to get meaningful additional review after the 
> current set of changes are committed rather than continually redoing a 
> large set of patches.

And that's the reason why.  I'm willing to discuss and accept changes, but I would rather doing it after this is committed than having to modify existing patches (especially if the changes are minor).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 02:40:05 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 26 Feb 2013 01:40:05 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361842805.77.0.355342070973.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> But, surely at this point, it would be easier to get meaningful additional review after the current set of changes are committed rather than continually redoing a large set of patches.

This was my reason for asking early on that the changes be proposed and committed individually, so that the whole set of patches doesn't have to be redone after each round of comments:

http://bugs.python.org/issue14468#msg179849

But the bulk of the discussion wound up being about this request rather than on the content of the patches themselves.  I've never had a problem breaking up my own issues/patches when asked.

For various reasons, there is a phenomenon that the larger the patch, the less relative scrutiny it tends to undergo (with the exception of PEP's where the process is different), which is the opposite of what it should be.  I'd like for us to try to avoid that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 02:49:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 01:49:44 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361843384.53.0.698669696353.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This was a somewhat major rewrite.  The fact that we had no rietveld available made things more complicated on the reviewer side, and splitting the patch in smaller chunks made things more complicated on my side.

FWIW I have 2 major doc issues up next: #4153 and #14097.  Much like this issue, I'd have to go through the existing content and make several adjustments, that not necessarily stand on their own.  Having a single patch and update that based on the comments received on rietveld seems to work there though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 03:33:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 02:33:33 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <3ZFPGN2xzGzNrN@mail.python.org>


Roundup Robot added the comment:

New changeset a50e537c5914 by Ezio Melotti in branch 'default':
#14468: document the use of the share extension as the suggested approach for core developers.
http://hg.python.org/devguide/rev/a50e537c5914

New changeset 3e213eaf85a6 by Ezio Melotti in branch 'default':
#14468: regroup the "Version control" FAQs in two sections: "for everyone" and "for committers".
http://hg.python.org/devguide/rev/3e213eaf85a6

New changeset ec43cf291255 by Ezio Melotti in branch 'default':
#14468: update FAQs about multiple clones and share extension.
http://hg.python.org/devguide/rev/ec43cf291255

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 03:38:31 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 02:38:31 +0000
Subject: [issue17284] create mercurial section in devguide's committing.rst
In-Reply-To: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>
Message-ID: <1361846311.05.0.406202038942.issue17284@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This has now been committed as part of #14468.
Regarding the change of the section title, I'm not sure that's necessary.
Currently the section covers all the fundamental Mercurial-related operations that a committers needs to know (set up, commit, merge, push), not just committing.
I suggest closing this as out of date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17284>
_______________________________________

From report at bugs.python.org  Tue Feb 26 04:15:18 2013
From: report at bugs.python.org (karl)
Date: Tue, 26 Feb 2013 03:15:18 +0000
Subject: [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1361848518.59.0.135991963239.issue11448@psf.upfronthosting.co.za>


karl added the comment:

This is a possible additional example for set_tunnel, modification of python3.3/html/_sources/library/http.client.txt

Hope it helps.

----------
nosy: +karlcow
Added file: http://bugs.python.org/file29243/http.client.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11448>
_______________________________________

From report at bugs.python.org  Tue Feb 26 05:55:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Feb 2013 04:55:33 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361854533.23.0.0568250344242.issue14468@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

While multiple, spaced, commits might have been better, if the first had been made at least 6 months ago, I agree that the best thing *now* was to commit these as a base for further improvements. There are 19 other open devguide issues to review and close as out-of-date, a bad idea, or a good idea with an improvement made. I think the core-mentorship list would be one place to get more opinions if more are needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 06:32:30 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Feb 2013 05:32:30 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361856750.44.0.541427619855.issue14468@psf.upfronthosting.co.za>


Ned Deily added the comment:

"I think the core-mentorship list would be one place to get more opinions if more are needed."

Keep in mind that the core-mentorship list is a closed list so any discussions there would take place without direct participation of the (many?) core developers, like me, not currently on the list.  Soliciting opinions is one thing but, in general, I don't think it is a good idea to encourage side, non-public discussions of the development process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 06:53:13 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Feb 2013 05:53:13 +0000
Subject: [issue16942] urllib still doesn't support persistent connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361857993.68.0.316343249104.issue16942@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

+class FileCookieJar(CookieJar, metaclass=ABCMeta):
+    """Abstract Base Class for any file-based CookieJar."""

Is it just me or is it a bit strange to derive an abstract base class from a concrete class? Is CookieJar meant to be directly used?

+        with open(self.filename) as f:
+            magic = f.readline()
+            if not self.magic_re.search(magic):
+                f.close()
+                raise LoadError(
+                    "%r does not look like a Netscape format cookies 

f.close() seems not needed as doing that in __exit__ as a major point of with open... statements.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16942>
_______________________________________

From report at bugs.python.org  Tue Feb 26 07:05:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Feb 2013 06:05:19 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361858719.09.0.00174513732713.issue14468@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have no intention of excluding you ;-). Please comment on any or all of the other 19. But if an issue is stuck with inadequate or conflicting developer opinion, getting supplemental opinions from target users, as in "There is a proposal to change 'abc' to 'xyz'. Which is clearer to you?" might be one way to move forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 07:20:46 2013
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 26 Feb 2013 06:20:46 +0000
Subject: [issue17289] readline.set_completer_delims() doesn't play well with
	others
In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za>
Message-ID: <1361859646.53.0.792000455251.issue17289@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17289>
_______________________________________

From report at bugs.python.org  Tue Feb 26 07:57:32 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Feb 2013 06:57:32 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361799442.43.0.308714279488.issue17263@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3S7C88fdwoF=2ZNnsAtOb2SgCMiJFzh+XgHbPNqCb=CQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Note that in threadmodule.c, in local_clear, we are iterating through all threads:
>
> In PyDict_DelItem, if the GIL is released and meanwhile, the list of threadstates is altered, is that a problem for this loop? So maybe tstate becomes invalid there.

Yes.
If PyDict_DelItem() releases the GIL and tstate is deleted,
PyThreadState_Next(tstate) is undefined behavior (it accesses
tstate->next).

Changing your reproducer to create/wait for termination of threads in
a loop in a background thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 08:33:47 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 26 Feb 2013 07:33:47 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361864027.11.0.72673322227.issue16612@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I still can't see a reference to Cython in the PEP. Larry, I don't really mind adding a newly designed DSL for this, but regarding the implementation of the actual argument parser, could you at least add a short paragraph to the PEP that mentions it as worth being looked at? I mean, it already does all of this and generates optimised and streamlined code for fast unpacking of args and kwargs, although just from a typed Python function signature, not a full fledged DSL. I mean, you don't have to reuse that code, but it's certainly relevant to see how others have solved this. Years ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Tue Feb 26 08:44:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 07:44:27 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361864667.26.0.750616666602.issue16930@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

http://docs.python.org/devguide/committing.html#porting-changesets-between-the-two-major-python-versions-2-x-and-3-x now mentions both "hg graft" and "hg export|import".  Do you think this is enough or should we add a link to http://mercurial.selenic.com/wiki/FixingCaseCollisions too?

This could be added just after "On older version of Mercurial where hg graft is not available [or while grafting on case-insensitive filesystems] ...".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Tue Feb 26 08:52:40 2013
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 26 Feb 2013 07:52:40 +0000
Subject: [issue1744382] Read Write lock
Message-ID: <1361865160.43.0.497379400875.issue1744382@psf.upfronthosting.co.za>


Changes by Vladimir Rutsky <altsysrq at gmail.com>:


----------
nosy: +rutsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744382>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:08:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 08:08:41 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <3ZFXj50xJszNNc@mail.python.org>


Roundup Robot added the comment:

New changeset f3f23ecdb1c6 by Serhiy Storchaka in branch '2.7':
Issue #13555: Fix an integer overflow check.
http://hg.python.org/cpython/rev/f3f23ecdb1c6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:18:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 08:18:14 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1361866694.43.0.00494358041993.issue13555@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the report. Standard tests do not cover pickling/unpickling to real files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:20:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 08:20:58 +0000
Subject: [issue17298] Twisted test failure triggered by change in 2.7 branch
In-Reply-To: <1361831094.62.0.865591087681.issue17298@psf.upfronthosting.co.za>
Message-ID: <1361866858.61.0.800269873732.issue17298@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If this is a duplicate, it should be fixed by f3f23ecdb1c6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17298>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:39:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 08:39:39 +0000
Subject: [issue17299] Test cPickle with real files
Message-ID: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently cPickle module tested only with cStringIO.StringIO. However cPickle uses different code for cStringIO.StringIO, for file objects, and for general IO streams (i.e. io.BytesIO). Last two cases are not covered by tests.

----------
components: Tests
messages: 183028
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Test cPickle with real files
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17299>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:42:18 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Feb 2013 08:42:18 +0000
Subject: [issue16932] urlparse fails at parsing "www.python.org:80/"
In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za>
Message-ID: <1361868138.57.0.105780464579.issue16932@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I am noticing this one late. Sorry for that.
I agree that this is docs issue and I would like to fix it in this way.

Give the doc example as:

>>> urlparse('www.cwi.nl/%7Eguido/Python.html')
ParseResult(scheme='', netloc='', path='www.cwi.nl/%7Eguido/Python.html', params='', query='', fragment='')

Instead of

>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')

Which introduces a trick ":80" parsing and invokes the rule that Georg pointed out in the message. If I recollect, the point of the example was to point out that URLs (following 1808 RFC) should start with // for their netloc to be identified. Otherwise it is path.

A ":" on PORT without the "scheme :" is really tricky for any application, so it is right thing for the parser to identify anything before ":" as scheme and the implementation here is correct.

So, instead of fixing the example to identify the scheme as "www.cwi.nl" which is quite meaningless, the better way to fix the example will be, change the example to urlparse('www.cwi.nl/%7Eguido/Python.html') and the result remains the same.

I am going ahead with the fix. Thanks.

----------
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16932>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:42:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 08:42:24 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1361868144.2.0.745433185325.issue13555@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have opened issue17299 for testing issue.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13555>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:48:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 08:48:10 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1361868490.73.0.377852669324.issue14468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I went through all the messages on this issue, and I'll address them here.  There's enough material for two new issues (advanced FAQs, and improvements about Windows docs), and a few minor issues that can be discussed and fixed as part of this issues before closing it.


Chris in msg178927:

> I would break up the 20 lines of command-line commands.

Those are supposed to provide a complete overview, the individual commands are explained with inline comments, and more in details in the following section.  Is that OK?

> I would also state (or link to) something about forward-porting from
> 3.x to 3.y and that 2.7 should be kept separate

This should be covered now.

> I would also say (or link to) something about pushing all branches
> simultaneously.

This is not stated explicitly, but the fact that there's a single "hg push" at end implies it.  It might be mentioned somewhere together with "hg out".

> Lastly, might it be worth explicitly dividing the Mercurial stuff into separate sections for (1) everyone, and (2) committers?

This is done, explicitly in the FAQs, and more implicitly in committing.rst.  Committing.rst is written mainly for developers, whereas other parts of the devguide are more generic and valid for everyone.


Chris in msg178983:

> If applying to 2.7 or 3.2, etc. loses information (which has been 
> more often the case for me), then instead of merging I null-merge and 
> reapply the original patch.

This could be a FAQ.


Ezio in msg179853:

> At the end of committing.rst I can add a link to the "committers 
> faqs" in faqs.rst, and add more FAQs there.  Everything about null
> merges, head merges, merge conflicts, long-term development branches 
> etc. will go to faqs.rst.

This still needs to be done, and should be covered in a separate "Add 'advanced' mercurial FAQs for committers." issue.


Terry in msg182625:

> On Windows, ~/.hgrc is $HOME$/mercurial.ini.

This could either be mentioned right there, or if there are multiple occurrences of it, we could add a FAQs that briefly explains what .hgrc is and where to find it on Linux and Windows and link to it.

> with TortoiseHG/Workbench, one should better use the Settings dialogs 
> than edit directly.

This could also be mentioned in the aforementioned FAQ.


Terry in msg182633:

> Given the obnoxiousness of Command Prompt, and how foreign it is to working on > Windows, I think maybe there should be an addendum *somewhere*, 
> About  "run `make patchcheck`". The current Committing page gives
> "(or ./python.exe Tools/scripts/patchcheck.py on Windows)" as the windows
> equivalent. './' does not work on Windows. '.\' will, [...]

I suggest to create a new issue like "Improve Windows instructions in the devguide" and mention all these issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:49:07 2013
From: report at bugs.python.org (Martin Fiers)
Date: Tue, 26 Feb 2013 08:49:07 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1361868547.29.0.656384100866.issue12641@psf.upfronthosting.co.za>


Martin Fiers added the comment:

This also affects our software. I agree with Dan (danmbox): I don't understand; so many people depend on it and yet an out-of-the-box solution doesn't work.

I don't want to break the distutils package of our users because we use mingw. Within one Python script, I managed to fix it using this before the setup call:

if isWindows():
	"""
	Fix bug in cygwinccompiler: removed -mno-cygwin. This is fixed in cygwinccompiler_new.
	We hacked the distutils.ccompiler : def new_compiler : It uses sys.modules to fetch the compiler
	By modifying the sys.modules, we can choose our own compiler version.
	(this is a bug that's out there for quite some time)
	"""
	import cygwinccompiler_new
	import distutils.cygwinccompiler
	import sys
	sys.modules["distutils.cygwinccompiler"] = cygwinccompiler_new

..if I then later run setup(...), it will use my new cygwinccompiler_new, that has the '-mno-cygwin' line removed.

However, when you want to install new packages using pip from the command-line, I cannot find a suitable fix (except if I would replace the distutils.cygwinccompiler before pip'ing, then put it back). For afaik, distutils cannot be virtualenv'ed, right? So we cannot even fix the issue in a virtual environment.

If it is not possible to find out what version of gcc implemented it first; can't you simply use a pragmatic solution and run
"gcc -mno-cygwin": if it gives an error, then remove the option. That would need the least testing and would fix the issue.

----------
nosy: +Martin.Fiers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Feb 26 09:49:42 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Feb 2013 08:49:42 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <CAH_1eM3S7C88fdwoF=2ZNnsAtOb2SgCMiJFzh+XgHbPNqCb=CQ@mail.gmail.com>
Message-ID: <CAH_1eM3jhP6XZmm3h4zCN9WmL6Kfa5C6ptnqO-0wVm2s4FJ4SQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

And here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file29244/thread_local_concurrent.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________
-------------- next part --------------
--- Python-3.3.0/Modules/_threadmodule.c	2013-02-26 08:37:05.000000000 +0000
+++ python/Modules/_threadmodule.c	2013-02-26 08:48:24.000000000 +0000
@@ -769,6 +769,7 @@
 local_clear(localobject *self)
 {
     PyThreadState *tstate;
+    PyInterpreterState *interp;
     Py_CLEAR(self->args);
     Py_CLEAR(self->kw);
     Py_CLEAR(self->dummies);
@@ -776,13 +777,18 @@
     /* Remove all strong references to dummies from the thread states */
     if (self->key
         && (tstate = PyThreadState_Get())
-        && tstate->interp) {
-        for(tstate = PyInterpreterState_ThreadHead(tstate->interp);
-            tstate;
-            tstate = PyThreadState_Next(tstate)) {
+        && (interp = tstate->interp)) {
+        for (tstate = PyInterpreterState_ThreadHead(interp);
+             tstate;) {
             if (tstate->dict &&
-                PyDict_GetItem(tstate->dict, self->key))
+                PyDict_GetItem(tstate->dict, self->key)) {
                 PyDict_DelItem(tstate->dict, self->key);
+                /* the list of threads could have been altered, restart from
+                 * the head */
+                tstate = PyInterpreterState_ThreadHead(interp);
+            } else {
+                tstate = PyThreadState_Next(tstate);
+            }
         }
     }
     return 0;

From report at bugs.python.org  Tue Feb 26 09:51:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 08:51:19 +0000
Subject: [issue15034] Document best practices for exceptions
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1361868679.92.0.020413144422.issue15034@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm removing the "devguide" component and update the title accordingly.

----------
components: +Documentation -Devguide
title: Devguide should document best practices for stdlib exceptions -> Document best practices for exceptions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15034>
_______________________________________

From report at bugs.python.org  Tue Feb 26 10:02:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 09:02:27 +0000
Subject: [issue16932] urlparse fails at parsing "www.python.org:80/"
In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za>
Message-ID: <3ZFYv70FLfzNll@mail.python.org>


Roundup Robot added the comment:

New changeset 33895c474b4d by Senthil Kumaran in branch '2.7':
Fix issue16932: Fix the urlparse example. Remote :port when scheme is not specified to demonstrate correct behavior
http://hg.python.org/cpython/rev/33895c474b4d

New changeset 5442a77b925c by Senthil Kumaran in branch '3.2':
Fix issue16932: Fix the urlparse example. Remote :port when scheme is not specified to demonstrate correct behavior
http://hg.python.org/cpython/rev/5442a77b925c

New changeset 8928205f57f6 by Senthil Kumaran in branch '3.3':
Fix issue16932: Fix the urlparse example. Remote :port when scheme is not specified to demonstrate correct behavior
http://hg.python.org/cpython/rev/8928205f57f6

New changeset 9caad461936e by Senthil Kumaran in branch 'default':
Fix issue16932: Fix the urlparse example. Remote :port when scheme is not specified to demonstrate correct behavior
http://hg.python.org/cpython/rev/9caad461936e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16932>
_______________________________________

From report at bugs.python.org  Tue Feb 26 10:03:53 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Feb 2013 09:03:53 +0000
Subject: [issue16932] urlparse fails at parsing "www.python.org:80/"
In-Reply-To: <1357903769.2.0.674766943444.issue16932@psf.upfronthosting.co.za>
Message-ID: <1361869433.19.0.627710541821.issue16932@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I have fixed the docs issue. Thanks for the report and following up.

----------
assignee:  -> orsenthil
keywords:  -buildbot
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16932>
_______________________________________

From report at bugs.python.org  Tue Feb 26 10:52:42 2013
From: report at bugs.python.org (Andreas Hausmann)
Date: Tue, 26 Feb 2013 09:52:42 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361872362.74.0.91375598755.issue17296@psf.upfronthosting.co.za>


Andreas Hausmann added the comment:

That is correct.

Under 2.4 and 3.3 it should show neither the line "EXCEPTION ## EXCEPTION" nor the following line "TypeError: ('__init__() takes at least 2 arguments....."

That means, that in version 2.4 and 3.3 that unpickling problem doesn't exist. In version 2.4 I tested it myself; exactly, there is no problem. In version 3.3 I simply take your word, that the bug is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Tue Feb 26 10:56:54 2013
From: report at bugs.python.org (Andreas Hausmann)
Date: Tue, 26 Feb 2013 09:56:54 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361872614.88.0.73057299348.issue17296@psf.upfronthosting.co.za>


Andreas Hausmann added the comment:

A backport to 2.7 would be in the interest of the Zope community (I dare say ;)), at least in ours.

In our project, after having migrated to Zope 2.13/Python2.7 we found this bug and now we are quite worried what else might happen with our huge pickled database.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Tue Feb 26 11:01:41 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 26 Feb 2013 10:01:41 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361872901.37.0.984557937047.issue16612@psf.upfronthosting.co.za>


Larry Hastings added the comment:

As a rule I'm unlikely to mention things I haven't heard about.  I've never used Cython, and I don't recall anyone mentioning this technology previously.  Once skrah posts his alternative DSL proposal, I'll amend the PEP to discuss both these alternatives.

Can you point me to documentation on this Cython feature?

And, FWIW, the DSL was the interesting part for me.  I'm hoping someone else will step up and write the shiny new fast argument parsing API.  If it can be adapted out of existing working code, so much the better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Tue Feb 26 11:25:02 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 26 Feb 2013 10:25:02 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized preprocessor
	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <1361874302.12.0.864326792858.issue16612@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I mentioned it in a couple of places during the discussion, you might just have missed them.

The code that generates the unpacking C code starts here:

https://github.com/cython/cython/blob/4ebc647c2fa54179d25335b2dcf5d845e7fc9a79/Cython/Compiler/Nodes.py#L3068

and extends to here:

https://github.com/cython/cython/blob/4ebc647c2fa54179d25335b2dcf5d845e7fc9a79/Cython/Compiler/Nodes.py#L3641

As I said, Cython actually takes its signature information from normal Python signatures, which you can augment with type annotations in normal C style. So it's not really some fancy DSL behind it, just straight forward stuff like this:

    def func(a, int b, bytes c, unicode s, *, bint flag=False):
        ...

If you want to take a closer look, it's best to just write down a Python function and let Cython translate it for you to see the code that it generates for it.

And it's based on Cython's type system, so argument type conversions use Cython's support for things like copying mappings into structs, for example, or optimised builtin types unboxing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Tue Feb 26 11:28:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 10:28:15 +0000
Subject: =?utf-8?q?=5Bissue17300=5D_=D0=A1rash_when_deleting_deeply_recursive_isli?=
	=?utf-8?q?ce=28=29?=
Message-ID: <1361874495.09.0.394992661852.issue17300@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

http://permalink.gmane.org/gmane.comp.python.ideas/19669

>>> from itertools import islice, count
>>> it = count()
>>> for i in range(1000000):
...     it = islice(it, 0)
... 
>>> del it
Segmentation fault

This looks very similar to the crash in tee() (issue13454).

----------
assignee: serhiy.storchaka
components: Extension Modules
messages: 183041
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: ?rash when deleting deeply recursive islice()
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17300>
_______________________________________

From report at bugs.python.org  Tue Feb 26 11:30:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 10:30:02 +0000
Subject: [issue14010] deeply nested filter segfaults
In-Reply-To: <1329235106.54.0.737183388066.issue14010@psf.upfronthosting.co.za>
Message-ID: <1361874602.56.0.873169983324.issue14010@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +serhiy.storchaka
versions:  -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14010>
_______________________________________

From report at bugs.python.org  Tue Feb 26 11:36:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 10:36:47 +0000
Subject: =?utf-8?q?=5Bissue17300=5D_=D0=A1rash_when_deleting_deeply_recursive_iter?=
	=?utf-8?q?ator_wrappers?=
In-Reply-To: <1361874495.09.0.394992661852.issue17300@psf.upfronthosting.co.za>
Message-ID: <1361875007.05.0.145509450066.issue17300@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And same issue with filter:

>>> it = iter([])
>>> for i in range(1000000):
...     it = filter(None, it)
... 
>>> del it
Segmentation fault

----------
title: ?rash when deleting deeply recursive islice() -> ?rash when deleting deeply recursive iterator wrappers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17300>
_______________________________________

From report at bugs.python.org  Tue Feb 26 11:40:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Feb 2013 10:40:16 +0000
Subject: =?utf-8?q?=5Bissue17300=5D_=D0=A1rash_when_deleting_deeply_recursive_iter?=
	=?utf-8?q?ator_wrappers?=
In-Reply-To: <1361874495.09.0.394992661852.issue17300@psf.upfronthosting.co.za>
Message-ID: <1361875216.49.0.261173463455.issue17300@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Aha, this is a duplicate of issue14010.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> deeply nested filter segfaults

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17300>
_______________________________________

From report at bugs.python.org  Tue Feb 26 12:08:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Feb 2013 11:08:15 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <CAH_1eM3jhP6XZmm3h4zCN9WmL6Kfa5C6ptnqO-0wVm2s4FJ4SQ@mail.gmail.com>
Message-ID: <1677645312.64890423.1361876888632.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> And here's a patch.

Wouldn't it be better to expose and re-use the HEAD_LOCK and HEAD_UNLOCK
macros from pystate.c?
That said, I doubt this is the issue here. We are removing a string key pointing
to a localdummy object. Both are small atomic types not handled by the GC, so
I don't see how deallocating these objects could release the GIL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 12:13:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Feb 2013 11:13:19 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized
	preprocessor	into CPython trunk
In-Reply-To: <1361666951.91.0.802595852992.issue16612@psf.upfronthosting.co.za>
Message-ID: <1670601638.64901873.1361877193323.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> * Antoine: I've implemented shunting the bulk of Argument Clinic's
>   output into a separate file.  Please see Modules/zlibmodule.c
>   and Modules/zlibmodule_clinic.c for more.

Interesting, thanks :-)
Why do you need both clinic.write_clinic_file() and clinic.include_clinic_file() ?

> I don't suppose we can get some decisions made and some code checked
> in before the PyCon sprints...?

I suppose that depends on how quick everyone is.
But code can be written before the PEP is finally accepted, of course.

----------
title: Integrate "Argument Clinic" specialized preprocessor into CPython trunk -> Integrate "Argument Clinic" specialized preprocessor	into CPython trunk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Tue Feb 26 12:14:45 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Tue, 26 Feb 2013 11:14:45 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1361877285.36.0.958585306209.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Eli, I tried to preserve the style (and detail) of the rest of the docs of the respective version. If I bring the 3.3 version of find() into 2.7, then it will have a lot less detail than f.e. findall() as a sibling method on the same class: http://docs.python.org/2/library/xml.etree.elementtree.html#xml.etree.ElementTree.ElementTree

Is that intentional? If so, I'll happily provide adjusted patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Tue Feb 26 12:23:13 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 26 Feb 2013 11:23:13 +0000
Subject: [issue16612] Integrate "Argument Clinic" specialized
	preprocessor	into CPython trunk
In-Reply-To: <1354659537.54.0.587753848221.issue16612@psf.upfronthosting.co.za>
Message-ID: <jo813k0aaobdas9rmlwnfvhi.1361877787298@email.android.com>


Larry Hastings added the comment:

write_clinic_file tells Clinic to start writing to the clinic file, which I think is best to do at the very top of the file.  include_clinic_file spits out the #include, which you probably want near the bottom of the file, just before the static module declarations.  You can't put the #include at the top because it may refer to typedefs declared further down. 

Antoine Pitrou <report at bugs.python.org> wrote:

>
>Antoine Pitrou added the comment:
>
>> * Antoine: I've implemented shunting the bulk of Argument Clinic's
>>   output into a separate file.  Please see Modules/zlibmodule.c
>>   and Modules/zlibmodule_clinic.c for more.
>
>Interesting, thanks :-)
>Why do you need both clinic.write_clinic_file() and clinic.include_clinic_file() ?
>
>> I don't suppose we can get some decisions made and some code checked
>> in before the PyCon sprints...?
>
>I suppose that depends on how quick everyone is.
>But code can be written before the PEP is finally accepted, of course.
>
>----------
>title: Integrate "Argument Clinic" specialized preprocessor into CPython trunk -> Integrate "Argument Clinic" specialized preprocessor	into CPython trunk
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue16612>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16612>
_______________________________________

From report at bugs.python.org  Tue Feb 26 12:34:05 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 26 Feb 2013 11:34:05 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1361878445.42.0.493175270729.issue10527@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Tue Feb 26 13:43:36 2013
From: report at bugs.python.org (Dan)
Date: Tue, 26 Feb 2013 12:43:36 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1361882616.45.0.940882284842.issue12641@psf.upfronthosting.co.za>


Dan added the comment:

Nice partial work-around.

I think it's quite clear that the decision makers for this bug have not been making rational decisions for a year and a half, so we can't really expect change. This being the open-source world, the only recourse is publicizing the issue (or is there some bounty system for python?). So I suggest you blog about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Feb 26 13:53:28 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 26 Feb 2013 12:53:28 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361883208.41.0.902449096443.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Btw., where we are at this issue - I have seen many more loops over the threads (via PyThreadState_Next). I have a bad feeling that many of these loops have similar issues.

In this case, I am also not sure anymore that it really was a problem. I originally thought that in this loop, it would delete the local-dicts (which contained my Test-object/sqlite connection object). But it does not, it only deallocates a string and the dummy object there. The local-dicts were already been freed at Py_CLEAR(dummies).

I still tried to reproduce the crash in the testcase even when the interpreter is not shutting down (like it looks in my musicplayer app) but no success. I also wasn't able yet to get more debugging info about the musicplayer app crash.

Note that in the musicplayer app, I have the same workaround now as demonstrated in the testcase and there aren't any crashes anymore (so far - they were seldom anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:01:20 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 26 Feb 2013 13:01:20 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361883680.64.0.364878582837.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

> Wouldn't it be better to expose and re-use the HEAD_LOCK and HEAD_UNLOCK macros from pystate.c?

The macro-names HEAD_LOCK/HEAD_UNLOCK irritates me a bit. Protecting only the head would not be enough. Any tstate object could be invalidated. But actually, it protects any modification on the list (both in tstate_delete_common and in new_threadstate), as far as I see it.

But yes, it would be a good thing to export this locking functionality so other code can use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:08:13 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 13:08:13 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361884093.0.0.475035927647.issue13772@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
hgrepos: +176

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:08:51 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 13:08:51 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361884131.2.0.173087141597.issue13772@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
hgrepos:  -176

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:09:01 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 13:09:01 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361884141.26.0.324667479238.issue13772@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
hgrepos: +177

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:10:00 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 13:10:00 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361884200.41.0.567070539765.issue13772@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file29245/8bf88b31ebb7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:13:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 13:13:10 +0000
Subject: [issue17018] Inconsistent behaviour of methods waiting for child
	process
In-Reply-To: <1358954121.08.0.546295178726.issue17018@psf.upfronthosting.co.za>
Message-ID: <3ZFgSP4sVVzNT9@mail.python.org>


Roundup Robot added the comment:

New changeset 92003d9aae0e by Richard Oudkerk in branch '2.7':
Issue #17018: Make Process.join() retry if os.waitpid() fails with EINTR.
http://hg.python.org/cpython/rev/92003d9aae0e

New changeset 5fae31006724 by Richard Oudkerk in branch '3.2':
Issue #17018: Make Process.join() retry if os.waitpid() fails with EINTR.
http://hg.python.org/cpython/rev/5fae31006724

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17018>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:14:53 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 26 Feb 2013 13:14:53 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1677645312.64890423.1361876888632.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <CAH_1eM2s4tH_G5FNP9RZg8tnYKow3z6KJgDrZevuy7Qf=Qcr4A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Wouldn't it be better to expose and re-use the HEAD_LOCK and HEAD_UNLOCK
> macros from pystate.c?

I don't like holding locks before calling "alien" code, it's a recipe
for deadlocks: for example, if another thread-local object was
deallocated as part of the deallocation chain, we would call back into
local_clear(), and deadlock.

> That said, I doubt this is the issue here. We are removing a string key pointing
> to a localdummy object. Both are small atomic types not handled by the GC, so
> I don't see how deallocating these objects could release the GIL.

Yes, it shouldn't happen, the thread local dict is deallocated right
before (I initially thought the thread local dict was deallocated
here).

Without a proper backtrace, i'ts going to be hard to debug...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:23:03 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 26 Feb 2013 13:23:03 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361884983.86.0.484792146158.issue17223@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

The new test seems to be reliably failing on Windows:

======================================================================
FAIL: test_issue17223 (__main__.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Repos\cpython-dirty\lib\test\test_array.py", line 1075, in test_issue17223
    self.assertRaises(ValueError, a.tounicode)
AssertionError: ValueError not raised by tounicode

----------------------------------------------------------------------

----------
nosy: +sbt
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:24:25 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 13:24:25 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361885065.05.0.0608297918622.issue13772@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I tried the create-patch function, but it didn't work against bitbucket (produced an empty diff). So I'm attaching a diff explicitly.

----------
Added file: http://bugs.python.org/file29246/8bf88b31ebb7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:32:43 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 26 Feb 2013 13:32:43 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1361885563.48.0.442263734443.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Henrik. Yes, I think the change in 3.3 was intentional in order to avoid duplication that can be a source of errors. If ET.find() does exactly what ET.getroot().find() does, it suffices to mention it with a link. Since Element docs come first and arguably Element's methods are much more widely used, I think it's a good tradeoff. Any duplication is yet another place to remember fixing when problems in the documentation are discovered (like the original problem leading to this issue).

So for consistency you can make all methods point to Element's methods (just backport 3.3's version, but please verify that the code behavior is indeed as documented in earlier versions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:40:17 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 26 Feb 2013 13:40:17 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361886017.26.0.261445254925.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

> > Wouldn't it be better to expose and re-use the HEAD_LOCK and HEAD_UNLOCK
> > macros from pystate.c?

> I don't like holding locks before calling "alien" code, it's a recipe
> for deadlocks: for example, if another thread-local object was
> deallocated as part of the deallocation chain, we would call back into
> local_clear(), and deadlock.

Ah, yes. Right now, the head-lock is acquired while the GIL is held. So while the head-lock is held, we must not unlock the GIL. So this wouldn't work.

Btw., I think it also does happen already. While playing around with this test case, I sometimes encountered a deadlock at quit. I was thinking that it was the result of some badly written memory.

But I just saw this code (PyInterpreterState_Clear):

    HEAD_LOCK();
    for (p = interp->tstate_head; p != NULL; p = p->next)
        PyThreadState_Clear(p);
    HEAD_UNLOCK();

So, if something inside PyThreadState_Clear unlocks the GIL and some other thread acquires the GIL and then tries to HEAD_LOCK (for example, at thread exit), you have a classic deadlock.

A solution would be: Only acquire the head-mutex while the GIL is not held. Then, after you held the head-mutex, also acquire the GIL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 14:51:40 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 13:51:40 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za>
Message-ID: <1361886700.31.0.540407456369.issue13772@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Please disregard the patch 8bf88b31ebb7.

Antoine, Brian, or anyone else - would you please review the attached patch (b744517b90bc.diff)? It adds a test for creating directory symlinks that are non-local (don't depend on the current directory for reference), backs out Antoine's changes, and replaces them with directory detection that fixes this issue while maintaining directory detection.

I'm not super-confident about the implementation of the path-manipulation functions, and I would prefer to use the Python implementations of the path-manipulation (dirname and join) instead. If there are any suggestions in this regard, I'd appreciate them.

That said, the tests now pass for me on Windows (and I don't see why the tests wouldn't also pass on Linux).

----------
Added file: http://bugs.python.org/file29247/b744517b90bc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:04:06 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 26 Feb 2013 14:04:06 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361887446.57.0.0499151946732.issue15083@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Great, thanks.

Now looking forward to the patch getting rid of the module-level globals. One idea is explicitly pass the module into each testing class. The classes should not rely on anything global in this respect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:10:33 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 26 Feb 2013 14:10:33 +0000
Subject: [issue13555] cPickle MemoryError when loading large file (while
	pickle works)
In-Reply-To: <1323348723.51.0.524535293585.issue13555@psf.upfronthosting.co.za>
Message-ID: <1361887833.16.0.767750032197.issue13555@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/issue13555>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:11:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Feb 2013 14:11:53 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <1361886700.31.0.540407456369.issue13772@psf.upfronthosting.co.za>
Message-ID: <2131842814.65338392.1361887906997.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I'm not super-confident about the implementation of the
> path-manipulation functions, and I would prefer to use the Python
> implementations of the path-manipulation (dirname and join) instead.
> If there are any suggestions in this regard, I'd appreciate them.

>From an implementation standpoint, I would indeed prefer the path handling
functions to be written in Python.

>From a principle standpoint, I'm not sure it's a good idea for os.symlink()
to be non-atomic (there's a small race condition between reading the target's
attributes and creating the actual symlink).

Also, since in general you always know whether you're making a link to a
directory or a file, I'm not sure auto-detection is really a plus (except
that it makes things more familiar for Unix developers).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:13:40 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 26 Feb 2013 14:13:40 +0000
Subject: [issue7358] cStringIO not 64-bit safe
In-Reply-To: <1258645822.27.0.150067328286.issue7358@psf.upfronthosting.co.za>
Message-ID: <1361888020.59.0.568839862649.issue7358@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/issue7358>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:32:42 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 26 Feb 2013 14:32:42 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1361889162.32.0.782802335136.issue11367@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Thanks for working on this. It is always nice to see things moving.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:34:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Feb 2013 14:34:12 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361884983.86.0.484792146158.issue17223@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbpNMNZC+1C7zo30eNO5=fKTEDQ52r_+EVn7yH9RTaQMg@mail.gmail.com>


STINNER Victor added the comment:

On Windows, test_array can use an invalid surrogate pair to test this
issue: b'\xff\xdf\x61\x00' for example.

I don't know how to easily check the size of wchar_t.
ctypes.sizeof(ctypes.c_wchar) can be used, but ctypes is not always
available. sys.unicode is now always 0x10ffff since Python 3.3.
PyUnicode_GetMax() is not accessible in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 15:57:19 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Feb 2013 14:57:19 +0000
Subject: [issue13772] listdir() doesn't work with non-trivial symlinks
In-Reply-To: <2131842814.65338392.1361887906997.JavaMail.root@zimbra10-e2.priv.proxad.net>
Message-ID: <7E79234E600438479EC119BD241B48D636A15C16@CH1PRD0611MB432.namprd06.prod.outlook.com>


Jason R. Coombs added the comment:

Thanks for the suggestions.

> Antoine Pitrou added the comment:
>
> From an implementation standpoint, I would indeed prefer the path handling
> functions to be written in Python.

Is there an example of how a function like win32_symlink could call into ntpath.dirname()? I believe the reason we did not invoke ntpath was due to a possible race condition where the Python interpreter might not be fully started before os.symlink is invoked. Perhaps there are mitigating factors, but I'm not familiar enough with the Python internals to know what's safe and what is not (or even how to invoke that behavior).

> From a principle standpoint, I'm not sure it's a good idea for os.symlink()
> to be non-atomic (there's a small race condition between reading the target's
> attributes and creating the actual symlink).

I agree there exists a small possibility of a race condition here. I believe this race condition is of little concern to the vast majority of use-cases. For those use cases where a race condition might be a factor, the target_is_directory parameter may be supplied by that code to overcome the condition.

Furthermore, since the Windows APIs don't provide a way to match the symlink creation with its target, it's not possible to avoid this race condition.

> Also, since in general you always know whether you're making a link to a
> directory or a file, I'm not sure auto-detection is really a plus (except that it
> makes things more familiar for Unix developers).

For the vast majority of use cases, target detection will behave much like symlinks do in Unix, which allows os.symlink to be used portably without specifically accounting for Windows behavior. I'm not as concerned about Windows programmers using Python (who might not mind specifying the directory-ness of their targets), but Python programs written by Unix developers running on Windows. In the latter use-case, it's much harder to have those programs adopt an additional parameter to support Windows. I could imagine some library maintainers rejecting a patch that includes target_is_directory just because it's not elegant and seems unnecessary from a Unix programmer's perspective. For that use case and in order to support the general expectation that os.symlink should provide the most uniform behavior it can, the directory detection is highly valuable.

Indeed, both your initial usage of the function and Larry Hastings' initial reaction betray the expectation that os.symlink should create a directory-type symlink when the target is a directory. I don't see how it's not a huge plus to support a developer's expectations when possible.

Personally, I would prefer to not have the parameter at all. Unfortunately, to support cases where one might need to create directory symlinks to non-existent targets, the parameter is necessary. However, I'd like to limit its required usage to only the cases where it's necessary.

> I'm not against restoring detection, but it should be non-buggy and
> correctly unit-tested :)

I'd like to focus on restoring detection, which was vetted and approved in the original implementation. Obviously, I can't guarantee that it doesn't have additional bugs. Provably-correct code is expensive and way outside the scope of this effort. As you could see from your patch, there were tests capturing the desired behavior. That test has been restored. Additionally, this patch includes a new test to capture the case of a non-local link (a behavior that was never tested for Unix symlinks).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13772>
_______________________________________

From report at bugs.python.org  Tue Feb 26 16:47:06 2013
From: report at bugs.python.org (netrick)
Date: Tue, 26 Feb 2013 15:47:06 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361893626.73.0.0576427816108.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Mark, you are my hero! I can't believe it got fixed that fast.

I confirm that for me, the fix works. I just replaced pyw.exe in python33 folder and the bug is gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 16:58:46 2013
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 26 Feb 2013 15:58:46 +0000
Subject: [issue17263] crash when tp_dealloc allows other threads
In-Reply-To: <1361414271.61.0.154662693899.issue17263@psf.upfronthosting.co.za>
Message-ID: <1361894326.3.0.982886637554.issue17263@psf.upfronthosting.co.za>


Albert Zeyer added the comment:

Btw., this turns out to be at least 4 kind of separate bugs:

1. The crash from the testcase - when the interpreter shuts down.

2. Maybe the crash from my musicplayer app - if that is a different one. But very related to the first one.

3. Many loops over the thread states could have code inside which might release the GIL. All these loops can crash because the thread state could be invalidated in the meanwhile.

4. Possible deadlock with HEAD_LOCK usage.

Should we make separate issue reports for each?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17263>
_______________________________________

From report at bugs.python.org  Tue Feb 26 16:59:24 2013
From: report at bugs.python.org (netrick)
Date: Tue, 26 Feb 2013 15:59:24 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361894364.07.0.574382944621.issue17290@psf.upfronthosting.co.za>


netrick added the comment:

Vinay, is there a chance that the fix will be included in 3.3.1?

If not, is there a chance to create a python 3.3 installer with the patched pyw.exe? As I know nothing of python packaging so I have no idea how to do it and it would be very handy for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 17:29:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 16:29:59 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <3ZFlqV2K6CzNsf@mail.python.org>


Roundup Robot added the comment:

New changeset 5fddaa709d6b by Vinay Sajip in branch '3.3':
Closes #17290: Loading cursor now does not persist when launching GUI scripts.
http://hg.python.org/cpython/rev/5fddaa709d6b

New changeset 0d55fb0217f1 by Vinay Sajip in branch 'default':
Closes #17290: Merged fix from 3.3.
http://hg.python.org/cpython/rev/0d55fb0217f1

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 17:33:18 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 26 Feb 2013 16:33:18 +0000
Subject: [issue17290] pythonw - loading cursor bug when launching scripts
In-Reply-To: <1361741672.29.0.168357428516.issue17290@psf.upfronthosting.co.za>
Message-ID: <1361896398.05.0.939193801666.issue17290@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Plus, the standalone launcher has already been updated (the version displayed in the installer and the resource version should be 1.0.1.2):

https://bitbucket.org/vinay.sajip/pylauncher/downloads

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17290>
_______________________________________

From report at bugs.python.org  Tue Feb 26 18:35:50 2013
From: report at bugs.python.org (Maximiliano Curia)
Date: Tue, 26 Feb 2013 17:35:50 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
In-Reply-To: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>
Message-ID: <1361900150.1.0.660832610717.issue17251@psf.upfronthosting.co.za>


Maximiliano Curia added the comment:

Hi,

This is still present in the current mercurial.

I'm attaching a patch that fixes the issue.

Thanks.

----------
keywords: +patch
nosy: +maxy at debian.org
versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29248/issue_17251.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Tue Feb 26 19:00:15 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 26 Feb 2013 18:00:15 +0000
Subject: [issue17299] Test cPickle with real files
In-Reply-To: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>
Message-ID: <1361901615.16.0.397349352227.issue17299@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17299>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:16:31 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 26 Feb 2013 19:16:31 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
In-Reply-To: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>
Message-ID: <1361906191.17.0.187485485429.issue17283@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:23:01 2013
From: report at bugs.python.org (Christopher King)
Date: Tue, 26 Feb 2013 19:23:01 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361906581.44.0.262017644838.issue7423@psf.upfronthosting.co.za>


Christopher King added the comment:

This is a crazy and unexpected behavior.  (Moreover, the fact that Python has dynamic scope *only if you forget to initialize a variable* is even more crazy and unexpected.)  To provide unsurprising behavior (i.e. behavior compatible with that of a list comprehension) the generator above should "unwrap" (i.e. reduce) to:

def g1(x):
    for y in 'c':
        yield x+y
l = []
for x in 'ab':
    l.append(g1(x))
print l
print map(list, l)

i.e. the variables referenced by, but not initialized by, the innermost generator should add extra parameters to the generated generator function.

----------
nosy: +Christopher.King

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:36:42 2013
From: report at bugs.python.org (Christopher King)
Date: Tue, 26 Feb 2013 19:36:42 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361907402.78.0.543465376254.issue7423@psf.upfronthosting.co.za>


Christopher King added the comment:

Also tested and broken in Py3k.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:38:39 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Feb 2013 19:38:39 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361907519.15.0.77695181335.issue7423@psf.upfronthosting.co.za>


R. David Murray added the comment:

The behavior is deeply baked into how Python does closures and scoping. It shows up elsewhere than generators (eg: nested function definitions; usually encountered when using lambdas).  So, this behavior isn't going to change, it's just one of a relatively small handful of odd things you have to learn in order to grok Python.  (And yes, it is surprising...that's why there's a FAQ for it.)

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:47:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 19:47:30 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <3ZFrCP3PwqzRZs@mail.python.org>


Roundup Robot added the comment:

New changeset eb45fd74db34 by Petri Lehtinen in branch '2.7':
Issue #14720: Enhance sqlite3 microsecond conversion, document its behavior
http://hg.python.org/cpython/rev/eb45fd74db34

New changeset ae25a38e6c17 by Petri Lehtinen in branch '3.2':
Issue #14720: Enhance sqlite3 microsecond conversion, document its behavior
http://hg.python.org/cpython/rev/ae25a38e6c17

New changeset 17673a8c7083 by Petri Lehtinen in branch '3.3':
Issue #14720: Enhance sqlite3 microsecond conversion, document its behavior
http://hg.python.org/cpython/rev/17673a8c7083

New changeset 0db66afbd746 by Petri Lehtinen in branch 'default':
Issue #14720: Enhance sqlite3 microsecond conversion, document its behavior
http://hg.python.org/cpython/rev/0db66afbd746

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:48:39 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Tue, 26 Feb 2013 19:48:39 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361908119.23.0.594014452583.issue10572@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Thanks Ned! Attached is an update for sqlite tests with the right patch format (issue10572-sqlite3-2.patch).

May make sense to mention the hg diff --git format in:
http://docs.python.org/devguide/patch.html

----------
Added file: http://bugs.python.org/file29249/issue10572-sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:48:40 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 26 Feb 2013 19:48:40 +0000
Subject: [issue14720] sqlite3 microseconds
In-Reply-To: <1336113066.83.0.671734474285.issue14720@psf.upfronthosting.co.za>
Message-ID: <1361908120.28.0.744300869536.issue14720@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14720>
_______________________________________

From report at bugs.python.org  Tue Feb 26 20:52:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Feb 2013 19:52:50 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361908370.07.0.495063163632.issue16930@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> To clarify my original comment, I got an error about
> ConfigParser.py/configparser.py even when that file was not part of the 
> change.

Would you mind reporting a Mercurial bug then? (http://bz.selenic.com/)

As for mentioning it in the devguide, I don't think we want to mention every other utility's quirk.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:00:51 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Feb 2013 20:00:51 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1361908851.69.0.363320375787.issue12641@psf.upfronthosting.co.za>


?ric Araujo added the comment:

> I don't understand; so many people depend on it and yet an out-of-the-box solution doesn't work.

It is because of the combinations of some facts:
- Python contributors are volunteers;
- distutils is used a lot and quite brittle, which is a combination that makes us extremely cautious with changes;
- I am not a Windows user or developer;
- Martin knows Windows but apparently not Cygwin;
- nobody submitted patches until this month;
- nobody reviewed patches after they were attached.

You can choose to believe that we are unresponsible, stupid, etc. or accept that in an open, volunteer-based project, subtle changes in a niche part of the code are not committed right away.  Whatever we do, we get blamed for moving too slowly and for changing Python too fast (not by the same people :).

The good news is that Roumev submitted clear patches, and that Trent Nelson put together Snakebite, a set of computers for Python developers that run various OSes including Windows.  Using these machines to test the patches, we can now make progress.

----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:12:07 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Tue, 26 Feb 2013 20:12:07 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361909527.43.0.987373353775.issue10572@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Attach updated patch for lib2to3 (issue10572-lib2to3-2.patch)

----------
Added file: http://bugs.python.org/file29250/issue10572-lib2to3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:14:58 2013
From: report at bugs.python.org (Christopher King)
Date: Tue, 26 Feb 2013 20:14:58 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361909698.39.0.566010761402.issue7423@psf.upfronthosting.co.za>


Christopher King added the comment:

Only the implementation of *generators* needs to change to remedy this bug.  Please see the example I included.  By closing the generated generator function over free the free variables in the generator expression, you can avoid dynamic scoping entirely and provide expected behavior.

The reason I claim this behavior is surprising and incorrect is because generator expressions are touted as being able to replace list comprehensions, when in fact they are not due to this bug.  Even the generator expression PEP claims: "This PEP introduces generator expressions as a high performance, memory efficient generalization of list comprehensions".

Until this bug is fixed, generator expressions are NOT a generalization of list comprehensions, and hence CPython is in violation of the PEP as accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:26:01 2013
From: report at bugs.python.org (Christopher King)
Date: Tue, 26 Feb 2013 20:26:01 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361910361.2.0.0968473017176.issue7423@psf.upfronthosting.co.za>


Christopher King added the comment:

Quote from Guido:

"""In general the value of every free variable used anywhere 
except in the outer expression should be captured; [...] This 
should give the least surprising semantics in a variaty of use 
cases."""

Source: http://bugs.python.org/issue872326#msg45190

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:28:29 2013
From: report at bugs.python.org (Martin Fiers)
Date: Tue, 26 Feb 2013 20:28:29 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1361910509.79.0.946085229862.issue12641@psf.upfronthosting.co.za>


Martin Fiers added the comment:

Dear Eric,

I never said that anyone of these volunteers is unresponsible/stupid/whatsoever. It was also never my intention to express myself in this way, so I apologize if you felt harmed in any way. I was just suprised that this issue exists for so long. And since I only recently started developing on Windows, I was a bit knocked over by the additional effort that was needed to get things working (for which I blame Windows, not Python!). I've been developing for some time now and I understand completely that it's far from trivial; given the complexity of the software and fragility of distutils. So kudos to the developers that put their hours into this! 

Anyway, I have a workaround using some distutils manipulations now (see my previous post), which works for now, and I'm looking forward to a permanent fix!

With best regards,
Martin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:28:43 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 26 Feb 2013 20:28:43 +0000
Subject: [issue17301] An in-place version of many bytearray methods is needed
Message-ID: <1361910523.06.0.491264384267.issue17301@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

bytearray has many methods that return a *new* bytearray object rather than applying the transformation to modify the bytearray in place.  Given that one use of bytearray's is to avoid making extra copies... There should be in-place variants of the following methods:

ljust
lower
lstrip
rjust
rstrip
strip
swapcase
title
translate
upper

especially so for the methods that don't change the length or move data around such as translate, lower, upper, swapcase and title.

----------
components: Interpreter Core
keywords: easy
messages: 183082
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: An in-place version of many bytearray methods is needed
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17301>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:38:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Feb 2013 20:38:42 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361911122.96.0.572187413197.issue7423@psf.upfronthosting.co.za>


R. David Murray added the comment:

I hear what you are saying, but the "generalization" does not mean that they work exactly the same way.  The whole point of generators is that execution is lazy, which is what leads to the difference in behavior.  

The generator function *is* closed over the free variables.  That's what leads to the difference in behavior: the generator uses the value the free variable has when the generator executes.  I don't believe there is any practical way to implement what you are suggesting, even if we wanted to...which we would not be, since it would constitute a backward incompatible change in behavior.

Note also that this behavior of closures is not unique to Python.  See for example http://www.javascriptkit.com/javatutors/closures2.shtml.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:50:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Feb 2013 20:50:58 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361911858.14.0.533332472088.issue7423@psf.upfronthosting.co.za>


R. David Murray added the comment:

To be honest I don't understand the sentence from Guido that you are quoting (even reading the issue I don't think I have the full context), but what we wound up with was what he wound up wanting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:53:34 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Feb 2013 20:53:34 +0000
Subject: [issue16931] mention work-around to create diffs in default/non-git
	mode
In-Reply-To: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za>
Message-ID: <1361912014.31.0.291269473618.issue16931@psf.upfronthosting.co.za>


Ned Deily added the comment:

However this is resolved, the information in the devguide should be consistent.  AFAICT, the recommendation to use hg "git" format is currently only mentioned in the Committing section (http://docs.python.org/devguide/committing.html#minimal-configuration) but not elsewhere, in particular, not http://docs.python.org/devguide/patch.html. (This was brought up in Issue10572.) Perhaps both sections could reference a FAQ entry which includes the Rietveld caveats.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16931>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:54:45 2013
From: report at bugs.python.org (karl)
Date: Tue, 26 Feb 2013 20:54:45 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
Message-ID: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>


New submission from karl:

Are there plans to develop an HTTP/2.0 library in parallel of the specification development? It will not be ready before years, but it would be good to have an evolving implementation. Or should it be done outside of python.org?

Reference: https://github.com/http2

----------
components: Library (Lib)
messages: 183086
nosy: karlcow
priority: normal
severity: normal
status: open
title: HTTP/2.0 - Implementations/Testing efforts
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:56:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Feb 2013 20:56:00 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1361912160.8.0.374021666887.issue10572@psf.upfronthosting.co.za>


Ned Deily added the comment:

Geoff, thanks, it is documented elsewhere in the devguide but it should be mentioned there as well.  I've added a note to Issue16931.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Tue Feb 26 21:57:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Feb 2013 20:57:09 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
In-Reply-To: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>
Message-ID: <1361912229.85.0.893240886137.issue17302@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It should certainly be done outside of python.org.
Also, I think the stdlib already lacks some HTTP/1.1 features, better start there...

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:20:20 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 26 Feb 2013 21:20:20 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
In-Reply-To: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>
Message-ID: <1361913620.0.0.163090842266.issue17302@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Yes, feature complete of 1.1 will be a start. :(

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:28:54 2013
From: report at bugs.python.org (Joar Wandborg)
Date: Tue, 26 Feb 2013 21:28:54 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361914134.42.0.0410527287918.issue17267@psf.upfronthosting.co.za>


Joar Wandborg added the comment:

New patch, removed whitespace change and unnecessary test.

add_time_timedelta arg `factor` will not be changed, in order to preserve uniformity.

----------
Added file: http://bugs.python.org/file29251/issue17267-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:33:30 2013
From: report at bugs.python.org (Christopher King)
Date: Tue, 26 Feb 2013 21:33:30 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361914410.74.0.016426355445.issue7423@psf.upfronthosting.co.za>


Christopher King added the comment:

> I hear what you are saying, but the "generalization" does not mean
> that they work exactly the same way.

Correct.  But it does mean that the functionality of one (generator expressions) is a superset of the functionality of the other (list comprehensions).  That is currently not the case.

> The whole point of generators is that execution is lazy, which is
> what leads to the difference in behavior.

No.  That the innermost generator isn't closed over its free variables is what leads to the difference in behavior.

> The generator function *is* closed over the free variables.  That's
> what leads to the difference in behavior: the generator uses the
> value the free variable has when the generator executes.

We're using the term "closure" in two different ways.  Coming from a FP background (where comprehensions first found their way into programming languages), I mean it to close over the value of the variable.  I understand that in Python it closes over the variable itself.  In the context of a comprehension, I claim that the latter is useless and surprising behavior.

> I don't believe there is any practical way to implement what you are
> suggesting

Again, please see the example in my original post.  The generic algorithm is simple: for every generator expression syntactically nested inside another, walk the AST of the inner generator expression's output expression.  Do not enter lambdas.  Recursively apply this algorithm for any generator expressions syntactically nested in the inner generator expression.  For every variable referenced which is not bound by the inner generator expression, add it as a parameter to the generated inner generator function, and add it as an argument when calling the inner generator function from the outer generator function.

> even if we wanted to...which we would not be, since it would
> constitute a backward incompatible change in behavior.

You can't honestly tell me anyone relies on the current behavior of nested generators.

Furthermore, my assertion is that the current behavior is in violation of the language specification.  If "backward-incompatible changes in behavior" was a legitimate excuse for refusing to remedy implementation/specification disparities, then it would apply to every Python bug ever.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:38:25 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Feb 2013 21:38:25 +0000
Subject: [issue17303] Fix test discovery for test_future*
Message-ID: <1361914705.71.0.738486694226.issue17303@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's the fix for test discovery of test_future* (particularly test_future3).  Without the patch, running 'python -m unittest discover Lib/test/ "test_future*"' results in an error in test_future3.py, due to test_future.py's FutureTest.test_future3 removing test_future3 from sys.modules by way of support.unload.  The patch replaces all instances of support.unload with a support.CleanImport context manager.

The patch also replaces test_main() in all test_future*.py modules, just for good measure.

----------
components: Tests
files: test_future_discovery.diff
keywords: patch
messages: 183092
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_future*
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29252/test_future_discovery.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17303>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:40:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Feb 2013 21:40:08 +0000
Subject: [issue17303] Fix test discovery for test_future*
In-Reply-To: <1361914705.71.0.738486694226.issue17303@psf.upfronthosting.co.za>
Message-ID: <1361914808.49.0.437229076192.issue17303@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Correction: ...all instances of support.unload *in test_future.py* with support.CleanImport...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17303>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:52:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Feb 2013 21:52:42 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <3ZFtzs3lnBzRf5@mail.python.org>


Roundup Robot added the comment:

New changeset 66e9d0185b0f by Victor Stinner in branch '3.3':
Issue #17223: Fix test_array on Windows (16-bit wchar_t/Py_UNICODE)
http://hg.python.org/cpython/rev/66e9d0185b0f

New changeset 5aaf6bc1d502 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17223: Fix test_array on Windows (16-bit wchar_t/Py_UNICODE)
http://hg.python.org/cpython/rev/5aaf6bc1d502

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 22:54:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Feb 2013 21:54:13 +0000
Subject: [issue17223] Initializing array.array with unicode type code and
	buffer segfaults
In-Reply-To: <1361144705.32.0.225799767897.issue17223@psf.upfronthosting.co.za>
Message-ID: <1361915653.25.0.571605182529.issue17223@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"It was discussed to add new formats for UCS1, UCS2 and UCS4 formats to the array module, but nobody implemented the idea. The "u" format is kept unchanged (use Py_UNICODE / wchar_t) for backward compatibility with Python 3.2."

See also issue #13072 for this discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17223>
_______________________________________

From report at bugs.python.org  Tue Feb 26 23:06:54 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Feb 2013 22:06:54 +0000
Subject: [issue17304] Fix test discovery for test_hash.py
Message-ID: <1361916414.01.0.225881852868.issue17304@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: Tests
files: test_hash_discovery.diff
keywords: patch
nosy: brett.cannon, ezio.melotti, zach.ware
priority: normal
severity: normal
status: open
title: Fix test discovery for test_hash.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29253/test_hash_discovery.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17304>
_______________________________________

From report at bugs.python.org  Tue Feb 26 23:10:52 2013
From: report at bugs.python.org (Emil Lind)
Date: Tue, 26 Feb 2013 22:10:52 +0000
Subject: [issue16039] imaplib: unlimited readline() from connection
In-Reply-To: <1348569370.53.0.568109495954.issue16039@psf.upfronthosting.co.za>
Message-ID: <1361916652.48.0.797273397688.issue16039@psf.upfronthosting.co.za>


Emil Lind added the comment:

I'm uploading my first patch. 
Heavily based on the related issues for ftplib and poplib.
Need help with review and a few questions...

Q1: Is the error Exception the right way to handle the "breach" (disconnects client?) or is there a better way? Like a 'BAD' response...

Q2: I'm not sure how to best modify the test_imaplib for this patch. I'm guessing a make_server where the client gets MAXLINE+1 bytes of data and validates exception. But it's above my abilities right now...

I welcome any input, thanks. 

note: patch seems to apply to 2.7, 3.2, 3.3, 3.4

----------
keywords: +patch
nosy: +Emil.Lind
Added file: http://bugs.python.org/file29254/imaplib.issue16039.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16039>
_______________________________________

From report at bugs.python.org  Tue Feb 26 23:19:19 2013
From: report at bugs.python.org (karl)
Date: Tue, 26 Feb 2013 22:19:19 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
In-Reply-To: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>
Message-ID: <1361917159.62.0.523563804235.issue17302@psf.upfronthosting.co.za>


karl added the comment:

agreed on HTTP/1.1, is there a plan to fix it too ;) because the current http.server seems to be untouchable without breaking stuff all around :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Tue Feb 26 23:29:07 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Feb 2013 22:29:07 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361917747.21.0.646757711584.issue7423@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, we're a bit more nuanced about backward compatibility than that :)

I doubt that people *intentionally* rely on the behavior, true, so a change could conceivably be made in a new release.

At this point you need to take your arguments to python-ideas or python-dev (probably the latter), where the people who built this PEP and its implementation can address your concerns better than I can.  I could be wrong, since I'm just a user of generators, not one of the implementors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Wed Feb 27 00:49:41 2013
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 26 Feb 2013 23:49:41 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
In-Reply-To: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>
Message-ID: <1361922581.27.0.284318334899.issue17251@psf.upfronthosting.co.za>


Demian Brecht added the comment:

According to some digging around that I've done, this issue may be invalid:

(I couldn't find an RFC or detailed spec of the LWP format, so reading from libwww-perl source @ http://cpansearch.perl.org/src/GAAS/libwww-perl-5.836/lib/HTTP/Cookies.pm)

# Try with a more general domain, alternately stripping
# leading name components and leading dots.  When this
# results in a domain with no leading dot, it is for
# Netscape cookie compatibility only:
#
# a.b.c.net	Any cookie
# .b.c.net	Any cookie
# b.c.net	Netscape cookie only
# .c.net	Any cookie

So, www.domain.com is not a valid LWP domain and therefore, unless I'm missing something, the module is functioning as expected.

----------
nosy: +dbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Wed Feb 27 00:51:23 2013
From: report at bugs.python.org (Maximiliano Curia)
Date: Tue, 26 Feb 2013 23:51:23 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
In-Reply-To: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>
Message-ID: <1361922683.26.0.258637671047.issue17251@psf.upfronthosting.co.za>


Changes by Maximiliano Curia <maxy at debian.org>:


Removed file: http://bugs.python.org/file29248/issue_17251.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Wed Feb 27 01:01:05 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 00:01:05 +0000
Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and
	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1361923265.63.0.396277431005.issue16901@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16901>
_______________________________________

From report at bugs.python.org  Wed Feb 27 01:05:13 2013
From: report at bugs.python.org (karl)
Date: Wed, 27 Feb 2013 00:05:13 +0000
Subject: [issue12921] http.server.BaseHTTPRequestHandler.send_error and
	trailing newline
In-Reply-To: <1315334514.02.0.137561826697.issue12921@psf.upfronthosting.co.za>
Message-ID: <1361923513.29.0.453398728976.issue12921@psf.upfronthosting.co.za>


karl added the comment:

Testing your code in Listing 1

? curl -sI http://localhost:9000/
HTTP/1.0 501 Unsupported method ('HEAD')
Server: BaseHTTP/0.6 Python/3.3.0
Date: Tue, 26 Feb 2013 23:38:32 GMT
Content-Type: text/html;charset=utf-8
Connection: close

So this is normal, http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-6.6.2

except that it would be better to use "501 Not Implemented" through the prose is optional. The content-type is also kind of useless. That would deserve to open another bug.


And

? curl http://localhost:9000/
Server: BaseHTTP/0.6 Python/3.3.0
Date: Tue, 26 Feb 2013 23:39:46 GMT
Content-Type: text/html;charset=utf-8
Connection: close

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 500</p>
        <p>Message: Traceback (most recent call last):
  File "server.py", line 9, in do_GET
    assert(False)
AssertionError
.</p>
        <p>Error code explanation: 500 - Server got itself in trouble.</p>
    </body>
</html>

OK. The server is answering with HTTP/1.0 and then a Traceback? which has nothing to do here.


We can see that in more details with a telnet

? telnet localhost 9000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost:9000

HTTP/1.0 500 Traceback (most recent call last):
  File "server.py", line 9, in do_GET
    assert(False)
AssertionError

Server: BaseHTTP/0.6 Python/3.3.0
Date: Tue, 26 Feb 2013 23:49:04 GMT
Content-Type: text/html;charset=utf-8
Connection: close

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 500</p>
        <p>Message: Traceback (most recent call last):
  File "server.py", line 9, in do_GET
    assert(False)
AssertionError
.</p>
        <p>Error code explanation: 500 - Server got itself in trouble.</p>
    </body>
</html>

Note that when not sending the traceback with the following code

#!/usr/bin/env python3.3

import http.server
import traceback

class httphandler(http.server.BaseHTTPRequestHandler):
  def do_GET(self):
    try:
      assert(False)
    except:
      self.send_error(500)

if __name__=='__main__':
  addr=('',9000)
  http.server.HTTPServer(addr,httphandler).serve_forever()

Everything is working well.

? telnet localhost 9000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost:9000

HTTP/1.0 500 Internal Server Error
Server: BaseHTTP/0.6 Python/3.3.0
Date: Tue, 26 Feb 2013 23:51:46 GMT
Content-Type: text/html;charset=utf-8
Connection: close

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 500</p>
        <p>Message: Internal Server Error.</p>
        <p>Error code explanation: 500 - Server got itself in trouble.</p>
    </body>
</html>
Connection closed by foreign host.

I'm looking at http://hg.python.org/cpython/file/3.3/Lib/http/server.py#l404

For the second part of your message. I don't think the two issues should be mixed. Maybe open another bug report.

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12921>
_______________________________________

From report at bugs.python.org  Wed Feb 27 01:10:20 2013
From: report at bugs.python.org (karl)
Date: Wed, 27 Feb 2013 00:10:20 +0000
Subject: [issue12921] http.server.BaseHTTPRequestHandler.send_error and
	trailing newline
In-Reply-To: <1315334514.02.0.137561826697.issue12921@psf.upfronthosting.co.za>
Message-ID: <1361923820.4.0.181271524916.issue12921@psf.upfronthosting.co.za>


karl added the comment:

OK I had understand a bit better. 

self.send_error(code, msg) is used for

* The body
* The HTTP header
* and the log

That's bad, very bad.

I do not think it should be used for the HTTP Header at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12921>
_______________________________________

From report at bugs.python.org  Wed Feb 27 01:27:02 2013
From: report at bugs.python.org (karl)
Date: Wed, 27 Feb 2013 00:27:02 +0000
Subject: [issue12921] http.server.BaseHTTPRequestHandler.send_error and
	trailing newline
In-Reply-To: <1315334514.02.0.137561826697.issue12921@psf.upfronthosting.co.za>
Message-ID: <1361924822.64.0.64886963862.issue12921@psf.upfronthosting.co.za>


karl added the comment:

ok I modify the code of server.py so that the server doesn't send the private message but the one which is already assigned by the library as it should. If there is a need for customization, there should be two separate variables, but which could lead to the same issues.

After modifications this is what I get.

? telnet localhost 9000
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost:9000

HTTP/1.0 500 Internal Server Error
Server: BaseHTTP/0.6 Python/3.3.0
Date: Wed, 27 Feb 2013 00:21:21 GMT
Content-Type: text/html;charset=utf-8
Connection: close

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
        <title>Error response</title>
    </head>
    <body>
        <h1>Error response</h1>
        <p>Error code: 500</p>
        <p>Message: Traceback (most recent call last):
  File "server.py", line 11, in do_GET
    assert(False)
AssertionError
.</p>
        <p>Error code explanation: 500 - Server got itself in trouble.</p>
    </body>
</html>
Connection closed by foreign host.


I joined the patch: server.issue12921.patch

----------
keywords: +patch
Added file: http://bugs.python.org/file29255/server.issue12921.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12921>
_______________________________________

From report at bugs.python.org  Wed Feb 27 01:45:02 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 00:45:02 +0000
Subject: [issue16942] urllib still doesn't support persistent connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361925902.95.0.321770562116.issue16942@psf.upfronthosting.co.za>


Demian Brecht added the comment:

http://bugs.python.org/issue1690 seems to be a duplicate of this one (at least the initial report). 16901 (imho) is documented more clearly than this one, so can this one be closed as duplicate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16942>
_______________________________________

From report at bugs.python.org  Wed Feb 27 02:32:46 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Wed, 27 Feb 2013 01:32:46 +0000
Subject: [issue17305] IDNA2008 encoding missing
Message-ID: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>


New submission from Marten Lehmann:

Since Python 2.3 the idna encoding is available for Internationalized Domain Names. But the current encoding doesn't work according to the latest version of the spec.

There is a new IDNA2008 specification (RFCs 5890-5894). Although I'm not very deep into all the changes, I know that at least the nameprep has changed. For example, the German sharp S ('?') isn't replaced by 'ss' any longer.

The attached file shows the difference between the expected translation and the actual translation.

----------
components: Library (Lib)
files: idna_translate.py
messages: 183104
nosy: marten
priority: normal
severity: normal
status: open
title: IDNA2008 encoding missing
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file29256/idna_translate.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 02:39:22 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 01:39:22 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1361929162.79.0.562394102225.issue12144@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Wed Feb 27 02:56:14 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 01:56:14 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
	'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1361930174.41.0.625639712705.issue12144@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I was able to repro this with Terry's steps on latest hg update. I've taken Scott's patch and updated it to diff from source root (his was pointing to /usr/lib) against the latest. The patch fixes the issue and I also can't see any negative knock-ons that may be caused by applying it.

----------
Added file: http://bugs.python.org/file29257/cookiejar_12144.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Wed Feb 27 03:26:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Feb 2013 02:26:01 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1361931961.69.0.347061576963.issue17305@psf.upfronthosting.co.za>


R. David Murray added the comment:

How are they handling interoperability?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 03:29:09 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Feb 2013 02:29:09 +0000
Subject: [issue17306] Improve the way abstract base classes are shown in help()
Message-ID: <1361932149.15.0.421194254516.issue17306@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Start by adding docstrings to the colletions ABCs.
Look at improving help() to clearly show the required abstract methods.

----------
assignee: rhettinger
components: Documentation
messages: 183107
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Improve the way abstract base classes are shown in help()
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17306>
_______________________________________

From report at bugs.python.org  Wed Feb 27 04:49:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 03:49:21 +0000
Subject: [issue10799] Improve webbrowser (.open) doc and behavior
In-Reply-To: <1293767251.94.0.704365544958.issue10799@psf.upfronthosting.co.za>
Message-ID: <1361936961.72.0.345637201366.issue10799@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

On WinXP, if I try "firefox bugs.python.org", I get an error because it can not find firefox in the PATH.  This is probably what happens with _isexecutable("firefox").
However if I try "C:\Program Files\Mozilla Firefox\>firefox.exe bugs.python.org", Firefox correctly opens the page.

So I think that the problem here is not that the browser fails to open "bugs.python.org" or "google.com", but that the executable of the browser is not found, and whatever is used to open "bugs.python.org" (os.startfile()?) doesn't know that it should be opened with Firefox.

> In the longer run, what I would really like is for webbrowser to be
> better at using the default or finding executables.

I haven't looked at the code, but, if reasonable, it should search in some common folders for the executables of the supported browsers.

Should I create a separate issue for this?  If this solution is not viable, we can always document that the URLs have to start with 'http://' or 'www.'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10799>
_______________________________________

From report at bugs.python.org  Wed Feb 27 04:58:42 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 03:58:42 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1361937522.62.0.972280063826.issue12915@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Can you provide a couple of examples of that notation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Wed Feb 27 05:08:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 04:08:52 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361938132.24.0.162487923955.issue15083@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The next logical step is to make all test classes in test_xml_etree 
> accept the ET module in some way and store it, using it to get classes 
> & function. I.e. no more global "ET" and "pyET" at all.

The idiom suggested by PEP 399 has the two modules (cmod and pymod) as globals, and then simply sets them as class attributes.  Is there any reason why this should be avoided in this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Wed Feb 27 05:40:59 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Feb 2013 04:40:59 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1361938132.24.0.162487923955.issue15083@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda97uq0WUFkPTk=m0t9v_qUoR=dRz2MCdwCY_Ahjnx+ZUg@mail.gmail.com>


Eli Bendersky added the comment:

On Tue, Feb 26, 2013 at 8:08 PM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti added the comment:
>
> > The next logical step is to make all test classes in test_xml_etree
> > accept the ET module in some way and store it, using it to get classes
> > & function. I.e. no more global "ET" and "pyET" at all.
>
> The idiom suggested by PEP 399 has the two modules (cmod and pymod) as
> globals, and then simply sets them as class attributes.  Is there any
> reason why this should be avoided in this case?
>

I'm just not sure how the globals help except for saving 2-3 lines of code.
I do see how they can cause problems because even when I just want to run
the pure Python code, the C module gets imported. Why should it be? I
really don't want it to, I want to isolate things as much as possible
(after all, testing the pure Python module actually tests a scenario where
there is no C module). Pickle is one concrete place that can cause problems
with this.

We talked about related things in Issue #15083 and AFAIR Eric's and Brett's
proposals move these modules away from the global namespace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Wed Feb 27 05:57:33 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Feb 2013 04:57:33 +0000
Subject: [issue17278] SIGSEGV in _heapqmodule.c
In-Reply-To: <1361564739.94.0.652055114597.issue17278@psf.upfronthosting.co.za>
Message-ID: <1361941053.86.0.091058701026.issue17278@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17278>
_______________________________________

From report at bugs.python.org  Wed Feb 27 06:12:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 05:12:30 +0000
Subject: [issue15083] Rewrite ElementTree tests in a cleaner and safer way
In-Reply-To: <1339818759.87.0.747348787779.issue15083@psf.upfronthosting.co.za>
Message-ID: <1361941950.75.0.425590072055.issue15083@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I'm just not sure how the globals help 

It doesn't, but if it works fine there's probably no reason to complicate (if it's complicated at all) things to change this.

> even when I just want to run the pure Python code, the C module gets
> imported. Why should it be?

Doesn't the test always run both? (assuming the C module is available -- if it's not it won't be imported anyway)

> Pickle is one concrete place that can cause problems with this.

This might be an actual reason to avoid globals, but I don't know the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15083>
_______________________________________

From report at bugs.python.org  Wed Feb 27 07:05:18 2013
From: report at bugs.python.org (Kushal Das)
Date: Wed, 27 Feb 2013 06:05:18 +0000
Subject: [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1361945118.27.0.22227046498.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

Attaching patch with the initial documentation of the macros. It also fixes the typo in the title of stable API section.

----------
keywords: +patch
nosy: +kushaldas
Added file: http://bugs.python.org/file29258/issue15465.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15465>
_______________________________________

From report at bugs.python.org  Wed Feb 27 07:15:27 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Feb 2013 06:15:27 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361945727.91.0.521433309828.issue17267@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

LGTM.

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Wed Feb 27 07:36:21 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Feb 2013 06:36:21 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1361946981.4.0.808666200388.issue12915@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> Can you provide a couple of examples of that notation?

entry_points = """
[console_scripts]
pybabel = babel.messages.frontend:main

[distutils.commands]
compile_catalog = babel.messages.frontend:compile_catalog
extract_messages = babel.messages.frontend:extract_messages
init_catalog = babel.messages.frontend:init_catalog
update_catalog = babel.messages.frontend:update_catalog

[distutils.setup_keywords]
message_extractors = babel.messages.frontend:check_message_extractors

[babel.checkers]
num_plurals = babel.messages.checkers:num_plurals
python_format = babel.messages.checkers:python_format

[babel.extractors]
ignore = babel.messages.extract:extract_nothing
python = babel.messages.extract:extract_python
javascript = babel.messages.extract:extract_javascript
"""

Source:

http://babel.edgewall.org/browser/trunk/setup.py#L38

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Wed Feb 27 07:59:00 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 27 Feb 2013 06:59:00 +0000
Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid
	arguments combinations
In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za>
Message-ID: <1361948340.88.0.7190045394.issue17269@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

My bug submission at Apple was closed as a duplicate of radar 13058317.

Given the state of testing of getaddrinfo a testcase will be easier than expected, just pasting the call in this bugreport into the right testcase will match the style of most other checks in that testcase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17269>
_______________________________________

From report at bugs.python.org  Wed Feb 27 08:01:15 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 07:01:15 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
In-Reply-To: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>
Message-ID: <1361948475.5.0.651919163884.issue17251@psf.upfronthosting.co.za>


Demian Brecht added the comment:

That was silly of me. What I /meant/ to say was that, for this specific report, it's functioning as expected. However, the logic in LWPCookieJar isn't entirely correct. As noted in the comments from libwww-perl, the reported URL is in fact, an invalid LWP cookie. What's missing is the logic to deal with other, valid cookies. 

domain_specified = domain.starts_with('.') is incorrect as a four part domain name (a.b.c.d) /is/ a valid LWP domain.

This should likely be patched.

Another question that I have though, is why is LWPCookieJar even part of the stdlib? It's relatively well documented that it is not known to be compatible with any browser. I'm curious as to how heavily used it is and what the rational was to include it (dev might be a better place to ask this, I'm not sure).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Wed Feb 27 08:01:43 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 27 Feb 2013 07:01:43 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361948503.9.0.48069041826.issue17267@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
keywords: +needs review
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:01:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 08:01:23 +0000
Subject: [issue17303] Fix test discovery for test_future*
In-Reply-To: <1361914705.71.0.738486694226.issue17303@psf.upfronthosting.co.za>
Message-ID: <3ZG8VB2v7PzShr@mail.python.org>


Roundup Robot added the comment:

New changeset 83ae10bf608c by Ezio Melotti in branch '3.3':
#17303: test_future* now work with unittest test discovery.  Patch by Zachary Ware.
http://hg.python.org/cpython/rev/83ae10bf608c

New changeset 5599bbc275bc by Ezio Melotti in branch 'default':
#17303: merge with 3.3.
http://hg.python.org/cpython/rev/5599bbc275bc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17303>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:03:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 08:03:53 +0000
Subject: [issue17303] Fix test discovery for test_future*
In-Reply-To: <1361914705.71.0.738486694226.issue17303@psf.upfronthosting.co.za>
Message-ID: <1361952233.88.0.383518010294.issue17303@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!
I also removed a some "from test import support" that were no longer necessary.

test_future files could be reorganized a bit, since they are basically no-ops, and they aren't testing much.

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17303>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:10:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 08:10:02 +0000
Subject: [issue17304] Fix test discovery for test_hash.py
Message-ID: <3ZG8h96R5yzSkb@mail.python.org>


New submission from Roundup Robot:

New changeset 619ed4ed7087 by Ezio Melotti in branch '3.3':
#17304: test_hash now works with unittest test discovery.  Patch by Zachary Ware.
http://hg.python.org/cpython/rev/619ed4ed7087

New changeset bc4458493024 by Ezio Melotti in branch 'default':
#17304: merge with 3.3.
http://hg.python.org/cpython/rev/bc4458493024

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17304>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:10:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 08:10:39 +0000
Subject: [issue17304] Fix test discovery for test_hash.py
In-Reply-To: <3ZG8h96R5yzSkb@mail.python.org>
Message-ID: <1361952639.75.0.546563055997.issue17304@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!
Even here I removed a "from test import support" that was no longer needed.

----------
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17304>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:16:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 08:16:55 +0000
Subject: [issue16935] unittest should understand SkipTest at import time
	during test discovery
In-Reply-To: <1357915388.69.0.583817209092.issue16935@psf.upfronthosting.co.za>
Message-ID: <1361953015.84.0.973441164491.issue16935@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16935>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:27:38 2013
From: report at bugs.python.org (Maximiliano Curia)
Date: Wed, 27 Feb 2013 08:27:38 +0000
Subject: [issue17251] LWPCookieJar load() set domain_specifed wrong
In-Reply-To: <1361342913.69.0.115494364841.issue17251@psf.upfronthosting.co.za>
Message-ID: <1361953658.04.0.661576304457.issue17251@psf.upfronthosting.co.za>


Maximiliano Curia added the comment:

I've deleted my previous patch, as I found the code working as intended.

The domain_specified signals whether the domain stores came from a Domain: tag inside a Set-Cookie request or is taken from the hostname of the request.

The rfc2965 dictates that a value taken from a Domain: tag should be
prepended with a "." if the values doesn't include it. Once stored in a LWPCookieJar the same logic is used to signal if the domain_specified is true or false. Thus the observed behaviour.

The LWP-Cookies-2.0 format is an extension to the perl format, that seeks compatibility adding some features.

About the domain matching, the rfc2965 documents this. I think the perl comment is an example for a.b.c.net, so that matchs with .b.c.net but not with b.c.net.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17251>
_______________________________________

From report at bugs.python.org  Wed Feb 27 09:59:47 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 27 Feb 2013 08:59:47 +0000
Subject: [issue17307] HTTP PUT request Example
Message-ID: <1361955587.38.0.14131170532.issue17307@psf.upfronthosting.co.za>


New submission from Senthil Kumaran:

I think an explicit HTTP put request example in the docs may help. Previously, I thought the POST example was enough as PUT is very similar, but given the folks are looking for it, an example of how to do a PUT request using httplib may be helpful.

Here is patch attached for review.

----------
assignee: orsenthil
files: http_put_example.patch
keywords: patch
messages: 183124
nosy: ezio.melotti, orsenthil, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: HTTP PUT request Example
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29259/http_put_example.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17307>
_______________________________________

From report at bugs.python.org  Wed Feb 27 10:09:47 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 09:09:47 +0000
Subject: [issue17284] create mercurial section in devguide's committing.rst
In-Reply-To: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>
Message-ID: <1361956187.27.0.478027974218.issue17284@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Currently the section covers all the fundamental Mercurial-related operations that a committers needs to know (set up, commit, merge, push), not just committing.

The point of the change in section title is to have a title so non-committers know they can skip over the section.  I'm not wedded to the title I initially suggested.  "Mercurial Guide for Committers" is another possibility.  Mercurial information common to both committers and non-committers can go in a more generally titled section like "Working with Mercurial."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17284>
_______________________________________

From report at bugs.python.org  Wed Feb 27 10:25:14 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 09:25:14 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361957114.87.0.0152851470776.issue16930@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Why must we mention graft at all?  I've never had a need for it.  It seems simpler and just as effective to run `hg import` on the original patch.

I think it's preferable that the steps we recommend to work on all systems.  Then we won't have to worry about documenting quirks, or responding to e-mails or tracker issues saying our recommended steps don't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 10:59:01 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 09:59:01 +0000
Subject: [issue16931] mention work-around to create diffs in default/non-git
	mode
In-Reply-To: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za>
Message-ID: <1361959141.84.0.396502976226.issue16931@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> AFAICT, the recommendation to use hg "git" format is currently only mentioned in the Committing section (http://docs.python.org/devguide/committing.html#minimal-configuration) but not elsewhere, in particular, not http://docs.python.org/devguide/patch.html.

Good observation.  Personally, I think it makes sense to keep Mercurial information for both committers and non-committers (like configuring to use the "git" format) outside of the Mercurial section specific to committers.  This can be in a general Mercurial section before the section specific to committers, or else spread throughout (e.g. in the FAQ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16931>
_______________________________________

From report at bugs.python.org  Wed Feb 27 10:59:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 09:59:15 +0000
Subject: [issue17284] create mercurial section in devguide's committing.rst
In-Reply-To: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>
Message-ID: <1361959155.76.0.0434490196167.issue17284@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> The point of the change in section title is to have a title so 
> non-committers know they can skip over the section.

In the first part of committing.rst there are also things for committers only, and some of the content of the "working with mercurial" might be interesting for non committers too.

We could add a note at the beginning of the page that says that this page is mainly intended for committers, and that contributors can skip it or just skim through it.

I also wonder if we should make the distinction between committers and contributors docs more evident, but in any case there's going to be
some overlapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17284>
_______________________________________

From report at bugs.python.org  Wed Feb 27 11:13:48 2013
From: report at bugs.python.org (Ulrik Sverdrup)
Date: Wed, 27 Feb 2013 10:13:48 +0000
Subject: [issue16113] Add SHA-3 (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1361960028.26.0.95601437564.issue16113@psf.upfronthosting.co.za>


Ulrik Sverdrup added the comment:

Please do not go forward until NIST publishes its SHA-3 specification document. We don't know yet what parameters they will finally choose when making Keccak SHA-3.

----------
nosy: +englabenny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

From report at bugs.python.org  Wed Feb 27 11:31:25 2013
From: report at bugs.python.org (Kushal Das)
Date: Wed, 27 Feb 2013 10:31:25 +0000
Subject: [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1361961085.91.0.245142580013.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

Adding the updated patch with changes as suggested in the review

----------
Added file: http://bugs.python.org/file29260/issue15465v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15465>
_______________________________________

From report at bugs.python.org  Wed Feb 27 11:39:53 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 10:39:53 +0000
Subject: [issue17284] create mercurial section in devguide's committing.rst
In-Reply-To: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>
Message-ID: <1361961593.09.0.881764357269.issue17284@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I think making the sections more focused helps because sections are the linkable units, and sections can be freely moved around once they are more stand-alone (e.g. into or out of the FAQ).

In issue 16931 in response to Ned, I suggested adding a general Mercurial section before the Mercurial section specific to committers.  I can propose a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17284>
_______________________________________

From report at bugs.python.org  Wed Feb 27 11:41:59 2013
From: report at bugs.python.org (jbatista)
Date: Wed, 27 Feb 2013 10:41:59 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361961719.06.0.209731601235.issue17267@psf.upfronthosting.co.za>


jbatista added the comment:

IMHO this should be "safe" when the timezone is UTC for example, where there is no problems with daylight savings. What should be the behavior when adding a certain timedelta() and it crosses a date where there is an hour switch due to daylight savings? The unadvised would get incorrect results.

----------
nosy: +jbatista

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Wed Feb 27 11:46:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 10:46:58 +0000
Subject: [issue17284] create mercurial section in devguide's committing.rst
In-Reply-To: <1361695059.15.0.281280075427.issue17284@psf.upfronthosting.co.za>
Message-ID: <1361962018.13.0.26373274253.issue17284@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The problem with that is that you have to navigate through different links/pages/sections though (see also msg182645).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17284>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:02:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Feb 2013 11:02:18 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1361957114.87.0.0152851470776.issue16930@psf.upfronthosting.co.za>
Message-ID: <578362145.67683000.1361962932481.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> Why must we mention graft at all?  I've never had a need for it.  It
> seems simpler and just as effective to run `hg import` on the
> original patch.

`hg graft` actually works in some cases where `hg import` will fail,
because grafting uses the merge logic (so, for example, it is able to
recognize that some files were renamed between branches).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:03:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Feb 2013 11:03:48 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
In-Reply-To: <1361917159.62.0.523563804235.issue17302@psf.upfronthosting.co.za>
Message-ID: <695075147.67686793.1361963022689.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> agreed on HTTP/1.1, is there a plan to fix it too ;) because the
> current http.server seems to be untouchable without breaking stuff
> all around :)

The way to do it without breaking compatibility would be to write a new
handler, see my platonic proposal at
http://mail.python.org/pipermail/python-dev/2012-September/121806.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:06:02 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 11:06:02 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361963162.91.0.768980511763.issue16930@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Also I often made changes on the patch I imported and applied on 2.7 (e.g. update Misc/NEWS).  Reimporting the patch means that I would have to do it again, and both "hg import --no-c url_of_the patch" and "hg export 2.7 | hg import -" are more complicated than "hg graft 2.7".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:06:59 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 27 Feb 2013 11:06:59 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361450879.34.0.390010426075.issue17267@psf.upfronthosting.co.za>
Message-ID: <1361963219.56.0.43023852676.issue17267@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

datetime.time arithmetic cannot be timezone aware, as there is no associated date and hence you cannot possibly know if there it a DST transition.

I don't think this is a problem. Adding/removing time to a clock value has clear real-world semantics. Using the (naive) real world semantics is the best we can do and should generally give the expected answer.

As to cross-timezone comparisons: 

   time(0, tzinfo=est) - timedelta(hours=1) * 5 == time(0, tzinfo=utc)

fails because the LHS of '==' is a time in a different timezone than the value on the RHS. That's expected and correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:10:23 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Feb 2013 11:10:23 +0000
Subject: [issue17267] datetime.time support for '+' and 'now'
In-Reply-To: <1361961719.06.0.209731601235.issue17267@psf.upfronthosting.co.za>
Message-ID: <20130227111104.GL13784@p29>


Petri Lehtinen added the comment:

A time object isn't associated with any date, so I don't really see a
problem here. The fact that you can shoot yourself in the leg can be
documented, noting that you should use datetime instead.

ISTM the reason why time objects even have an associated timezone is
to support easy calculations between times in different timezones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17267>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:23:36 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 11:23:36 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361964216.19.0.0727023749327.issue16930@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

If you start with a patch against 3.x, which is the normal case, why go to the trouble of grafting from the patch modified for 2.7?  It seems you're just creating more trouble for yourself (introducing more conflicts you have to resolve, etc) when you already have a patch that is known to apply cleanly to 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:30:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 11:30:29 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361964629.57.0.206472960794.issue16930@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Because if the graft succeeds "hg graft 2.7" does everything (including porting extra modifications that I made before committing on 2.7 and the commit on 3.2), if there are conflicts I just spend a few seconds more in kdiff3 to fix them.
Reapplying the patch means that I have to do import + commit at least, and possibly reapply manually changes that I've already done on 2.7.
(I'm assuming that the patch is applied on 2.7 and grafted on 3.2, but the opposite should also be valid.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:51:51 2013
From: report at bugs.python.org (karl)
Date: Wed, 27 Feb 2013 11:51:51 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
In-Reply-To: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>
Message-ID: <1361965911.19.0.79939527722.issue17302@psf.upfronthosting.co.za>


karl added the comment:

Read the thread. Thanks Antoine. Better understanding. I'm still discovering how the community is really working.

Trying to fix a few things in the mean time 

http://bugs.python.org/issue12921
http://bugs.python.org/issue747320
http://bugs.python.org/issue11448
http://bugs.python.org/issue7370 (maybe this one is a duplicate of 747320)

This one 
http://bugs.python.org/issue15799
which is still "open", make me thinks, that it might in the new class to have things for strict production rules, and some parsing rules with a warning mode, if the user cares.

Thanks again for the context Antoine. Maybe we should close this bug as postponed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Wed Feb 27 12:57:14 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 27 Feb 2013 11:57:14 +0000
Subject: [issue17302] HTTP/2.0 - Implementations/Testing efforts
In-Reply-To: <1361912085.4.0.961439299516.issue17302@psf.upfronthosting.co.za>
Message-ID: <1361966234.97.0.0218432648725.issue17302@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17302>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:19:49 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 12:19:49 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361967589.92.0.843524178989.issue16930@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Reapplying the patch means that I have to do import + commit at least, and possibly reapply manually changes that I've already done on 2.7.

Since 2.7 is more different from 3.2 than is 3.4, it seems more likely that grafting from 2.7 to 3.x will result in having to undo 2.7-specific changes and/or add back 3.x-specific changes, and even more so when skipping 3.2.

But this is all secondary to my point that we shouldn't include in our basic instructions things that we know won't work for some people when there is a straightforward alternative (and one that uses no new concepts).  At the very least, we should provide a working alternative alongside.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:23:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Feb 2013 12:23:49 +0000
Subject: [issue17299] Test cPickle with real files
In-Reply-To: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>
Message-ID: <1361967829.68.0.789109195597.issue17299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Serhiy, in Python3 the corresponding test uses io.BytesIO.  That means the additional tests are needed on Python3 as well, just a slightly different set, right?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17299>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:25:21 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Wed, 27 Feb 2013 12:25:21 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1361967921.28.0.159900563513.issue17305@psf.upfronthosting.co.za>


Marten Lehmann added the comment:

At least from the GNU people, two separate projects exists for this matter:

libidn, the original IDNA translation (http://www.gnu.org/software/libidn/)
libidn2, the IDNA2008 translation (http://www.gnu.org/software/libidn/libidn2/manual/libidn2.html)

Btw.: Does Python provide a way to decode the ASCII-representation back to UTF-8?

>>> name.encode('idna')
'xn--mller-kva.com'

>>> name.encode('idna').decode('utf-8')
u'xn--mller-kva.com'

Otherwise I'd look for Python bindings of libidn2 or idnkit-2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:27:33 2013
From: report at bugs.python.org (Andrew Jaffe)
Date: Wed, 27 Feb 2013 12:27:33 +0000
Subject: [issue3588] sysconfig variable LINKFORSHARED has wrong value for
	MacOS X framework build
In-Reply-To: <1219064496.5.0.0710172743091.issue3588@psf.upfronthosting.co.za>
Message-ID: <1361968053.24.0.926243605131.issue3588@psf.upfronthosting.co.za>


Andrew Jaffe added the comment:

Was this actually fixed? As per <http://bugs.python.org/issue16848> it affects "python-config --ldflags" which is used by various build systems.

----------
nosy: +Andrew.Jaffe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3588>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:28:15 2013
From: report at bugs.python.org (Andrew Jaffe)
Date: Wed, 27 Feb 2013 12:28:15 +0000
Subject: [issue16848] Mac OS X: python-config --ldflags and location of
	Python.framework
In-Reply-To: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za>
Message-ID: <1361968095.51.0.467907583908.issue16848@psf.upfronthosting.co.za>


Andrew Jaffe added the comment:

Will this be fixed? I note that the related LINKFORSHARED bug (which causes this, I think) is marked as resolved.

----------
nosy: +Andrew.Jaffe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16848>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:29:21 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Wed, 27 Feb 2013 12:29:21 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1361968161.12.0.549315113809.issue17305@psf.upfronthosting.co.za>


Marten Lehmann added the comment:

For the embedded Python examples, please prepend the following lines:

from __future__ import unicode_literals
name='m?ller.com'

So regarding interoperability: Usually you only use one implementation in your code and hopefully the latest release, but in case someone needs to old one, maybe there should be a separate encodings.idna2008 class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:35:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Feb 2013 12:35:08 +0000
Subject: [issue17307] HTTP PUT request Example
In-Reply-To: <1361955587.38.0.14131170532.issue17307@psf.upfronthosting.co.za>
Message-ID: <1361968508.11.0.139747969245.issue17307@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Shouldn't that be done with urllib?

----------
components: +Documentation
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17307>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:37:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Feb 2013 12:37:23 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1361968643.25.0.00213999000609.issue17305@psf.upfronthosting.co.za>


R. David Murray added the comment:

Does this mean the differences are only in the canonicalization of unicode values?  IDNA is a wire protocol, which means that an application can't know if it is being asked to decode an idna1 or idna2 string unless there's something in the protocol that tells it.  But if the differences are only on the encoding side, and an idna1 decoder will "do the right thing" with the idna2 string, then that would be interoperable.  I'll have to read the standard, but I don't have time right now :)

idna is a codec:

>>> b'xn--mller-kva.com'.decode('idna')
'm?ller.com'

(that's python3, it'll be a unicode string in python2, obviously).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 13:39:09 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 27 Feb 2013 12:39:09 +0000
Subject: [issue16848] Mac OS X: python-config --ldflags and location of
	Python.framework
In-Reply-To: <1357212774.75.0.369526303193.issue16848@psf.upfronthosting.co.za>
Message-ID: <1361968749.15.0.0544335775186.issue16848@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

With framework build from yesterday this is not fixed for python 2.7, it prints:

-L/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config -ldl -framework CoreFoundation -lpython2.7 -u _PyMac_Error Python.framework/Versions/2.7/Python

The bit and the end it unwanted:

   -u _PyMac_Error Python.framework/Versions/2.7/Python

The attached patch fixes the issue (I haven't committed yet because I don't have time to run the test suite right now). The patch works for me and should be fine as it mirrors the solution in the 3.x tree.

BTW. As noted before linking with '-framework Python' is not what you want to do, this causes problems when someone installs multiple framework versions: '-framework Python' then links to whatever framwork was installed last instead of the python version you ran 'python-config' for.

----------
keywords: +patch
Added file: http://bugs.python.org/file29261/issue16848.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16848>
_______________________________________

From report at bugs.python.org  Wed Feb 27 14:54:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Feb 2013 13:54:09 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <1361973249.07.0.389733122556.issue17296@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't have the expertise required to do the 2.7 backport.  My naive attempt is attached, but the message attribute is not preserved (test failure).  If someone can fix the patch, I'll commit it.

----------
keywords: +patch
Added file: http://bugs.python.org/file29262/exception_pickling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Wed Feb 27 15:04:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 14:04:39 +0000
Subject: [issue17296] Cannot unpickle classes derived from 'Exception'
In-Reply-To: <1361811616.55.0.878692548703.issue17296@psf.upfronthosting.co.za>
Message-ID: <3ZGJYL3FBqzQ6L@mail.python.org>


Roundup Robot added the comment:

New changeset 2c9f7ed28384 by R David Murray in branch '3.2':
#17296: backport fix for issue 1692335, naive exception pickling.
http://hg.python.org/cpython/rev/2c9f7ed28384

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17296>
_______________________________________

From report at bugs.python.org  Wed Feb 27 15:04:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 14:04:40 +0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <3ZGJYM2JRKzQ6H@mail.python.org>


Roundup Robot added the comment:

New changeset 2c9f7ed28384 by R David Murray in branch '3.2':
#17296: backport fix for issue 1692335, naive exception pickling.
http://hg.python.org/cpython/rev/2c9f7ed28384

New changeset 67c27421b00b by R David Murray in branch '3.3':
Null merge for issue 1692335 backport.
http://hg.python.org/cpython/rev/67c27421b00b

New changeset 94f107752e83 by R David Murray in branch 'default':
Null merge for issue 1692335 backport.
http://hg.python.org/cpython/rev/94f107752e83

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_______________________________________

From report at bugs.python.org  Wed Feb 27 15:52:04 2013
From: report at bugs.python.org (Harsha)
Date: Wed, 27 Feb 2013 14:52:04 +0000
Subject: [issue17308] Dialog.py crashes when putty Window resized
Message-ID: <1361976724.1.0.943033425333.issue17308@psf.upfronthosting.co.za>


New submission from Harsha:

Dialog.py crashes when putty windows is resized. 

    return simple_menu(d, config, "Select an option:", choices)
  File "/log-root/config-ac", line 499, in simple_menu
    code, tag = d.menu(str(text), height=15, width=45, menu_height=min(8, len(SI
	MPLE_MENU_CHOICES)), choices=SIMPLE_MENU_CHOICES, **kwargs)
  File "/usr/lib/python2.6/site-packages/dialog.py", line 1253, in menu
    (code, output) = self._perform(*(cmd,), **kwargs)
  File "/usr/lib/python2.6/site-packages/dialog.py", line 825, in _perform
    child_rfd)
  File "/usr/lib/python2.6/site-packages/dialog.py", line 762, in _wait_for_prog
  ram_termination  "environment variable)" % exit_code)
dialog.DialogError/usr/lib/python2.6/site-packages/dialog.py:87: DeprecationWarn
ing: BaseException.message has been deprecated as of Python 2.6
  return "<%s: %s>" % (self.__class__.__name__, self.message)
: <DialogError: the dialog-like program exited with code 3 (was passed to it as
the DIALOG_ERROR environment variable)>

----------
components: Windows
messages: 183154
nosy: harshaap
priority: normal
severity: normal
status: open
title: Dialog.py crashes when putty Window resized
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17308>
_______________________________________

From report at bugs.python.org  Wed Feb 27 16:04:58 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 Feb 2013 15:04:58 +0000
Subject: [issue16620] Avoid using private function glob.glob1() in msi module
	and tools
In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za>
Message-ID: <1361977498.97.0.790148532636.issue16620@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +patch
nosy: +berker.peksag
Added file: http://bugs.python.org/file29263/issue16620.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16620>
_______________________________________

From report at bugs.python.org  Wed Feb 27 16:41:26 2013
From: report at bugs.python.org (Paul Koning)
Date: Wed, 27 Feb 2013 15:41:26 +0000
Subject: [issue17309] __bytes__ doesn't work in subclass of int
Message-ID: <1361979686.07.0.236846670702.issue17309@psf.upfronthosting.co.za>


New submission from Paul Koning:

The __bytes__ special method has no effect in a subclass of "int" because the bytes() builtin checks for int or int subclass before it gets around to looking for that special method.  The attached example shows it.

----------
components: Interpreter Core
files: bytes.py
messages: 183155
nosy: pkoning
priority: normal
severity: normal
status: open
title: __bytes__ doesn't work in subclass of int
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file29264/bytes.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17309>
_______________________________________

From report at bugs.python.org  Wed Feb 27 16:51:14 2013
From: report at bugs.python.org (Matt Clarke)
Date: Wed, 27 Feb 2013 15:51:14 +0000
Subject: [issue17310] Ctypes callbacks shows problem on Windows Python (64bit)
Message-ID: <1361980274.18.0.791136497364.issue17310@psf.upfronthosting.co.za>


New submission from Matt Clarke:

I have had an issue arise with ctypes callbacks with 64bit Python on Windows.
Note: everything works fine with 32bit Python on Windows and on 32bit and 64bit Linux.

I have created a simple example to illustrate the issue I have (see attachment), but the real-life issue occurs with using Python to interact with the EPICS control software (http://www.aps.anl.gov/epics/) used at many major scientific institutes.

Basically, if I have a C callback that takes a struct (by value) greater than 8 bytes then the callback returns nonsense. 8 bytes or less works fine.

Stepping through with the Windows debugger, if appears that something goes amiss between the callback being called in C and the closure_fcn(ffi_cif *cif, void *resp, void **args, void *userdata) function in ctypes's callback.c file. Unfortunately, the debugger won't let me step in between those two points.

Looking at the memory I can see the original data in memory at some memory address, X, and a copy of the data at X+40 bytes, but the args in the closure_fcn points at X-40 bytes (which is junk).

Using 32bit Python the data copy is at X-40 bytes and the args pointer in the closure_fcn also points at this.

EPICS has some 64bit C/C++ clients that work fine using callbacks on Windows. Likewise, doing the same sort of thing as ctypes does with EPICS from C# using PInvoke works fine.
 
Any help would be much appreciated.

----------
components: ctypes
files: code.txt
messages: 183156
nosy: Matt.Clarke
priority: normal
severity: normal
status: open
title: Ctypes callbacks shows problem on Windows Python (64bit)
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file29265/code.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17310>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:00:06 2013
From: report at bugs.python.org (Christopher King)
Date: Wed, 27 Feb 2013 16:00:06 +0000
Subject: [issue7423] nested generator expression produces strange results
In-Reply-To: <1259717665.75.0.392103948854.issue7423@psf.upfronthosting.co.za>
Message-ID: <1361980806.11.0.650096685926.issue7423@psf.upfronthosting.co.za>


Christopher King added the comment:

*At this point you need to take your arguments to python-ideas or python-dev (probably the latter),*

I used Python once and will probably never use it again.  I'm not nearly invested enough to evangelize on several mailing lists the validity of a bug that I've already reported.

If you want treat take my bug report as the ramblings of a selfish kook who doesn't know squat about language design or development, then you need take no further action.

However if you'd rather consider that someone with little investment in the language who took the time to form a cogent argument pointing out a surprising and possibly buggy behavior might in fact represent the sentiments of Python user base at large, then you should consider re-opening this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7423>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:18:09 2013
From: report at bugs.python.org (Aman Shah)
Date: Wed, 27 Feb 2013 16:18:09 +0000
Subject: [issue17299] Test cPickle with real files
In-Reply-To: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>
Message-ID: <1361981889.26.0.137544153864.issue17299@psf.upfronthosting.co.za>


Aman Shah added the comment:

Created a small patch for python 2.7 using file test_pickle.py .

----------
nosy: +Aman.Shah
Added file: http://bugs.python.org/file29266/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17299>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:39:54 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Wed, 27 Feb 2013 16:39:54 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1361983194.59.0.417876501808.issue17305@psf.upfronthosting.co.za>


Marten Lehmann added the comment:

IDNA2008 should be backwards compatible. I can try to explain it in a practical example:

DENIC was the first registry that actually used IDNA2008 - at a time, where not even libidn2 officially included the changes required for it. This was mainly due to the point, that the German Latin Small Letter Sharp S ('?') was treated differently to other German Umlauts ('?', '?', '?') in the original IDNA spec: It was not punycoded, because the nameprep already replaced it by 'ss'. Replacing '?' with 'ss' is in general correct in German (e.g. if your keyboard doesn't allow to enter '?'), but then '?' would have to be replaced by 'ae', '?' by 'oe' and '?' by 'ue' as well. 

Punycoding '?', '?', '?', but not '?' was inconsistent and it wouldn't allow to register a domain name like stra?e.de, because it was translated to strasse.de. Therefor DENIC supported IDNA2008 very early to allow the registration of domain names containing '?'.

The only thing I'm aware of in this situation is, that previously stra?e.de was translated to strasse.de, while with IDNA2008 it's being translated to xn--strae-oqa.de. So people that have hardcoded a URL containing '?' and who are expecting it to be translated to 'ss' would fail, because with IDNA2008 it would be translated to a different ASCII-hostname. But those people could just change '?' to 'ss' in their code and everything would work again.

On the contrary, people that have registered a domain name containing '?' in the meantime couldn't access it right now by specifying the IDN version, because it would be translated to the wrong domain name with the current Python IDNA encoding. So the current IDNA-Encoding should be upgraded to IDNA2008.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:48:29 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Wed, 27 Feb 2013 16:48:29 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1361983709.0.0.287778116427.issue16669@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
nosy: +Ankur.Ankan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16669>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:48:35 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Wed, 27 Feb 2013 16:48:35 +0000
Subject: [issue2209] mailbox module doesn't support compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1361983715.94.0.650962576444.issue2209@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
nosy: +Ankur.Ankan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:48:45 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Wed, 27 Feb 2013 16:48:45 +0000
Subject: [issue13477] tarfile module should have a command line
In-Reply-To: <1322190665.85.0.356467902383.issue13477@psf.upfronthosting.co.za>
Message-ID: <1361983725.75.0.066081820449.issue13477@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
nosy: +Ankur.Ankan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13477>
_______________________________________

From report at bugs.python.org  Wed Feb 27 17:52:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Feb 2013 16:52:49 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1361983969.84.0.0381041271044.issue17305@psf.upfronthosting.co.za>


R. David Murray added the comment:

That doesn't sound like interoperability to me, that sounds like backward incompatibility :(.  I hope you are right that it only affects people with hardcoded domain names, but that is still an issue.

In any case, since this is a new feature it can only go into Python3.4, however we decide to do it.

----------
stage:  -> needs patch
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 18:06:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 17:06:32 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
In-Reply-To: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>
Message-ID: <3ZGNbC4vHTzNPy@mail.python.org>


Roundup Robot added the comment:

New changeset e0f3dcd30af8 by Chris Jerdonek in branch 'default':
Issue #17283: Share code between __main__.py and regrtest.py in Lib/test.
http://hg.python.org/cpython/rev/e0f3dcd30af8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Wed Feb 27 18:08:02 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 17:08:02 +0000
Subject: [issue17283] Lib/test/__main__.py should share code with regrtest.py
In-Reply-To: <1361685448.23.0.991458523446.issue17283@psf.upfronthosting.co.za>
Message-ID: <1361984882.64.0.361011451327.issue17283@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks a lot for the review, Petri.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17283>
_______________________________________

From report at bugs.python.org  Wed Feb 27 18:12:04 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 17:12:04 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361985124.43.0.343377786408.issue15305@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The fix for issue 17283 has been committed now, which should make this slightly easier to fix (e.g. change one place instead of two).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 18:21:18 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Feb 2013 17:21:18 +0000
Subject: [issue16406] move the "Uploading Packages" section to
	distutils/packageindex.rst
In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za>
Message-ID: <1361985678.07.0.0840096041249.issue16406@psf.upfronthosting.co.za>


?ric Araujo added the comment:

LGTM.  Some comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16406>
_______________________________________

From report at bugs.python.org  Wed Feb 27 18:24:23 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Feb 2013 17:24:23 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1361985863.59.0.0902969530777.issue17100@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

My only attraction to adding any of the rotate variants is that they provide functionality that can't be done efficiently by a user without access to the underlying data structure.

However, looking only at the API, the methods seem a bit awkward and a bit at odds with how people think of ordered dicts (rotate is not a method that comes to mind for my mental model).   

When I built the OD code, I looked at many existing implementations (in Python and other languages), and I don't recall seeing rotation in any of them.

In the absence of strong use cases, I prefer to keep the API thin so that OD's remain easy to learn and remember.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17100>
_______________________________________

From report at bugs.python.org  Wed Feb 27 18:44:12 2013
From: report at bugs.python.org (Aman Shah)
Date: Wed, 27 Feb 2013 17:44:12 +0000
Subject: [issue17299] Test cPickle with real files
In-Reply-To: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>
Message-ID: <1361987052.37.0.968414970169.issue17299@psf.upfronthosting.co.za>


Aman Shah added the comment:

Fixed the patch by removing TESTFN from tearDown.

----------
Added file: http://bugs.python.org/file29267/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17299>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:05:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 18:05:36 +0000
Subject: [issue16406] move the "Uploading Packages" section to
	distutils/packageindex.rst
In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za>
Message-ID: <3ZGPvN0N0YzNyT@mail.python.org>


Roundup Robot added the comment:

New changeset a9565750930e by Chris Jerdonek in branch '2.7':
Issue #16406: combine the doc pages for uploading and registering to PyPI.
http://hg.python.org/cpython/rev/a9565750930e

New changeset f57ddf3c3e5d by Chris Jerdonek in branch '3.2':
Issue #16406: Combine the doc pages for uploading and registering to PyPI.
http://hg.python.org/cpython/rev/f57ddf3c3e5d

New changeset 58a28aa70fec by Chris Jerdonek in branch '3.3':
Issue #16406: Combine the doc pages for uploading and registering to PyPI.
http://hg.python.org/cpython/rev/58a28aa70fec

New changeset 44ebac378e51 by Chris Jerdonek in branch 'default':
Issue #16406: Combine the doc pages for uploading and registering to PyPI.
http://hg.python.org/cpython/rev/44ebac378e51

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16406>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:07:37 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 18:07:37 +0000
Subject: [issue16406] move the "Uploading Packages" section to
	distutils/packageindex.rst
In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za>
Message-ID: <1361988457.51.0.321342099309.issue16406@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks a lot for taking the time to review, guys.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16406>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:16:17 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 18:16:17 +0000
Subject: [issue17311] use distutils terminology in "PyPI package display"
	section
Message-ID: <1361988977.92.0.980923457558.issue17311@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

As suggested by ?ric in a Rietveld comment to issue 16406, this issue is to make the "PyPI package display" section of the distutils docs use the right terminology:

"It?s too bad this part of the documentation use ?package? with the meaning used on PyPI instead of following the naming conventions used in the rest of the distutils docs (see glossary).  Here I don?t know when ?package? and ?home page? mean pypi.python.org/project or pypi.python.org/project/release (the former being a shortcut to the latest release page)."

----------
assignee: eric.araujo
components: Distutils, Documentation
keywords: easy
messages: 183169
nosy: chris.jerdonek, eric.araujo, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: use distutils terminology in "PyPI package display" section
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17311>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:17:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 18:17:08 +0000
Subject: [issue16406] move the "Uploading Packages" section to
	distutils/packageindex.rst
In-Reply-To: <1352055793.2.0.149261948913.issue16406@psf.upfronthosting.co.za>
Message-ID: <1361989028.17.0.760889736665.issue16406@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I created issue 17311 for a suggestion ?ric made on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16406>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:36:37 2013
From: report at bugs.python.org (moijes12)
Date: Wed, 27 Feb 2013 18:36:37 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1361990197.48.0.344451820757.issue12768@psf.upfronthosting.co.za>


Changes by moijes12 <moijes12 at gmail.com>:


Added file: http://bugs.python.org/file29268/12768_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:40:05 2013
From: report at bugs.python.org (moijes12)
Date: Wed, 27 Feb 2013 18:40:05 +0000
Subject: [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1361990405.2.0.875241088229.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

I've attached a new patch with some changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:54:26 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 18:54:26 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361991266.91.0.888340980044.issue15305@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Here is a patch that updates Geoff's patch to the latest code, and addresses the directory creation issue.

----------
Added file: http://bugs.python.org/file29269/issue15305-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 19:56:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Feb 2013 18:56:16 +0000
Subject: [issue17100] rotating an ordereddict
In-Reply-To: <1359736323.45.0.953309245292.issue17100@psf.upfronthosting.co.za>
Message-ID: <1361991376.46.0.991468386473.issue17100@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> In the absence of strong use cases, I prefer to keep the API thin
> so that OD's remain easy to learn and remember.

It could be a separate function or a dedicated subclass if you prefer.
But providing it in the stdlib would avoid 3rd party code having to poke inside the OD internals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17100>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:14:07 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:14:07 +0000
Subject: [issue15305] Test harness unnecessarily disambiguating twice
In-Reply-To: <1341834351.63.0.548541942582.issue15305@psf.upfronthosting.co.za>
Message-ID: <1361992446.99.0.0418929086328.issue15305@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15305>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:34:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Feb 2013 19:34:05 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1361993645.44.0.387002245963.issue16930@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As a member of the devguide target audience, I think for this the devguide should give alternatives with brief pluses and minuses. After importing and applying a patch to the earliest applicable 2.x or 3.x, move it to the other series with graft (new, possible better merge,possible problem with case or series specific changes); re-import (possible loss of local edits); or even export/import (keep local changes, no case problems). Expanded, the previous sentence should only be 10 or at most 15 lines. Then each person can pick the method that works best for them, which might not always be the same method for each patch. In a few years, this topic will be obsolete except for security issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:39:55 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:39:55 +0000
Subject: [issue17312] test_aifc doesn't clean up after itself
Message-ID: <1361993994.98.0.627362156743.issue17312@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

test_aifc's AIFCLowLevelTest.test_write_aiff_by_extension() leaves a test file behind.  I'm not sure what other versions are affected.

----------
keywords: easy
messages: 183175
nosy: chris.jerdonek, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: test_aifc doesn't clean up after itself
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17312>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:40:34 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:40:34 +0000
Subject: [issue17312] test_aifc doesn't clean up after itself
In-Reply-To: <1361993994.98.0.627362156743.issue17312@psf.upfronthosting.co.za>
Message-ID: <1361994034.19.0.289239843387.issue17312@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
components: +Tests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17312>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:48:48 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:48:48 +0000
Subject: [issue17313] test_logging doesn't clean up after itself
Message-ID: <1361994528.33.0.380746946032.issue17313@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

test_logging leaves behind a file called test.log in the current working directory.  I haven't narrowed down to the specific test, and I'm not sure what other versions are affected.

----------
components: Tests
messages: 183176
nosy: chris.jerdonek, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging doesn't clean up after itself
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17313>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:56:35 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 19:56:35 +0000
Subject: [issue17314] Stop using imp.find_module() in multiprocessing
Message-ID: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za>


New submission from Brett Cannon:

I'm trying to remove all uses of imp.find_module()/load_module() and multiprocessing seems to have a single use of both purely for (re)loading a module. The attached patch moves over to importlib.find_loader() and subsequent load_module() call to match the semantics of imp.find_module()/load_module(). If a guaranteed reload is not necessary then importlib.import_module() is a single-line change.

I ran the test suite, but there don't seem to be any explicit tests for this chunk of code (or am I missing something?).

----------
assignee: sbt
components: Library (Lib)
files: remove_imp.find_module.diff
keywords: patch
messages: 183177
nosy: brett.cannon, sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Stop using imp.find_module() in multiprocessing
versions: Python 3.4
Added file: http://bugs.python.org/file29270/remove_imp.find_module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17314>
_______________________________________

From report at bugs.python.org  Wed Feb 27 20:58:41 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 19:58:41 +0000
Subject: [issue17315] test_posixpath doesn't clean up after itself
Message-ID: <1361995121.83.0.653056148204.issue17315@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

test_posixpath leaves behind a file of the following form when running on Mac OS X:

lrwxr-xr-x @test_17700_tmpa -> @test_17700_tmpa/b

I'm not sure which test it is or which other versions are affected.

----------
components: Tests
messages: 183178
nosy: chris.jerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posixpath doesn't clean up after itself
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17315>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:00:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:00:53 +0000
Subject: [issue17244] py_compile.compile() fails to raise exceptions when
	writing of target file fails
In-Reply-To: <1361306836.21.0.240059339462.issue17244@psf.upfronthosting.co.za>
Message-ID: <1361995253.35.0.644887152076.issue17244@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I figured out what I have to do to make this work properly again to avoid the exception from being swallowed. Roughly:

    # XXX calculate mode (_cache_bytecode)
    # XXX create subdirectories as necessary (set_data)
    # XXX write file (_write_atomic)
    # Above replaces loader._cache_bytecode(file, cfile, bytecode)

That will bypass the try/except block causing the issues.

----------
assignee:  -> brett.cannon
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17244>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:03:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:03:15 +0000
Subject: [issue17177] Document/deprecate imp
In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za>
Message-ID: <1361995395.16.0.120130989828.issue17177@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Deprecate imp.find_module()/load_module()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17177>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:03:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:03:22 +0000
Subject: [issue14797] Deprecate imp.find_module()/load_module()
In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>
Message-ID: <1361995402.66.0.281292873173.issue14797@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Stop using imp.find_module() in multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14797>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:04:26 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:04:26 +0000
Subject: [issue14797] Deprecate imp.find_module()/load_module()
In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>
Message-ID: <1361995466.55.0.569963603219.issue14797@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Assuming issue #17314 gets fixed, that leaves the following uses of imp.find_module():

Lib/idlelib/EditorWindow.py
39:    """Version of imp.find_module() that handles hierarchical module names"""
45:        (file, filename, descr) = imp.find_module(tgt, path)

Lib/modulefinder.py
482:        return imp.find_module(name, path)

Lib/pkgutil.py
229:            file, filename, etc = imp.find_module(subname, path)

Lib/test/test_imp.py
59:            with imp.find_module('module_' + mod, self.test_path)[0] as fd:
64:            imp.find_module('badsyntax_pep3120', path)
68:            fp, filename, info  = imp.find_module('module_' + mod,
77:        fp, filename, info = imp.find_module("tokenize")
91:            file, filename, info = imp.find_module(temp_mod_name)
147:            file, filename, info = imp.find_module(temp_mod_name)
187:                          imp.find_module, "badsyntax_pep3120", [path])
201:            x = imp.find_module("os")
213:        x = imp.find_module(example)
223:        fileobj, pathname, description = imp.find_module(m)

Lib/test/test_import.py
128:                imp.find_module, TESTFN, ["."])

Lib/test/test_importhooks.py
118:            file, filename, stuff = imp.find_module(subname, path)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14797>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:05:34 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:05:34 +0000
Subject: [issue14797] Deprecate imp.find_module()/load_module()
In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>
Message-ID: <1361995534.9.0.776467051749.issue14797@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The remaining uses of imp.load_module() after issue #17314 (which will probably all disappear as uses of imp.find_module() is removed):

Lib/idlelib/EditorWindow.py
48:        module = imp.load_module(tgt, file, filename, descr)

Lib/pkgutil.py
291:            mod = imp.load_module(fullname, self.file, self.filename, self.etc)

Lib/pydoc.py
47:#   - imp.load_module() cannot be prevented from clobbering existing
277:            module = imp.load_module(name, file, path, (ext, 'r', kind))

Lib/test/test_imp.py
155:                mod = imp.load_module(temp_mod_name, file, filename, info)
203:            new_os = imp.load_module("os", *x)
217:        mod = imp.load_module(example, *x)

Lib/test/test_importhooks.py
132:        mod = imp.load_module(fullname, self.file, self.filename, self.stuff)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14797>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:06:27 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 27 Feb 2013 20:06:27 +0000
Subject: [issue16651] Find out what stdlib modules lack a pure Python
	implementation
In-Reply-To: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za>
Message-ID: <1361995587.51.0.901573483128.issue16651@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16651>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:06:35 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:06:35 +0000
Subject: [issue14797] Deprecate imp.find_module()/load_module()
In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za>
Message-ID: <1361995595.9.0.457655582879.issue14797@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14797>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:09:40 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:09:40 +0000
Subject: [issue17316] Add Django 1.5 to benchmarks
Message-ID: <1361995780.43.0.28417987256.issue17316@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Will also need a new Django benchmark target which should get listed in the 2n3 overall target.

----------
assignee: brett.cannon
messages: 183182
nosy: brett.cannon, pitrou
priority: low
severity: normal
status: open
title: Add Django 1.5 to benchmarks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17316>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:11:39 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 27 Feb 2013 20:11:39 +0000
Subject: [issue17317] Benchmark driver should calculate actual benchmark count
	in -h
Message-ID: <1361995899.75.0.774872352722.issue17317@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. when you run ``./perf.py -h`` it lists the py3k benchmark target as having 4 benchmarks, but that's wrong since the 2n3 benchmark alone (which py3k includes) has 23 benchmarks.

----------
keywords: easy
messages: 183183
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Benchmark driver should calculate actual benchmark count in -h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17317>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:12:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Feb 2013 20:12:14 +0000
Subject: [issue17316] Add Django 1.5 to benchmarks
In-Reply-To: <1361995780.43.0.28417987256.issue17316@psf.upfronthosting.co.za>
Message-ID: <1361995934.29.0.00197079929512.issue17316@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17316>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:26:01 2013
From: report at bugs.python.org (Christian Ziemski)
Date: Wed, 27 Feb 2013 20:26:01 +0000
Subject: [issue12713] argparse: allow abbreviation of sub commands by users
In-Reply-To: <1312854957.22.0.437190269629.issue12713@psf.upfronthosting.co.za>
Message-ID: <1361996761.97.0.885242108866.issue12713@psf.upfronthosting.co.za>


Christian Ziemski added the comment:

Ouch, I really missed this one for a long time. :-(
(I didn't understand the workflow correctly and overlooked the reviews.)
I apologize to everyone who has been involved!

Finally I'm back here and re-did my patch for 3.4 this time.

I followed the comments of the reviewers (and Vinay's suggestion) as far as possible.

----------
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file29271/abbrev_subcmds_incl_tests_3.4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12713>
_______________________________________

From report at bugs.python.org  Wed Feb 27 21:59:04 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 20:59:04 +0000
Subject: [issue17311] use distutils terminology in "PyPI package display"
	section
In-Reply-To: <1361988977.92.0.980923457558.issue17311@psf.upfronthosting.co.za>
Message-ID: <1361998744.5.0.0792531483353.issue17311@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The link for convenience:

http://docs.python.org/dev/distutils/packageindex.html#pypi-package-display

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17311>
_______________________________________

From report at bugs.python.org  Wed Feb 27 22:21:12 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Feb 2013 21:21:12 +0000
Subject: [issue17313] test_logging doesn't clean up after itself
In-Reply-To: <1361994528.33.0.380746946032.issue17313@psf.upfronthosting.co.za>
Message-ID: <1362000072.13.0.668716578117.issue17313@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

There are only three logging tests that open a handler to test.log: test_filename, test_filemode and test_incompatible.

AFAIK those tests have remained unchanged over several years, if not months. Is the failure repeatable? Which platform did the failure occur on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17313>
_______________________________________

From report at bugs.python.org  Wed Feb 27 22:31:15 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 27 Feb 2013 21:31:15 +0000
Subject: [issue17313] test_logging doesn't clean up after itself
In-Reply-To: <1361994528.33.0.380746946032.issue17313@psf.upfronthosting.co.za>
Message-ID: <1362000675.91.0.485674106772.issue17313@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I investigated a little further. The file is created in the test directory (build/test_python_XXXX/) and, I assume, the dir is wiped at the end of the test.

I can go through and do an addCleanup(os.remove, 'test.log') in the relevant tests; that should do it. It probably affects all versions - I'm not sure it's worth bothering to change 2.x versions, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17313>
_______________________________________

From report at bugs.python.org  Wed Feb 27 22:48:41 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 27 Feb 2013 21:48:41 +0000
Subject: [issue17079] Fix test discovery for test_ctypes.py
Message-ID: <1362001721.85.0.416982491929.issue17079@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Version 1 converts test_main() into load_tests().  Version 2 removes the now unnecessary import of run_unittest from support; thank you to Ezio for reminding me to look at imports in these patches.

----------
Added file: http://bugs.python.org/file29272/test_ctypes_discovery.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17079>
_______________________________________

From report at bugs.python.org  Wed Feb 27 22:53:42 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 27 Feb 2013 21:53:42 +0000
Subject: [issue17082] Fix test discovery for test_dbm*.py
In-Reply-To: <1359568677.42.0.42152696128.issue17082@psf.upfronthosting.co.za>
Message-ID: <1362002022.88.0.713142247497.issue17082@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Version 2 removes an unnecessary import in test_dbm_gnu.py

----------
Added file: http://bugs.python.org/file29273/test_dbm-s_discovery.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17082>
_______________________________________

From report at bugs.python.org  Wed Feb 27 23:18:20 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 27 Feb 2013 22:18:20 +0000
Subject: [issue17313] test_logging doesn't clean up after itself
In-Reply-To: <1361994528.33.0.380746946032.issue17313@psf.upfronthosting.co.za>
Message-ID: <1362003500.69.0.505762815436.issue17313@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks for investigating.

Yes, currently regrtest.py deletes the containing directory.  But this doesn't happen when running with plain unittest.  If each test cleans up after itself, this will give us more flexibility in moving from regrtest to a unittest-based approach (there is an issue about this).  Currently, test_logging seems to be one of only a few test modules that don't do this.

It's probably okay to make the fix only in 3.4 since we won't be making progress on moving away from regrtest in maintenance releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17313>
_______________________________________

From report at bugs.python.org  Thu Feb 28 00:20:35 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 27 Feb 2013 23:20:35 +0000
Subject: [issue17314] Stop using imp.find_module() in multiprocessing
In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za>
Message-ID: <1362007235.68.0.36863909855.issue17314@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I think this change will potentially make the main module get imported twice under different names when we transfer pickled data between processes.  The current code (which is rather a mess) goes out of its way to avoid that.

Basically the main process makes sys.modules['__mp_main__'] an alias for the main module, and other process import the parent's main module with __name__ == '__mp_main__' and make sys.modules['__main__'] an alias for that.  This means that any functions/classes defined in the main module (from whatever process) will have

    obj.__module__ in {'__main__', '__mp_main__'}

Unpickling such an object will succeed in any process without reimporting the main module.

Attached is an alternative patch which is more like the original code and seems to work.  (Maybe modifying loader.name is an abuse of the API.)

----------
Added file: http://bugs.python.org/file29274/mp-importlib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17314>
_______________________________________

From report at bugs.python.org  Thu Feb 28 00:34:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Feb 2013 23:34:05 +0000
Subject: [issue17313] test_logging doesn't clean up after itself
In-Reply-To: <1361994528.33.0.380746946032.issue17313@psf.upfronthosting.co.za>
Message-ID: <3ZGYBN4NrnzQ07@mail.python.org>


Roundup Robot added the comment:

New changeset b7f5bff33c22 by Vinay Sajip in branch 'default':
Closes #17313: Deleted test file created by test_logging.
http://hg.python.org/cpython/rev/b7f5bff33c22

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17313>
_______________________________________

From report at bugs.python.org  Thu Feb 28 01:50:38 2013
From: report at bugs.python.org (Raynard Sandwick)
Date: Thu, 28 Feb 2013 00:50:38 +0000
Subject: [issue17318] xml.sax and xml.dom fetch DTDs by default
Message-ID: <1362012637.97.0.538376803739.issue17318@psf.upfronthosting.co.za>


New submission from Raynard Sandwick:

Note that URIs in the following are only meant as links when in parentheses; otherwise, they are identifiers and mostly will not yield useful results. I have only worked with xml.sax in Python 2.6 and 2.7, so I cannot speak to its current state in later versions.

The condition described in Python issue #2124 (http://bugs.python.org/issue2124) may yet be a defect, and is at the least a reasonably important enhancement, but apparently was not sufficiently specified, so I will attempt to clarify. As an aside, it is similar to a libxml2 issue on which I have also commented today (https://bugzilla.gnome.org/show_bug.cgi?id=162776), whose statement of issue actually contains what I would expect to be correct behavior if the toggling action were setting an option/feature rather than importing an additional module.

The most common case, and the reason w3c has been inundated with the described requests, is that every time any user anywhere uses xml.sax in its default form to parse an XHTML document containing a doctype declaration, a request is sent to www.w3.org for the contents of that DTD from the URI in its system identifier. This is not documented anywhere (which would be the primary reason to call this a defect), and is confusing because it has the effect of using the terms parser and validator (or "validating parser," whichever is the preferred name) interchangeably.

The w3c is largely to blame, since their own definition document for XML (http://www.w3.org/TR/REC-xml/#sec-external-ent) defines the DTD as a "special kind of external entity," and then goes on to say that XML processors *MAY* use any combination of pubid+sysid to find an alternative method of resolving the reference, but otherwise *MUST* use the URI.

However, this is only necessary when *validating* XML. The DTD is a "mostly useless, but required" (http://en.wikipedia.org/wiki/Document_Type_Declaration) entity in HTML5, e.g., but is not required in XML generally. Even when present, the only time a processor should consult the DTD is during validation, not parsing. If the default parser revealed by xml.sax is a validator rather than just a parser, that should be communicated clearly to the user. When we discuss a CSV parser, we expect it to accept lines separated by some character, each with columns separated by commas. We do not expect it to verify that certain values are found in certain columns of the first line unless we specify that it should. In specifying that it should, we have asked for a validator rather than a parser. This issue is related to the XML analogue of that distinction.

The most valid and important complaint in the referenced blog post is: "don't fetch stuff unless you actually need it," which is what xml.sax users may be unwittingly doing if validation is the default behavior. Further, if xml.sax were actually *not* conducting validation by default, there is no reason whatever to retrieve the DTD, since any external entity references can remain unresolved in well-formed XML prior to validation.

Note that the features, http://xml.org/sax/features/external-general-entities, .../external-parameter-entities, and .../validation have no specified defaults (http://www.saxproject.org/apidoc/org/xml/sax/package-summary.html#package_description). Making these enabled by default causes network-required side effects, which I would contend is improper: unless a user asks for network activity, none should occur. An implicit request for network activity, such as validation, should be fully and widely-visibly documented as a legitimate side effect.

The set of primary use cases for the xml.sax parsers certainly include validation, but users will often be unaware that it is the default, and more importantly be unaware that the parser will therefore request the DTD from its URI. While the feature, .../external-general-entities, partially solves the problem, it is not a full solution, because a well-formed XML document can contain external entities regardless of the location of DTD subsets. The w3c's description ("special kind of external entity") is important here - the DTD is special for a reason, and has its own tag/specifier as a result: resolving general external entities after intentionally omitting an external DTD subset is an acceptable use case, especially in a non-validating parser.

My proposal would be to enhance/fix xml.sax by doing the following:

1) allow toggling of external DTD subset loading via a feature such as http://apache.org/xml/features/nonvalidating/load-external-dtd (http://xerces.apache.org/xerces-j/features.html),
2) cause the feature, http://xml.org/sax/features/validation, to automatically enable the DTD loading feature as well, just as it does for the two currently implemented external entity features,
3) document the default behavior, specially noting that users can expect URIs to be resolved, across the network/internet if necessary, after either the DTD feature or the validation feature is toggled to the enabled state,

and in my opinion:

4) disable the DTD feature by default, so the xml.sax-uninitiated developer who arrives upon the module as a solution doesn't start testing/using it without realizing these requests will be sent.

Sufficient documentation could override #4, since there is a backward-compatibility issue, but I think the detriment to the w3c is enough reason to rethink it nevertheless. Catalogs are a nice solution as well when validation is needed, but when it is not needed, there is no reason to require the extra work of building a catalog (that can't be guaranteed to be writable in situ without sysadmin access) when it is essentially purposeless.

I am continuing to search for the entry point for "<!" (and would appreciate any pointers) but have resorted to subclassing ExpatParser (which, again, kills the nice abstraction xml.sax touts) and omitting external entites with public identifiers starting with "-//W3C//DTD " - this is not a general solution, as DTDs are not guaranteed to come from w3c, and a correct solution would apply the appropriate omissions to the full "<!DOCTYPE ...>" entity, either by leaving external subsets as unparsed and orphaned entities in the document, or (only as a secondary potential solution since internal subsets could still be present and would thus become broken) by ignoring it completely. It might not even be reasonable to consider the latter, though when parsing only and not validating it would be a correctly-working result, so if the former is unachievable, the latter would be a decent improvement for that situation.

As a final note, in case it's helpful: my approach to a fix has been to examine ways to treat the DOCTYPE declaration itself, but another approach would be to have EntityResolver.resolveEntity receive a declaration type alongside the public and system identifiers, and thus the DOCTYPE declaration type could receive appropriate treatment within the current framework quite easily.

----------
components: XML
messages: 183193
nosy: rsandwick3
priority: normal
severity: normal
status: open
title: xml.sax and xml.dom fetch DTDs by default
type: resource usage
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17318>
_______________________________________

From report at bugs.python.org  Thu Feb 28 02:03:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Feb 2013 01:03:54 +0000
Subject: [issue17314] Stop using imp.find_module() in multiprocessing
In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za>
Message-ID: <1362013434.84.0.815940132297.issue17314@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It is an abuse since I didn't design that part of the API to function that way, but it's cool that it just happens to. =)

I do see your use-case and it is legitimate, although extremely rare and narrow. Let me think about whether I want to add specific support either through your approach, Richard, or if I want to decouple the setting of module attributes so that it is more along the lines of::

  main_module = imp.new_module('__mp_main__')
  loader.set_attributes(main_module)  # BRAND-NEW; maybe private to the stdlib?
  main_module.__name__ = '__mp_main__'
  code_object = loader.get_code(main_name)
  sys.modules['__main__'] = sys.modules['__mp_main__'] = main_module  # OLD
  exec(code_object, main_module.__dict__)

I'm currently leaning towards the latter option since it's an annoying bit to get right and it doesn't hurt anything to expose.

----------
assignee: sbt -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17314>
_______________________________________

From report at bugs.python.org  Thu Feb 28 02:13:58 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 28 Feb 2013 01:13:58 +0000
Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and
	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362014038.56.0.256915175466.issue16901@psf.upfronthosting.co.za>


Demian Brecht added the comment:

(Note: Additional context can be found here: http://bugs.python.org/issue16942, which seems to be a dupe of this report)

I haven't had any feedback to my proposal on python-ideas about the removal of LWPCookieJar and MozillaCookieJar and the introduction of LWPCookieProcessor and MozillaCookieProcessor yet (http://thread.gmane.org/gmane.comp.python.ideas/19673), which could be indicative of this change simply not being acceptable. However, on the outside chance that's not the case, I've submitted a patch covering the proposed implementations. All tests pass. 

The patch addresses some of the oddities around FileCookieJar looking, but not behaving as an abstract class as well as inheriting from a concrete class (CookieJar). The change aligns LWPCookies and MozillaCookies with the HTTPCookies. This should fix the questions around why FileCookieJar can't be used directly. If this change looks reasonable, corresponding documentation changes will be made as well.

Note: This change /does/ break backwards compatibility. I'm not sure what the process is for that, so if this change is eventually applied, pointers as to what should be integrated where would be helpful.

----------
keywords: +patch
Added file: http://bugs.python.org/file29275/cookiejar_16901.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16901>
_______________________________________

From report at bugs.python.org  Thu Feb 28 02:31:48 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Feb 2013 01:31:48 +0000
Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and
	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362015108.8.0.263206572069.issue16901@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I suspect most people don't use or care much about cookies and cookie jar and do not understand the issue of proposal enough to comment. My feeling is that the patch probably breaks more than is necessary to fix the immediate problem and too much for current releases. For one, just the name change seems unnecessary. I need to look at HTTPCookies before I can say more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16901>
_______________________________________

From report at bugs.python.org  Thu Feb 28 02:32:10 2013
From: report at bugs.python.org (Raynard Sandwick)
Date: Thu, 28 Feb 2013 01:32:10 +0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1362015130.45.0.48223784214.issue2124@psf.upfronthosting.co.za>


Raynard Sandwick added the comment:

I have opened issue #17318 to try to specify the problem better. While I do think that catalogs are the correct fix for the validation use case (and thus would like to see something more out-of-the-box in that vein), the real trouble is that users are often unaware that they're sending requests to DTD URIs, so some combination of fixes in default behavior and/or documentation is definitely needed.

The external_ges feature does help, in a way, but is poorly communicated to new users, and moreover does not respect the difference between external DTD subsets and external general entities (there's a reason "DOCTYPE" isn't spelled "ENTITY").

The default behavior is not well documented, and the constraining behavior of DTDs is frequently unnecessary. Either a user should have to explicitly enable validation, or it should be irrevocably obvious to a user that validation is the default behavior, and in both cases it should be blatantly documented that validation may cause network side effects. I think the input has been reasonable all around, and yet I find it rather insane that this issue didn't eventually at least result in a documentation fix, thanks to what looks like push-back for push-back's sake, though I will gladly admit the conclusion that it was underspecified is entirely valid.

Anyway, further info in the new issue...

----------
nosy: +rsandwick3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
_______________________________________

From report at bugs.python.org  Thu Feb 28 04:13:26 2013
From: report at bugs.python.org (Waldir Pimenta)
Date: Thu, 28 Feb 2013 03:13:26 +0000
Subject: [issue12345] Add math.tau
In-Reply-To: <1308193830.26.0.803614362003.issue12345@psf.upfronthosting.co.za>
Message-ID: <1362021206.09.0.667552264094.issue12345@psf.upfronthosting.co.za>


Waldir Pimenta added the comment:

Following-up sbaird's comment, I must point out that those aren't Python-specific results. Filtering them by appending &l=python to the urls yields:
- "TAU = 2 * Math.PI": 6
- "TAU = 2*Math.PI": 2
- "TAU=2*Math.PI": 0
- "TAU = Math.PI * 2": 0
- "TAU = Math.PI*2": 2
- "TAU=Math.PI*2": 1
(total: 11)

- "TAU = 2 * PI": 9
- "TAU = 2*PI": 12
- "TAU=2*PI": 0
- "TAU = PI * 2": 2
- "TAU = PI*2": 0
- "TAU=PI*2": 0
(total: 23)

Then again, the results for all languages are still helpful to estimate the overall adoption of the notation in code, and indeed the global usage of these patterns (in github only) is in the hundreds.

Also, it's worth taking a look at the usage of the twopi constant, which is already defined in several languages (http://en.wikipedia.org/w/index.php?oldid=509096802#Support_in_programming_languages), and has been manually defined in python quite often, proving its usefulness:

- https://github.com/search?l=python&q=twopi&type=Code (~2k results in python, and ~58k overall)
- https://github.com/search?l=python&q=two_pi&type=Code (~200 results in python, ~23k overall)

----------
nosy: +waldir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12345>
_______________________________________

From report at bugs.python.org  Thu Feb 28 05:08:46 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Thu, 28 Feb 2013 04:08:46 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1362024526.93.0.577080407792.issue17305@psf.upfronthosting.co.za>


Marten Lehmann added the comment:

I found an interesting link about this issue:

http://www.unicode.org/faq/idn.html

I also checked a domain name of a client that ends with 'stra?e.de': IE, Firefox and Chrome still use IDNA2003, Opera already does IDNA2008.

In IDNA2008 a lot of characters aren't allowed any longer (like symbols or strike-through letters). But I think this doesn't have any practical relevance, because even while IDNA2003 formally allowed these characters, domain name registries disallowed to register internationalized domain names containing any of these characters.

Most registries restricted the allowed characters very strong, e.g. in the .de zone you cannot use Japanese characters, only those in use within the German language. Some other registries expect you to submit a language property during the domain registration and then only special characters within that language are allowed in the domain name. Also, most registries don't allow to register a domain name that mixes different languages.

So IDNA2008 is the future and hopefully shouldn't break a lot. I don't know of any real life use of the IDNA encoding other than DNS / URLs. I don't know how many existing modules in PyPI working with URLs already make use of the current encodings.idna class but I guess it would cause more work if they all would have to change their code to use name.encode('idna2008') or work with an outdated encoding in the end if unchanged than just silentely switching to IDNA2008 for encodings.idna and add encodings.idna2003 for those who really need the old one for some reason. Reminds me a bit on the range() / xrange() thing. Now the special new xrange() is the default and called just range() again. I guess in some years we'll look back on the IDNA2003/2008 transition the same way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Thu Feb 28 05:11:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Feb 2013 04:11:47 +0000
Subject: [issue17318] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1362012637.97.0.538376803739.issue17318@psf.upfronthosting.co.za>
Message-ID: <1362024707.04.0.395165528409.issue17318@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe this is a subset of issue 17239, and it may be appropriate to close it as a duplicate.  I'll let that up to Chris, though, since he knows what still needs to be specified/worked out.

----------
assignee:  -> christian.heimes
nosy: +christian.heimes, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17318>
_______________________________________

From report at bugs.python.org  Thu Feb 28 05:12:05 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 04:12:05 +0000
Subject: [issue17319] http.server.BaseHTTPRequestHandler send_response_only
	doesn't check the type and value of the code.
Message-ID: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za>


New submission from karl:

def send_response_only(self, code, message=None):
http://hg.python.org/cpython/file/3.3/Lib/http/server.py#l448

There is no type checking on code or if the code is appropriate. Let's take 


==============================================
#!/usr/bin/env python3.3
import http.server


class HTTPHandler(http.server.BaseHTTPRequestHandler):
    "A very simple server"
    def do_GET(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(bytes('Response body\n\n', 'latin1'))

if __name__ == '__main__':
    addr = ('', 9000)
    http.server.HTTPServer(addr, HTTPHandler).serve_forever()
=====================================================

A request is working well.

=========================================
? http GET localhost:9000
HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.3.0
Date: Thu, 28 Feb 2013 04:00:44 GMT
Content-type: text/plain

Response body

=========================================

And the server log is 

127.0.0.1 - - [27/Feb/2013 23:00:44] "GET / HTTP/1.1" 200 -

Then let's try


=========================================
#!/usr/bin/env python3.3
import http.server


class HTTPHandler(http.server.BaseHTTPRequestHandler):
    "A very simple server"
    def do_GET(self):
        self.send_response(999)
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(bytes('Response body\n\n', 'latin1'))

if __name__ == '__main__':
    addr = ('', 9000)
    http.server.HTTPServer(addr, HTTPHandler).serve_forever()
=========================================

The response is

=========================================
? http GET localhost:9000
HTTP/1.0 999 
Server: BaseHTTP/0.6 Python/3.3.0
Date: Thu, 28 Feb 2013 03:55:54 GMT
Content-type: text/plain

Response body

=========================================

and the log server is

127.0.0.1 - - [27/Feb/2013 22:55:12] "GET / HTTP/1.1" 999 -

And finally 

=========================================
#!/usr/bin/env python3.3
import http.server


class HTTPHandler(http.server.BaseHTTPRequestHandler):
    "A very simple server"
    def do_GET(self):
        self.send_response('foobar')
        self.send_header('Content-type', 'text/plain')
        self.end_headers()
        self.wfile.write(bytes('Response body\n\n', 'latin1'))

if __name__ == '__main__':
    addr = ('', 9000)
    http.server.HTTPServer(addr, HTTPHandler).serve_forever()
=========================================

The response is then

=========================================
? http GET localhost:9000
HTTPConnectionPool(host='localhost', port=9000): Max retries exceeded with url: /
=========================================

and the server log is 

127.0.0.1 - - [27/Feb/2013 22:56:39] "GET / HTTP/1.1" foobar -
----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 53917)
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 306, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 332, in process_request
    self.finish_request(request, client_address)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 345, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/socketserver.py", line 666, in __init__
    self.handle()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 400, in handle
    self.handle_one_request()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 388, in handle_one_request
    method()
  File "../25/server.py", line 8, in do_GET
    self.send_response('foobar')
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 444, in send_response
    self.send_response_only(code, message)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/http/server.py", line 459, in send_response_only
    (self.protocol_version, code, message)).encode(
TypeError: %d format: a number is required, not str
----------------------------------------

Both error messages and server logs are not very helpful. 
Shall we fix it? 
What others think?

I guess there should be test cases too?
I'm happy to make unit test cases for it though I might need a bit of guidance as I'm not comfortable with unit test cases mocking connections.

----------
components: Library (Lib)
messages: 183201
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code.
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17319>
_______________________________________

From report at bugs.python.org  Thu Feb 28 05:20:16 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Feb 2013 04:20:16 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1362025216.7.0.518787443263.issue17305@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, excellent, that document looks like exactly what I was looking for.

Now, when someone is going to get around to working on this, I don't know.

(Note that the xrange/range change was made at the Python2/Python3 boundary, where we broke backward compatibility.  I doubt that we are ever going to do that kind of transition again, but we do have ways to phase in changes in the default behavior over time.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Thu Feb 28 05:23:12 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 28 Feb 2013 04:23:12 +0000
Subject: [issue17307] HTTP PUT request Example
In-Reply-To: <1361955587.38.0.14131170532.issue17307@psf.upfronthosting.co.za>
Message-ID: <1362025392.19.0.204330652033.issue17307@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Ezio. yes in 3.3 onwards it should be done in urllib.request. I was having 2.7 docs in my mind, but I ended up writing for latest with the intention to backport. I have updated the patch to include both ways, while backporting to 2.7 and 3.2, plan to include only the httplib ones.

----------
Added file: http://bugs.python.org/file29276/issue17307-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17307>
_______________________________________

From report at bugs.python.org  Thu Feb 28 06:28:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Feb 2013 05:28:15 +0000
Subject: [issue1709112] test_1686475 of test_os & pagefile.sys
Message-ID: <1362029295.78.0.828950928355.issue1709112@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Now the test (see Lib/test/test_os.py:470) has been changed to:

try:
    os.stat(r"c:\pagefile.sys")
except FileNotFoundError:
    pass # file does not exist; cannot run test
except OSError as e:
    self.fail("Could not stat pagefile.sys")

so this should work properly now.

I can't find the code changed by the second patch in Modules/posixmodule.c, so I'm going to close this issue as out of date.

----------
nosy: +ezio.melotti
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1709112>
_______________________________________

From report at bugs.python.org  Thu Feb 28 07:02:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Feb 2013 06:02:57 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1362031377.06.0.167151962981.issue16930@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I think for this the devguide should give alternatives with brief 
> pluses and minuses.

Something like http://docs.python.org/devguide/committing.html#porting-changesets-between-the-two-major-python-versions-2-x-and-3-x ? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Thu Feb 28 07:26:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Feb 2013 06:26:39 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1362032799.61.0.953077207048.issue17279@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/issue17279>
_______________________________________

From report at bugs.python.org  Thu Feb 28 07:45:06 2013
From: report at bugs.python.org (py.user)
Date: Thu, 28 Feb 2013 06:45:06 +0000
Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and
	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362033906.78.0.397491373711.issue16901@psf.upfronthosting.co.za>


py.user added the comment:

Demian Brecht wrote:
>I haven't had any feedback to my proposal on python-ideas about the >removal of LWPCookieJar and MozillaCookieJar and the introduction of >LWPCookieProcessor and MozillaCookieProcessor yet >(http://thread.gmane.org/gmane.comp.python.ideas/19673), which could be >indicative of this change simply not being acceptable.

all python ideas are discussed in python lists (for users and for developers)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16901>
_______________________________________

From report at bugs.python.org  Thu Feb 28 08:06:04 2013
From: report at bugs.python.org (Kushal Das)
Date: Thu, 28 Feb 2013 07:06:04 +0000
Subject: [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1362035164.73.0.74373749476.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

version 3 of the patch where sys.hexversion table is moved and now a link to api and abi versioning given.

----------
Added file: http://bugs.python.org/file29277/issue15465v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15465>
_______________________________________

From report at bugs.python.org  Thu Feb 28 08:24:47 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 28 Feb 2013 07:24:47 +0000
Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and
	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362036287.73.0.0507515416224.issue16901@psf.upfronthosting.co.za>


Demian Brecht added the comment:

@Terry: I don't think that the name change is unnecessary as the patch changes the semantics of the the LWP and Mozilla Cookie classes. In the patch, they no longer /are/ a subclass of a CookieJar, but they take a CookieJar object and implement the FileCookieProcessor interface in order to save/load/revert file-based cookies.

This solves the problem of an abstract base class (or at least, what was /intended/ to be an abstract base class prior to abcs: FileCookieJar) extending a concrete class, which doesn't make sense from an architectural standpoint. It also fixes the problem that people are encountering when attempting to instantiate a FileCookieJar object, it doesn't just patch something that's fundamentally broken. It could be my lack of experience with large scale OSS, but I'd prefer a /correct/ fix (especially to something that few actually care about and is seemingly not in heavy use) over a duct taped "just make it work" solution.

I absolutely agree, however, that this is a rather large change (as far as the cookiejar module goes anyway) and shouldn't be taken lightly. However, the cookiejar module /is/ in need of some love and I think that this takes a step to giving it that.

@py.user: My proposal was made to python-ideas. I just prefer gmane to Google Group for links.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16901>
_______________________________________

From report at bugs.python.org  Thu Feb 28 10:45:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Feb 2013 09:45:20 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1362044720.47.0.885025466642.issue16930@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

16.6 is just what I was suggesting. I had not read that far in the revised version. But I am glad I did to find out about auto-commit. There have been issues where I would not want that. (I will check to see if commit is really 'alwats' or if there is an option to not commit, as with import and merge.)

I think that the worry about people not having graft available is misplaced. New people should be downloading the latest version of hg. Experienced users will know about the alternatives before they read 'hg graft'. Also, it seems easy enough to update hg (I plan to do so again soon), I think the main dev doc should assume that people have a recent enough version and describe what is most favored by experienced devs. (On quasi-religious issues like editors and dev methods, consensus is unreachable.)

As for case conflicts, how about adding a phrase to produce
"On older versions of Mercurial where hg graft is not available, or when graft has problems with case conflicts, you can use:"
(note /version/versions/, so a patch is needed anyway ;-).

Other than that, I think this issue should be closed unless and until there is a actual problem encountered, say by someone like me or with even less experience. Let's move on to another dev guide issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Thu Feb 28 10:57:01 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 28 Feb 2013 09:57:01 +0000
Subject: [issue17316] Add Django 1.5 to benchmarks
In-Reply-To: <1361995780.43.0.28417987256.issue17316@psf.upfronthosting.co.za>
Message-ID: <1362045421.56.0.363501503828.issue17316@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
components: +Benchmarks
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17316>
_______________________________________

From report at bugs.python.org  Thu Feb 28 11:02:26 2013
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 28 Feb 2013 10:02:26 +0000
Subject: [issue17170] string method lookup is too slow
In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za>
Message-ID: <1362045746.46.0.99773017435.issue17170@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17170>
_______________________________________

From report at bugs.python.org  Thu Feb 28 11:19:55 2013
From: report at bugs.python.org (David Lam)
Date: Thu, 28 Feb 2013 10:19:55 +0000
Subject: [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1362046795.22.0.933095701968.issue16954@psf.upfronthosting.co.za>


David Lam added the comment:

here's an updated patch incorporating the feedback from Ezio and Eric:

   - moved docstrings put in some __special__ method names
   - made the description of 'tag' consistent:  'tag' means the elements name (as opposed to 'tag' being a synonym for "element"!)
   - docstring args now *stared* as opposed to 'quoted'


I also gave a shot at copying the existing docstrings into their respective C counterparts.  But it *seems* like you can't do so
that easily for a C extension. Maybe I missed something though: 

>>> from _elementtree import Element as cElement
>>> cElement.__doc__ = 'foobarbaz'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'xml.etree.ElementTree.Element'

I see one example in Modules/_json.c where the docstrings were sorta copied and pasted over, so perhaps it's an ok thing to do.

----------
Added file: http://bugs.python.org/file29278/issue16954-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16954>
_______________________________________

From report at bugs.python.org  Thu Feb 28 12:06:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Feb 2013 11:06:08 +0000
Subject: [issue16465] dict creation performance regression
In-Reply-To: <1352823544.31.0.485629860142.issue16465@psf.upfronthosting.co.za>
Message-ID: <1362049568.14.0.976934882578.issue16465@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The patch gives a measurable speedup (./python is a patched 3.3.0+). IMO we should apply it. It's small and I can see no harm, too.

$ for PY in python2.7 python3.2 python3.3 ./python; do cmd="$PY -R -m timeit -n 10000000 '{};{};{};{};{};{};{};{};{};{}'"; echo $cmd; eval $cmd; done
python2.7 -R -m timeit -n 10000000 '{};{};{};{};{};{};{};{};{};{}'
10000000 loops, best of 3: 0.162 usec per loop
python3.2 -R -m timeit -n 10000000 '{};{};{};{};{};{};{};{};{};{}'
10000000 loops, best of 3: 0.142 usec per loop
python3.3 -R -m timeit -n 10000000 '{};{};{};{};{};{};{};{};{};{}'
10000000 loops, best of 3: 0.669 usec per loop
./python -R -m timeit -n 10000000 '{};{};{};{};{};{};{};{};{};{}'
10000000 loops, best of 3: 0.381 usec per loop

$ for PY in python2.7 python3.2 python3.3 ./python; do cmd="$PY -R -m timeit -n 10000000 'int(\"1\", base=16)'"; echo $cmd; eval $cmd; done
python2.7 -R -m timeit -n 10000000 'int("1", base=16)'
10000000 loops, best of 3: 0.268 usec per loop
python3.2 -R -m timeit -n 10000000 'int("1", base=16)'
10000000 loops, best of 3: 0.302 usec per loop
python3.3 -R -m timeit -n 10000000 'int("1", base=16)'
10000000 loops, best of 3: 0.477 usec per loop
./python -R -m timeit -n 10000000 'int("1", base=16)'
10000000 loops, best of 3: 0.356 usec per loop

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16465>
_______________________________________

From report at bugs.python.org  Thu Feb 28 12:21:01 2013
From: report at bugs.python.org (xiaowei)
Date: Thu, 28 Feb 2013 11:21:01 +0000
Subject: [issue17320] os.path.abspath in window7, return error
Message-ID: <1362050461.97.0.932202728371.issue17320@psf.upfronthosting.co.za>


New submission from xiaowei:

assert os.path.split( os.path.abspath('\xe7\x8e\xb0' ) )[-1] == '\xe7\x8e\xb0'

# it should be true(no error) but py2.7 in window it's false
# and when linux it's ok
# os.path.split( os.path.abspath('\xe7\x8e\xb0' ) )[-1] == '\xe7\x8e'
# i guess it's a real bug , hope some one can resolve it
# i donot try py3.* , i donot know if it exists in 3.*

----------
components: Windows
messages: 183212
nosy: xiaowei.py
priority: normal
severity: normal
status: open
title: os.path.abspath in window7, return error
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17320>
_______________________________________

From report at bugs.python.org  Thu Feb 28 12:25:09 2013
From: report at bugs.python.org (Dan)
Date: Thu, 28 Feb 2013 11:25:09 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1362050709.26.0.631999473098.issue12641@psf.upfronthosting.co.za>


Dan added the comment:

That's bull, Eric. This is not about a corner case in cygwin. This is about mingw, which is the **main free software that builds executables on Windows**. You know, for when you don't want to require your users to install Visual Studio.

Additionally, both you and Matthias imposed artificial conditions that made it unlikely for patches to be created (search for "will insist").

Now, I have to agree that the larger python community (and not an under-resourced team like your good selves) should be involved in distutils (or choose and **support** a different package manager). But I'm not sure where I could file a bug for that (again, blogging may be the best choice).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Feb 28 12:42:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Feb 2013 11:42:57 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1362051777.54.0.352986557213.issue16930@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> (I will check to see if commit is really 'alwats' or if there is an 
> option to not commit, as with import and merge.)

There isn't AFAIK, but two "tricks" I use are:
 1) "hg diff -c tip" to check the diff of what I just grafted;
 2) "hg rollback" to rollback the commit in case something is wrong;

I'll see if/where they should be added.

> New people should be downloading the latest version of hg.

That works on Windows, but on Unix most people just use the version shipped with their distribution.  "hg graft" is not so bleeding-edge anymore though -- I had it for a while using the default "hg".

> As for case conflicts, how about adding a phrase to produce
> "On older versions of Mercurial where hg graft is not available, or 
> when graft has problems with case conflicts, you can use:"

This (or the wording I suggested in msg183024 if it's accurate) would be ok with me.  Terry, have you tried using "hg graft" yet?  Are there conflicts on Windows?  I'm not sure how common these conflicts are -- I've never seen them myself.

> (note /version/versions/, so a patch is needed anyway ;-).

Yep, I spotted that but was waiting for this issue :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Thu Feb 28 13:06:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Feb 2013 12:06:19 +0000
Subject: [issue17063] assert_called_with could be more powerful if it allowed
	placeholders
In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za>
Message-ID: <1362053179.97.0.804921948739.issue17063@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Just got bitten by this again. Context: I have a protocol which is sending JSON datagrams over the wire and I'm checking the sent data. I can't exactly check the JSON-encoded content since dict ordering is undefined. So right now I have to write:

    self.assertEqual(q.transport.send.call_count, 1)
    (dgram, target), _ = q.transport.send.call_args
    self.assertEqual(target, (PEER, PORT))
    self.assertEqual(json.loads(dgram), { ... })

Clumsy, clumsy (note that I am too lazy to add a check for the kwargs).

Would be much better if I could simply write:

    dgram, = q.tranport.assert_called_once_with(mock.ANY, (PEER, PORT))
    self.assertEqual(json.loads(dgram), { ... })

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17063>
_______________________________________

From report at bugs.python.org  Thu Feb 28 13:14:02 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 28 Feb 2013 12:14:02 +0000
Subject: [issue17063] assert_called_with could be more powerful if it allowed
	placeholders
In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za>
Message-ID: <1362053642.66.0.520371338559.issue17063@psf.upfronthosting.co.za>


Michael Foord added the comment:

Note that there is nothing stopping you using the mock.ANY and assert_called_once_with style assert currently. You're making your assert more clumsy than it needs to be.

With my proposal you could write:

    q.tranport.assert_called_once_with(mock.ANY, (PEER, PORT))
    dgram = q.tranport.call_args.args[0]
    self.assertEqual(json.loads(dgram),expected)

You could currently be doing:

    q.tranport.assert_called_once_with(mock.ANY, (PEER, PORT))
    dgram = q.tranport.call_args[0][0]
    self.assertEqual(json.loads(dgram), expected)

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17063>
_______________________________________

From report at bugs.python.org  Thu Feb 28 14:07:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Feb 2013 13:07:48 +0000
Subject: [issue17063] assert_called_with could be more powerful if it allowed
	placeholders
In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za>
Message-ID: <1362056868.67.0.0840797854713.issue17063@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I still have to do some tuple unpacking myself while assert_* already did it first. It can be tedious and error-prone (especially if there are several arguments to get).

If the assert methods returning something bothers you, how about introducing a new method match_call_with(...)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17063>
_______________________________________

From report at bugs.python.org  Thu Feb 28 14:13:38 2013
From: report at bugs.python.org (Michael Foord)
Date: Thu, 28 Feb 2013 13:13:38 +0000
Subject: [issue17063] assert_called_with could be more powerful if it allowed
	placeholders
In-Reply-To: <1359377420.39.0.0447874471019.issue17063@psf.upfronthosting.co.za>
Message-ID: <1362057218.82.0.791337092573.issue17063@psf.upfronthosting.co.za>


Michael Foord added the comment:

Or create a JsonMatcher class that does it for you.


class JsonMatcher(object):
   def __init__(self, expected):
       self.expected = expected

   def __eq__(self, other):
       return json.loads(other) == self.expected

q.tranport.assert_called_once_with(JsonMatcher(expected), (PEER, PORT))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17063>
_______________________________________

From report at bugs.python.org  Thu Feb 28 14:54:36 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Thu, 28 Feb 2013 13:54:36 +0000
Subject: [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1362059676.66.0.131529783153.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

That sounds good, Eli! I'll check the implementations and then adapt the other ElementTree methods as well. Will take until next week, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11367>
_______________________________________

From report at bugs.python.org  Thu Feb 28 17:53:20 2013
From: report at bugs.python.org (Joe Borg)
Date: Thu, 28 Feb 2013 16:53:20 +0000
Subject: [issue17321] Better way to pass objects between imp.find_module() and
	imp.load_module()
Message-ID: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>


New submission from Joe Borg:

If I want to use imp to find some load modules, I have to do it in quite an "unpythonic" way:

>>> name = "os"
>>> file, pathname, description = imp.find_module(name)
>>> imp.load_module(name, file, pathname, description)

Can there not be a better way to pass the tuple (or other object) between find_module() and load_module()?

I'm happy to patch this myself and submit, if it's not already been thought about.

----------
messages: 183220
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Better way to pass objects between imp.find_module() and imp.load_module()
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17321>
_______________________________________

From report at bugs.python.org  Thu Feb 28 17:56:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Feb 2013 16:56:22 +0000
Subject: [issue17321] Better way to pass objects between imp.find_module() and
	imp.load_module()
In-Reply-To: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>
Message-ID: <1362070582.25.0.39664417107.issue17321@psf.upfronthosting.co.za>


R. David Murray added the comment:

Does importlib in Python3 provide what you need?  (New features such as this cannot be added to Python2.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17321>
_______________________________________

From report at bugs.python.org  Thu Feb 28 17:58:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Feb 2013 16:58:53 +0000
Subject: [issue17321] Better way to pass objects between imp.find_module() and
	imp.load_module()
In-Reply-To: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>
Message-ID: <1362070733.47.0.102304213228.issue17321@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

imp e imp.find/load_module() are also deprecated (or will be deprecated soon).

----------
nosy: +brett.cannon, ezio.melotti
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17321>
_______________________________________

From report at bugs.python.org  Thu Feb 28 18:02:05 2013
From: report at bugs.python.org (Joe Borg)
Date: Thu, 28 Feb 2013 17:02:05 +0000
Subject: [issue17321] Better way to pass objects between imp.find_module() and
	imp.load_module()
In-Reply-To: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>
Message-ID: <1362070925.37.0.347292026719.issue17321@psf.upfronthosting.co.za>


Joe Borg added the comment:

Thanks for the swift feedback guys, if this is deprecated (i.e. not being carried to Python 3) then close the bug; I'll look at `importlib` and see if it carries the same problem.

----------
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17321>
_______________________________________

From report at bugs.python.org  Thu Feb 28 18:17:13 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Feb 2013 17:17:13 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1362071833.7.0.443398861886.issue12641@psf.upfronthosting.co.za>


?ric Araujo added the comment:

[Martin]
Thanks for the message.  My previous message actually quoted Dan, not you, so no apology is necessary.


[Dan]
> That's bull, Eric.
Could you rephrase this?  English is not my native language.

> This is not about a corner case in cygwin.
Oops I confused cygwin and mingw, apologies.

> This is about mingw, which is the **main free software that builds
> executables on Windows**. You know, for when you don't want to require
> your users to install Visual Studio.
Let me state that I fully sympathize with people who use Windows and still want to use free software as much as possible, even though some version of Visual Studio is now available at no cost.  Again, the fact is that many core developers don?t use Windows, and the official CPython builds use MSVC, so from this viewpoint, MinGW is a niche platform for CPython.  It does not mean that patches are rejected, just that it?s harder for me to assess them.

> Additionally, both you and Matthias imposed artificial conditions that
> made it unlikely for patches to be created (search for "will insist").
Martin used that in a comment about backward compatibility, which we do take seriously.  Roumen?s patches don?t break backward compat if I read them correctly.

> Now, I have to agree that the larger python community (and not an
> under-resourced team like your good selves) should be involved in
> distutils
Yes, more feedback, bug reports, patches and reviews from the community would help.

> (or choose and **support** a different package manager). But I'm not
> sure where I could file a bug for that
An effort is ongoing to define the successors of distutils.  One problem is that it lacks features (like dependencies), and at the same time it tries to be too much (build, upload, install).  The community (Python core developers, packaging tools developers, users) is working on these things.

> (again, blogging may be the best choice).
If you want to get involved in the packaging discussions, you can join the distutils-sig mailing list.  If you want to push this specific issue forward, testing the patches on your system would help.  If you want to support Python on MinGW in general, you can contribute a buildbot to our continuous integration system, so that we can see when things break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Feb 28 18:58:14 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Feb 2013 17:58:14 +0000
Subject: [issue17321] Better way to pass objects between imp.find_module() and
	imp.load_module()
In-Reply-To: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>
Message-ID: <1362074294.02.0.246639891398.issue17321@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Both imp.find_module() and load_module() have been documented as deprecated since Python 3.3. I have not added the warning as I have to work through the stdlib first to remove all current uses.

But for what you are after, Joe, just use importlib.import_module() (which is available in Python 2.7 in the stdlib and earlier on PyPI).

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17321>
_______________________________________

From report at bugs.python.org  Thu Feb 28 19:07:28 2013
From: report at bugs.python.org (Joe Borg)
Date: Thu, 28 Feb 2013 18:07:28 +0000
Subject: [issue17321] Better way to pass objects between imp.find_module() and
	imp.load_module()
In-Reply-To: <1362070400.21.0.731470144624.issue17321@psf.upfronthosting.co.za>
Message-ID: <1362074848.92.0.147915743601.issue17321@psf.upfronthosting.co.za>


Joe Borg added the comment:

Hi Brett, I missed the fact that it's deprecated as it's not mentioned in the 2.* docs http://docs.python.org/2/library/imp.html.

I can see it is in the 3.*.

Thanks for the feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17321>
_______________________________________

From report at bugs.python.org  Thu Feb 28 19:18:16 2013
From: report at bugs.python.org (Jon)
Date: Thu, 28 Feb 2013 18:18:16 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1362075496.16.0.576631189842.issue12641@psf.upfronthosting.co.za>


Jon added the comment:

[Eric]
>> This is about mingw, which is the **main free software that builds
>> executables on Windows**. You know, for when you don't want to require
>> your users to install Visual Studio.
> Let me state that I fully sympathize with people who use Windows and
> still want to use free software as much as possible, even though some
> version of Visual Studio is now available at no cost.  Again, the
> fact is that many core developers don?t use Windows, and the official
> CPython builds use MSVC, so from this viewpoint, MinGW is a niche
> platform for CPython.  It does not mean that patches are rejected,
> just that it?s harder for me to assess them.

I'm going to advocate why mingw-based toolchains (mingw.org and mingw-w64) should be considered important platforms for CPython by giving some background info.

An important part of this issue has nothing to do with the politics of "free software" and everything to do with the technical benefits of using mingw-based toolchains on Windows. While you may be aware of the technical benefits, the following are important to me:

1a) MSVC forces you to link against a specific CRT version, and I don't get to decide which CRT version via a build setting. To the best of my knowledge the only way to link against another CRT version is to use another MSVC version. Many times it's important for all parts of a codebase to link against the same CRT version to prevent well-known cross-CRT object usage failures. While Mingw toolchains typically link to msvcrt.dll by default, they allow you to specify a CRT version via spec file tweaks.

1b) Often the most practical/stable way to build mixed codebases using CRT functionality is to link everything against msvcrt.dll. Using MSVC, the only way I'm aware of is to use old-and-slow VC6 which is not easily available. Updated and performant mingw toolchains enable one to link against msvcrt.dll and other CRT versions via spec file hackery.

2) While VC++ is a good IDE, many of us would like to simply use the command line compiler tools and not clutter our environment with a huge IDE we never use. MSFT has a poor record on this front, and after many fine years of making the command line tools available as part of the Windows SDK, they've regressed back to their lame ways in Windows 8 by removing the cmd line compiler tools from the SDK and embedding into the IDE similar to the old VC6 days. Enticing as it may be, I'll stop here rather than lurch into sailor-speak rage rant.

There are other benefits, but (1a) and (1b) are very important for many real-world usage scenarios on Windows. For example, easily building mercurial with mingw on Windows that work with the official MSVC-built Python. Extend this to other widely used Python and non-Python libraries. Extend this to those building binary libraries on Linux/OSX via mingw for their Windows users.

Also, there are other build automation awesomeness things you can do with mingw toolchains. For example, wouldn't it be great if you could download your source software, a complete mingw toolchain, and build the software on Windows in a sandbox using the mingw toolchain? You can with mingw and mingw-w64 toolchains. Nothing to pre-install and highly automated with minimal user intervention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Thu Feb 28 20:10:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 28 Feb 2013 19:10:51 +0000
Subject: [issue16930] mention limitations and/or alternatives to hg graft
In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za>
Message-ID: <1362078651.21.0.123036984902.issue16930@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The first and/or main place that recommends "hg graft" should link to the section with more detail for cases where users experience problems with graft.  I also agree that the section should mention the case-folding error.  I'm using a pretty new version of hg (version 2.2.1+20120504) and get the error.  (Mercurial's web site is down right now so I can't tell if it's the newest released version still.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16930>
_______________________________________

From report at bugs.python.org  Thu Feb 28 20:40:57 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 28 Feb 2013 19:40:57 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1362080457.63.0.957116570105.issue10967@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Extending regrtest to support unittest test discovery directly is also a worthwhile specific proposal.

Updating the tests to support discovery in all cases is discussed in (meta) issue 16748.  There are also many individual issues in the tracker (one per test module).

----------
dependencies: +Make CPython test package discoverable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Thu Feb 28 21:20:12 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 20:20:12 +0000
Subject: [issue17307] HTTP PUT request Example
In-Reply-To: <1361955587.38.0.14131170532.issue17307@psf.upfronthosting.co.za>
Message-ID: <1362082812.2.0.406215551508.issue17307@psf.upfronthosting.co.za>


karl added the comment:

Sentil:

About the PUT/POST, I would say:

    A POST and PUT methods differs only by the 
    intent of the enclosed representation. In the 
    case of a POST, the target resource (URI) on 
    the server decides what is the meaning of the 
    enclosed representation in the POST request.
    In a PUT request, the enclosed representation 
    is meant to replace the state of the target 
    resource (URI) on the server.
    It is why PUT is idempotent.

About the code:

* http.client
I would remove the following comment, because the term "file" is confusing in HTTP terms.

   # This will create a resource file with contents of BODY

or I would say more exactly


   # This creates an HTTP message 
   # with the content of BODY as the enclosed representation 
   # for the resource http://localhost:8080/foobar

   >>> import http.client
   >>> BODY = "Some data"
   >>> conn = http.client.HTTPConnection("localhost", 8080)
   >>> conn.request("PUT", "/foobar", BODY) # The actual PUT Request
   >>> response = conn.getresponse()
   >>> print(resp.status, response.reason)

Maybe it would be good to display the message which is sent so people can understand what goes on the wire.

* urllib
the client code for urllib doesn't create challenge, I would had a content-type but no hard feeling about it. On the other hand the server code makes me a bit uncomfortable. It sets people into believing that this is the way you should reply to a PUT which is not really the case.

1. If the resource was not existing and has been successfully created, the server MUST answer 204.
2. if the resource already exists and has been successfully replaced/modified, then the server SHOULD answer either 200 or 204 (depending on the design choice)

There are plenty of other cases depending on the constraints.  See for the details http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-4.3.4

If we keep the server code, I would be willing to have a note saying that it is not usable as-is in production code. 

Does that make sense? :)

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17307>
_______________________________________

From report at bugs.python.org  Thu Feb 28 21:38:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Feb 2013 20:38:01 +0000
Subject: [issue17279] Document which named built-in classes can be subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1362083881.66.0.406211986129.issue17279@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From the current python-ideas 'range' thread:
Me: Would it be correct to say (now) that all 4 are intentional omissions? and not merely oversights?
Nick: Yes, I think so. People will have to be *real* convincing to explain a case where composition isn't a more appropriate solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17279>
_______________________________________

From report at bugs.python.org  Thu Feb 28 21:52:44 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 28 Feb 2013 20:52:44 +0000
Subject: [issue14468] Update cloning guidelines in devguide
In-Reply-To: <1333296467.92.0.464102844472.issue14468@psf.upfronthosting.co.za>
Message-ID: <1362084764.81.0.286385032881.issue14468@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Ezio, did you delete the section on null-merging in your commits?  I don't see it in the devguide anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14468>
_______________________________________

From report at bugs.python.org  Thu Feb 28 22:13:47 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 21:13:47 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1362086027.81.0.0280030178207.issue12455@psf.upfronthosting.co.za>


karl added the comment:

Note that HTTP header fields are case-insensitive.
See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging#section-3.2

   Each HTTP header field consists of a case-insensitive field name
   followed by a colon (":"), optional whitespace, and the field value.

Basically the author of a request can set them to whatever he/she wants. But we should, IMHO, respect the author intent. It might happen that someone will choose a specific combination of casing to deal with broken servers and/or proxies. So a cycle of set/get/send should not modify at all the headers.

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Feb 28 22:27:14 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 21:27:14 +0000
Subject: [issue17322] urllib.request add_header() currently allows trailing
	spaces
Message-ID: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za>


New submission from karl:

For HTTP header field names parsing, see http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.2.4

   No whitespace is allowed between the header field-name and colon. In
   the past, differences in the handling of such whitespace have led to
   security vulnerabilities in request routing and response handling.  A
   server MUST reject any received request message that contains
   whitespace between a header field-name and colon with a response code
   of 400 (Bad Request). A proxy MUST remove any such whitespace from a
   response message before forwarding the message downstream.


In python3.3 currently
 
>>> import urllib.request
>>> req = urllib.request.Request('http://www.example.com/')
>>> req.add_header('FoO ', 'Yeah')
>>> req.header_items()
[('Foo ', 'Yeah'), ('User-agent', 'Python-urllib/3.3'), ('Host', 'www.example.com')]

The space has not been removed. So we should fix that at least. This is a bug. I'm not familiar with the specific security issues mentioned in the spec.  

Note that many things can be done too: :/

>>> req.add_header('FoO \n blah', 'Yeah')
>>> req.add_header('Foo:Bar\nFoo2', 'Yeah')
>>> req.header_items()
[('Foo:bar\nfoo2', 'Yeah'), ('Foo \n blah', 'Yeah'), ('Foo ', 'Yeah'), ('User-agent', 'Python-urllib/3.3'), ('Host', 'www.example.com')]


I will check for making a patch tomorrow.

----------
components: Library (Lib)
messages: 183234
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request add_header() currently allows trailing spaces
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17322>
_______________________________________

From report at bugs.python.org  Thu Feb 28 22:27:54 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 21:27:54 +0000
Subject: [issue17322] urllib.request add_header() currently allows trailing
	spaces (and other weird stuff)
In-Reply-To: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za>
Message-ID: <1362086874.32.0.692826131387.issue17322@psf.upfronthosting.co.za>


Changes by karl <karl+pythonbugs at la-grange.net>:


----------
title: urllib.request add_header() currently allows trailing spaces -> urllib.request add_header() currently allows trailing spaces (and other weird stuff)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17322>
_______________________________________

From report at bugs.python.org  Thu Feb 28 22:32:57 2013
From: report at bugs.python.org (py.user)
Date: Thu, 28 Feb 2013 21:32:57 +0000
Subject: [issue16901] In http.cookiejar.FileCookieJar() the .load() and
	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362087177.17.0.115598447311.issue16901@psf.upfronthosting.co.za>


py.user added the comment:

Demian Brecht:
>My proposal was made to python-ideas.

try this
http://mail.python.org/mailman/listinfo/python-dev

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16901>
_______________________________________

From report at bugs.python.org  Thu Feb 28 22:46:38 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 21:46:38 +0000
Subject: [issue17322] urllib.request add_header() currently allows trailing
	spaces (and other weird stuff)
In-Reply-To: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za>
Message-ID: <1362087998.07.0.469723198147.issue17322@psf.upfronthosting.co.za>


karl added the comment:

Yet another one leading spaces :(

>>> req = urllib.request.Request('http://www.example.com/')
>>> req.header_items()
[]
>>> req.add_header(' Foo3', 'Ooops')
>>> req.header_items()
[(' foo3', 'Ooops')]
>>> req.headers
{' foo3': 'Ooops'}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17322>
_______________________________________

From report at bugs.python.org  Thu Feb 28 22:47:58 2013
From: report at bugs.python.org (karl)
Date: Thu, 28 Feb 2013 21:47:58 +0000
Subject: [issue12455] urllib2 forces title() on header names,
	breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1362088078.5.0.594117764665.issue12455@psf.upfronthosting.co.za>


karl added the comment:

So looking at the casing of headers, I discovered other issues. I opened another bug. http://bugs.python.org/issue17322

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Thu Feb 28 23:11:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Feb 2013 22:11:41 +0000
Subject: [issue17299] Test cPickle with real files
In-Reply-To: <1361867979.39.0.619834075084.issue17299@psf.upfronthosting.co.za>
Message-ID: <1362089501.54.0.271954437121.issue17299@psf.upfronthosting.co.za>


R. David Murray added the comment:

Aman: another nit: PEP8 calls for no unneeded parentheses around logical expressions, so things like:

   if(self.f):

should be written:

   if self.f:

in order to adhere to our coding style.

Also, it's not obvious to me that there is any reason to rename the base classes (PicklerTests->AbstractIOPicklerTests, and same for Persistent test).

Finally, rereading Serhiy's note, Python3 only has "general IO streams", both non-IO files and cStringIO.StringIO are gone.  So this really is a 2.7-only issue, and only worth doing because 2.7 is a long term maintenance release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17299>
_______________________________________

From report at bugs.python.org  Thu Feb 28 23:34:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Feb 2013 22:34:24 +0000
Subject: [issue747320] rfc2822 formatdate functionality duplication
Message-ID: <1362090864.52.0.190530908249.issue747320@psf.upfronthosting.co.za>


R. David Murray added the comment:

Could you regenerate your patch using hg diff? (or at least diff -u)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue747320>
_______________________________________