From report at bugs.python.org  Sun Dec  1 00:03:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Nov 2013 23:03:25 +0000
Subject: [issue19845] Compiling Python on Windows docs
In-Reply-To: <1385844842.4.0.324477828597.issue19845@psf.upfronthosting.co.za>
Message-ID: <3dX7Rc3m6Gz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset a239897084bf by Zachary Ware in branch '3.3':
Issue #19845: Updated the Compiling Python on Windows docs.
http://hg.python.org/cpython/rev/a239897084bf

New changeset f4eedd29706b by Zachary Ware in branch 'default':
Issue #19845: Updated the Compiling Python on Windows docs.
http://hg.python.org/cpython/rev/f4eedd29706b

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

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

From report at bugs.python.org  Sun Dec  1 00:05:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 30 Nov 2013 23:05:28 +0000
Subject: [issue19845] Compiling Python on Windows docs
In-Reply-To: <1385844842.4.0.324477828597.issue19845@psf.upfronthosting.co.za>
Message-ID: <1385852728.37.0.732389532996.issue19845@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report; I could have sworn I had submitted a patch for this several months ago, but it seems like I didn't and had completely forgotten about it.

----------
assignee: docs at python -> zach.ware
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Sun Dec  1 00:20:49 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 30 Nov 2013 23:20:49 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385853649.3.0.837827597103.issue18885@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I wouldn't call that "being the most careful".  I've always had an implicit understanding that calls with timeouts may, for whatever reason, return sooner than requested (or later!), and the most careful approach is to re-check the clock again.

----------

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

From report at bugs.python.org  Sun Dec  1 00:29:14 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 30 Nov 2013 23:29:14 +0000
Subject: [issue19726] BaseProtocol is not an ABC
In-Reply-To: <1385163499.31.0.337273163062.issue19726@psf.upfronthosting.co.za>
Message-ID: <1385854154.6.0.991957523325.issue19726@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You're right, I commented previously without reading the context.  The classes defined in protocol.py are not ABCs, they are just base classes (and not mandatory, just convenient, because the transport *will* assume all methods are implemented, and call them without checking or catching NotImplementedError).  I will correct the docstrings.

----------

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

From report at bugs.python.org  Sun Dec  1 00:35:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Nov 2013 23:35:52 +0000
Subject: [issue19726] BaseProtocol is not an ABC
In-Reply-To: <1385163499.31.0.337273163062.issue19726@psf.upfronthosting.co.za>
Message-ID: <3dX8933zMJz7Ljl@mail.python.org>


Roundup Robot added the comment:

New changeset 5469e1a68dbd by Guido van Rossum in branch 'default':
asyncio: Use Interface instead of ABC.  Fixes issue 19726.
http://hg.python.org/cpython/rev/5469e1a68dbd

----------

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

From report at bugs.python.org  Sun Dec  1 00:36:20 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 30 Nov 2013 23:36:20 +0000
Subject: [issue19726] BaseProtocol is not an ABC
In-Reply-To: <1385163499.31.0.337273163062.issue19726@psf.upfronthosting.co.za>
Message-ID: <1385854580.84.0.339408670145.issue19726@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec  1 00:45:12 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 30 Nov 2013 23:45:12 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1385855112.72.0.324463685188.issue19842@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LGTM, although I wish that you had time to implement the comment "TODO: Subclasses can probably optimize this even further" rather than just shuffling the existing code around. :-)

----------

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

From report at bugs.python.org  Sun Dec  1 01:08:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 00:08:35 +0000
Subject: [issue17909] Autodetecting JSON encoding
In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za>
Message-ID: <1385856515.83.0.779537272044.issue17909@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sun Dec  1 01:09:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 00:09:31 +0000
Subject: [issue19839] bz2: regression wrt supporting files with trailing
 garbage after EOF
In-Reply-To: <1385806619.04.0.329117891617.issue19839@psf.upfronthosting.co.za>
Message-ID: <1385856571.41.0.98217958068.issue19839@psf.upfronthosting.co.za>


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


----------
keywords: +3.2regression
priority: normal -> high

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

From report at bugs.python.org  Sun Dec  1 01:21:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 00:21:42 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <3dX99x2v6zz7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 16eba94d3cfe by Alexandre Vassalotti in branch '3.3':
Issue #6477: Added support for pickling the types of built-in singletons.
http://hg.python.org/cpython/rev/16eba94d3cfe

New changeset ff56f48b3277 by Alexandre Vassalotti in branch 'default':
Issue #6477: Merge with 3.3.
http://hg.python.org/cpython/rev/ff56f48b3277

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

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

From report at bugs.python.org  Sun Dec  1 01:21:46 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 01 Dec 2013 00:21:46 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385857306.95.0.0854363681007.issue18885@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I've always had an implicit understanding that calls with timeouts may,
> for whatever reason, return sooner than requested (or later!), and the
> most careful approach is to re-check the clock again.

I've always had the implicit understanding that if I use an *infinite* timeout then the call will not timeout.

----------

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

From report at bugs.python.org  Sun Dec  1 01:24:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 00:24:14 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1385857454.47.0.195690497254.issue19837@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm -1 for a new module doing almost the same thing. Let's add distinct APIs in the existing json module.

----------

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

From report at bugs.python.org  Sun Dec  1 01:31:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 00:31:51 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1385857306.95.0.0854363681007.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385857908.2339.13.camel@fsol>


Antoine Pitrou added the comment:

> > I've always had an implicit understanding that calls with timeouts may,
> > for whatever reason, return sooner than requested (or later!), and the
> > most careful approach is to re-check the clock again.
> 
> I've always had the implicit understanding that if I use an *infinite*
> timeout then the call will not timeout.

Wow, that's a good point. select() and friends are not documented to
exhibit successful spurious wakeups. It would be a pretty strong
compatibility breach if they started doing so.

If we don't want select() to silently retry on EINTR, then I think we
should leave it alone.

Speaking of which, I see that SelectSelector.select() returns an empty
list when interrupted, but this is nowhere documented.

----------

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

From report at bugs.python.org  Sun Dec  1 01:57:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 00:57:21 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <3dX9z43hZDz7LlK@mail.python.org>


Roundup Robot added the comment:

New changeset fbb97f6eb3b3 by Alexandre Vassalotti in branch '2.7':
Issue #6477: Added pickling support for singletons and their types.
http://hg.python.org/cpython/rev/fbb97f6eb3b3

----------

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

From report at bugs.python.org  Sun Dec  1 01:57:49 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 00:57:49 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1385859469.19.0.982230322203.issue6477@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
assignee: docs at python -> alexandre.vassalotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 02:05:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 01:05:37 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1385859937.02.0.170402946012.issue6477@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Uh... Your commits make PyNone_Type and PyNotImplemented_Type public APIs, which I don't think is ok, especially not in bugfix releases.

Also, it would be nice to post patches on the tracker before committing (not for trivial patches of course, but it's generally nicer).

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

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

From report at bugs.python.org  Sun Dec  1 02:10:14 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Dec 2013 01:10:14 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385860214.31.0.766015979328.issue18885@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

> I've always had an implicit understanding that calls with timeouts may, for whatever reason, return sooner than requested (or later!), and the most careful approach is to re-check the clock again.

exactly.  at the system call level you can be interrupted.  re-checking the clock is the right thing to do if the elapsed time actually matters.

> If we don't want select() to silently retry on EINTR, then I think we
should leave it alone.

We should go ahead and retry for the user for select/poll/epoll/kqueue.  If they care about being able to break out of that low level call due to a signal, they should set a signal handler which raises an exception.  I have *never* seen code intentionally get an EINTR exception from a select or poll call and have often seen code tripped up because it or a library it was using forgot to handle it.

We're a high level language: Lets be sane by default and do the most desirable thing for the user. Retry the call internally with a safely adjusted timeout:
  new_timeout = min(original_timeout, time_now-start_time)
  if new_timeout <= 0:
    return an empty list  # ie: the system clock changed
  retry the call with new_timeout

----------

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

From report at bugs.python.org  Sun Dec  1 02:41:27 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 01:41:27 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1385862087.6.0.619980075132.issue6477@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Would you be okay with removing the static declaration of PyNotImplemented_Type and PyNone_Type if we prefix their name with an underscore? There isn't any other way to fix this without making the types linkable.

I might revert the 2.7 change anyway as it broke test_xpickle and it doesn't look easy to fix.

----------

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

From report at bugs.python.org  Sun Dec  1 02:44:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 01:44:25 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <3dXC1M2C3Vz7Lk2@mail.python.org>


Roundup Robot added the comment:

New changeset d964d7023aa4 by Alexandre Vassalotti in branch '2.7':
Issue #6477: Revert fbb97f6eb3b3 as it broke test_xpickle.
http://hg.python.org/cpython/rev/d964d7023aa4

----------

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

From report at bugs.python.org  Sun Dec  1 02:47:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 01:47:20 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1385862440.52.0.544807070876.issue6477@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yeah, adding an underscore is a fine way of dealing with this if the symbol has to be exported.

----------

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

From report at bugs.python.org  Sun Dec  1 02:48:36 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 01 Dec 2013 01:48:36 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385862516.46.0.561748875921.issue18885@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

We went through this whole discussion before.  Returning immediately with three empty lists is better than raising InterruptedError.  Retrying is not always better.

----------

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

From report at bugs.python.org  Sun Dec  1 02:55:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 01:55:02 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1385862902.21.0.262884725829.issue19837@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The problem with adding new APIs with different names to the JSON module is that it breaks symmetry with other wire protocols. The quartet of module level load, loads, dump and dumps functions has become a de facto standard API for wire protocols.

If it wasn't for that API convention, the status quo would be substantially less annoying (and confusing) than it currently is.

The advantage of a separate "jsonb" module is that it becomes easy to say "json is the text transform that dumps and loads from a Unicode string, jsonb is the wire protocol that dumps and loads a UTF encoded byte sequence".

Backporting as simplejsonb would also work in a straightforward fashion (since one PyPI package can include multiple top level Python modules).

The same approach would also extend to fixing the xmlrpc module to handle the encoding step properly (if anyone was so inclined).

----------

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

From report at bugs.python.org  Sun Dec  1 03:04:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 02:04:47 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <3dXCSv1z1mz7Lly@mail.python.org>


Roundup Robot added the comment:

New changeset 9fcba15d7685 by Alexandre Vassalotti in branch '3.3':
Issue #6477: Keep PyNotImplemented_Type and PyNone_Type private.
http://hg.python.org/cpython/rev/9fcba15d7685

New changeset 7d6c27fa7f32 by Alexandre Vassalotti in branch 'default':
Issue #6477: Merge with 3.3.
http://hg.python.org/cpython/rev/7d6c27fa7f32

----------

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

From report at bugs.python.org  Sun Dec  1 03:15:02 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 01 Dec 2013 02:15:02 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385864102.97.0.37491950954.issue18885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Modules/socketmodule.c is using a simple style to implement socket timeouts using select().  If I were to naively copy this style over to pure Python, it would work in current Pythons; I'd get occasionally an OSError(EINTR), which I would have presumably been annoyed with and am now catching properly.  Now if my working code was made to run with a select() modified as proposed, an EINTR would instead cause the program to fail more obscurely: its sockets occasionally -- and apparently without reason -- time out much earlier.  In that situation I would have a hard time finding the reason, particularly if running on an OS where the system select() doesn't spuriously return early with a timeout ("man select" on Linux guarantees this, for example).

Similarly, an existing program might rely on select() with an infinite timeout to only return when one of the descriptors is ready, particularly if called with only one or two descriptors.

Overall, I would far prefer the status quo over a change in the logic from one slightly-subtle situation to another differently slightly-subtle one.  I believe this would end up with programs that need to take special care about both kinds of subtlenesses just to run on two versions of Python.  I may be wrong, in this case sorry to take your time. :-)

----------

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

From report at bugs.python.org  Sun Dec  1 03:16:07 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 02:16:07 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <1385864167.02.0.996635996347.issue19728@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Oops, fumble fingered the issue number in one of the commits. This was the commit for the missing hg add Ned pointed above: http://hg.python.org/cpython/rev/04088790c077

----------

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

From report at bugs.python.org  Sun Dec  1 03:16:18 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 01 Dec 2013 02:16:18 +0000
Subject: [issue19822] PEP process entrypoint
In-Reply-To: <1385647169.27.0.622120668783.issue19822@psf.upfronthosting.co.za>
Message-ID: <1385864178.69.0.892956942938.issue19822@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/issue19822>
_______________________________________

From report at bugs.python.org  Sun Dec  1 03:17:39 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 02:17:39 +0000
Subject: [issue19726] BaseProtocol is not an ABC
In-Reply-To: <1385163499.31.0.337273163062.issue19726@psf.upfronthosting.co.za>
Message-ID: <1385864259.23.0.696864956827.issue19726@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec  1 03:33:29 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 02:33:29 +0000
Subject: [issue19726] BaseProtocol is not an ABC
In-Reply-To: <1385163499.31.0.337273163062.issue19726@psf.upfronthosting.co.za>
Message-ID: <1385865209.23.0.207978557573.issue19726@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 3.4 -Python 3.5

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

From report at bugs.python.org  Sun Dec  1 03:37:27 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 02:37:27 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1385865447.58.0.775898081296.issue6477@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Antoine, are you okay with applying this fix to 2.7? Or should we just mark this as a won't fix?

----------
keywords: +patch
priority: low -> normal
resolution: fixed -> 
stage: committed/rejected -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32915/backport_pickle_singleton_types_fix.diff

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

From report at bugs.python.org  Sun Dec  1 03:47:08 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Dec 2013 02:47:08 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1385864102.97.0.37491950954.issue18885@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNKmVJk9oZJ-wr4G5z0pu7ihJxAg-51_DoNM00D6GLHKcQ@mail.gmail.com>


Gregory P. Smith added the comment:

Guido's point was that it is already a bug in code to not check the elapsed
time after a select call returns rather than assuming the full timeout time
has elapsed. Correct code today already needs to deal with both situations
(OSError(EINTR) and select returning an empty set before the desired time
has elapsed) because both can happen on existing systems today. So correct
code in the future wishing to be compatible with older Pythons will need to
continue to do so.

As for "presumably have been annoyed by the occasional OSError(EINTR) and
fix that bug" that isn't always true. EINTRs are not guaranteed to happen
and are likely to crop up on different systems (production systems) long
after you've deployed and successfully run your code as they are something
that happens due to things _outside_ of the control of your deployed
program: signals.

That's what has gotten me on a kick to hide EINTR from python developers
when at all possible.

For the record: I am perfectly fine with select and friends returning an
empty set early on EINTR (as Guido seems to prefer). If this worries some
people lets at least highlight this in the documentation as part of this
change.

What I don't want is to ever see OSError(EINTR) in the future.

----------

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

From report at bugs.python.org  Sun Dec  1 04:04:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 03:04:12 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <3dXDnR5FRdz7Lk7@mail.python.org>


Roundup Robot added the comment:

New changeset c4cd891cf167 by Gregory P. Smith in branch '3.3':
Fixes Issue #15798 - subprocess.Popen() no longer fails if file
http://hg.python.org/cpython/rev/c4cd891cf167

New changeset 0387054b2038 by Gregory P. Smith in branch 'default':
Fixes Issue #15798 - subprocess.Popen() no longer fails if file
http://hg.python.org/cpython/rev/0387054b2038

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

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

From report at bugs.python.org  Sun Dec  1 04:05:15 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Dec 2013 03:05:15 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <1385867115.86.0.279790552288.issue15798@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec  1 06:00:55 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 05:00:55 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1385874055.49.0.23685612442.issue19775@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file32916/pathlib_samefile.patch

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

From report at bugs.python.org  Sun Dec  1 06:02:26 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 05:02:26 +0000
Subject: [issue13797] Allow objects implemented in pure Python to export PEP
 3118 buffers
In-Reply-To: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za>
Message-ID: <1385874146.38.0.0259732878012.issue13797@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sun Dec  1 06:06:57 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 05:06:57 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>
Message-ID: <1385874417.19.0.69956116947.issue19804@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

I see the same failure of this test on my system (Gentoo Linux, amd64, ifconfig available) on all branches (2.7, 3.3, default).

----------
nosy: +Arfrever
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open
title: test_uuid failing on 32-bit Windows Vista -> test_uuid.TestUUID.test_find_mac() fails
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Dec  1 06:13:44 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 05:13:44 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1385874824.41.0.441881515226.issue11489@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

New tests fail on 2.7 branch, at least with Python configured with --enable-unicode=ucs4 (which is default in Gentoo):

======================================================================
FAIL: test_surrogates (json.tests.test_scanstring.TestCScanstring)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/json/tests/test_scanstring.py", line 107, in test_surrogates
    assertScan(u'"z\\ud834\udd20x12345"', u'z\ud834\udd20x12345')
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/json/tests/test_scanstring.py", line 97, in assertScan
    (expect, len(given)))
AssertionError: Tuples differ: (u'z\ud834\udd20x12345', 16) != (u'z\U0001d120x12345', 16)

First differing element 0:
z\ud834\udd20x12345
z\U0001d120x12345

- (u'z\ud834\udd20x12345', 16)
+ (u'z\U0001d120x12345', 16)

======================================================================
FAIL: test_surrogates (json.tests.test_scanstring.TestPyScanstring)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/json/tests/test_scanstring.py", line 107, in test_surrogates
    assertScan(u'"z\\ud834\udd20x12345"', u'z\ud834\udd20x12345')
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/json/tests/test_scanstring.py", line 97, in assertScan
    (expect, len(given)))
AssertionError: Tuples differ: (u'z\ud834\udd20x12345', 16) != (u'z\U0001d120x12345', 16)

First differing element 0:
z\ud834\udd20x12345
z\U0001d120x12345

- (u'z\ud834\udd20x12345', 16)
+ (u'z\U0001d120x12345', 16)

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

----------
nosy: +Arfrever
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

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

From report at bugs.python.org  Sun Dec  1 06:16:20 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 05:16:20 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1385874980.41.0.48774829897.issue11489@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

... when code is loaded from .pyc files (i.e. when `make test` runs tests the second time).

----------

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

From report at bugs.python.org  Sun Dec  1 06:23:06 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 05:23:06 +0000
Subject: [issue16549] regression: -m json.tool module is broken
In-Reply-To: <1353799140.48.0.264325786565.issue16549@psf.upfronthosting.co.za>
Message-ID: <1385875386.1.0.100978950037.issue16549@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

2 tests fail (only on 2.7 branch) when `make test` runs test suite the second time:

======================================================================
ERROR: test_infile_outfile (json.tests.test_tool.TestTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/json/tests/test_tool.py", line 64, in test_infile_outfile
    rc, out, err = assert_python_ok('-m', 'json.tool', infile, outfile)
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
TypeError: 'NoneType' object is not callable

======================================================================
ERROR: test_infile_stdout (json.tests.test_tool.TestTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/json/tests/test_tool.py", line 57, in test_infile_stdout
    rc, out, err = assert_python_ok('-m', 'json.tool', infile)
  File "/var/tmp/portage/dev-lang/python-2.7.7_pre20131201/work/python-2.7.7_pre20131201/Lib/test/script_helper.py", line 55, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
TypeError: 'NoneType' object is not callable

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

----------
nosy: +Arfrever
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

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

From report at bugs.python.org  Sun Dec  1 06:29:03 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 05:29:03 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1385875743.13.0.00657766264149.issue18716@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

formatter module is used by (Python-3-compatible) Portage (package manager for Gentoo):
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=summary

Maybe deprecation should be reverted.

----------
nosy: +Arfrever
resolution: fixed -> 
stage: committed/rejected -> 
status: closed -> open

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

From report at bugs.python.org  Sun Dec  1 06:36:11 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Dec 2013 05:36:11 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1385876171.82.0.699772233915.issue18716@psf.upfronthosting.co.za>


Larry Hastings added the comment:

They're not on Python 3.  I think we should keep the deprecation and let them roll their own when they upgrade.  It's not like the module provides much functionality in the first place.

----------

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

From report at bugs.python.org  Sun Dec  1 08:51:11 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 07:51:11 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1385884271.95.0.650306741642.issue19775@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

About doc string in patch:
1. s/same/the same/
2. "same" is usually used with "as", not "with":
   https://books.google.com/ngrams/graph?content=same+as%2Csame+with%2Csame+to&year_start=1800&year_end=2000&corpus=15&smoothing=3

----------

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

From report at bugs.python.org  Sun Dec  1 08:59:59 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 07:59:59 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385855112.72.0.324463685188.issue19842@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1NwO9Laax2bxiD2T5GKdnaj=chnkqPk51ke9bUtzQQ+w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
>
> LGTM, although I wish that you had time to implement the comment "TODO: Subclasses can probably optimize this even further" rather than just shuffling the existing code around. :-)

I will look a this, but I rather take care of the API than
implementation details :-)
Also, I'm not sure that modify() is actually a performance-critical
code-path: do you have any semi-realistic asyncio-based benchmark I
could use?

----------

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

From report at bugs.python.org  Sun Dec  1 09:06:41 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 08:06:41 +0000
Subject: [issue19840] The is no way to tell shutil.move to ignore metadata
In-Reply-To: <1385816740.15.0.284400453847.issue19840@psf.upfronthosting.co.za>
Message-ID: <1385885201.24.0.554171825005.issue19840@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/issue19840>
_______________________________________

From report at bugs.python.org  Sun Dec  1 09:13:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 08:13:45 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <3dXMfc6kVMz7Lk2@mail.python.org>


Roundup Robot added the comment:

New changeset efcdf2a70f2a by Gregory P. Smith in branch '3.3':
Undo supposed fix for Issue #15798 until I understand why this is
http://hg.python.org/cpython/rev/efcdf2a70f2a

New changeset ddbf9632795b by Gregory P. Smith in branch 'default':
Undo supposed fix for Issue #15798 until I understand why this is
http://hg.python.org/cpython/rev/ddbf9632795b

----------

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

From report at bugs.python.org  Sun Dec  1 09:14:29 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Dec 2013 08:14:29 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <1385885669.27.0.901265095637.issue15798@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec  1 09:14:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 08:14:58 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <CAGE7PNKmVJk9oZJ-wr4G5z0pu7ihJxAg-51_DoNM00D6GLHKcQ@mail.gmail.com>
Message-ID: <CAH_1eM2ejADUhf9RiUvrKkUWXhNuYSc7FMiGXBWWFUVm-H=w1w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Just for the record, I was initially in favor of recomputing the
timeout and retrying upon EINTR, but Guido prefers to return empty
lists, and since that's a better compromise than the current situation
(I've seen *many* people complaining on EINTR popping-up at random
points in the code, including myself), I went ahead and implemented
it.

AFAICT, an early return for calls such as poll()/epoll() etc is
something which is definitely acceptable: if you have a look at e.g.
Tornado, Twisted & Co, they all return empty lists on EINTR.

> I've always had the implicit understanding that if I use an *infinite* timeout then > the call will not timeout.

Well, I've always assumed that time.sleep(n) would sleep n seconds, but:
"""
static int
floatsleep(double secs)
[...]
    Py_BEGIN_ALLOW_THREADS
    err = select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t);
    Py_END_ALLOW_THREADS
    if (err != 0) {
#ifdef EINTR
        if (errno == EINTR) {
            if (PyErr_CheckSignals())
                return -1;
        }
        else
#endif
        {
            PyErr_SetFromErrno(PyExc_IOError);
            return -1;
        }
    }
[...]
"""

So really, I'm like Gregory: I don't care which solution we chose, but
I just don't want to have to let the user handle EINTR.

----------

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

From report at bugs.python.org  Sun Dec  1 09:16:17 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 08:16:17 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <1385885777.58.0.160053749069.issue15798@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/issue15798>
_______________________________________

From report at bugs.python.org  Sun Dec  1 09:35:54 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 01 Dec 2013 08:35:54 +0000
Subject: [issue19840] The is no way to tell shutil.move to ignore metadata
In-Reply-To: <1385816740.15.0.284400453847.issue19840@psf.upfronthosting.co.za>
Message-ID: <1385886954.02.0.394616456228.issue19840@psf.upfronthosting.co.za>


Changes by Claudiu.Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

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

From report at bugs.python.org  Sun Dec  1 09:48:10 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 01 Dec 2013 08:48:10 +0000
Subject: [issue19840] The is no way to tell shutil.move to ignore metadata
In-Reply-To: <1385816740.15.0.284400453847.issue19840@psf.upfronthosting.co.za>
Message-ID: <1385887690.54.0.436211790368.issue19840@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hi. Here's a patch which adds `copy_function` parameter to `shutil.move`.

----------
keywords: +patch
Added file: http://bugs.python.org/file32917/shutil.patch

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

From report at bugs.python.org  Sun Dec  1 10:05:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 09:05:57 +0000
Subject: [issue19831] tracemalloc: stop the module later at Python shutdown
In-Reply-To: <1385722651.55.0.86737779548.issue19831@psf.upfronthosting.co.za>
Message-ID: <3dXNps07sQz7Lk2@mail.python.org>


Roundup Robot added the comment:

New changeset cc8953ea3c7e by Victor Stinner in branch 'default':
Closes #19831: Stop tracemalloc later at Python shutdown to be able to use
http://hg.python.org/cpython/rev/cc8953ea3c7e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 10:16:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 09:16:30 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1385889390.95.0.486571954531.issue5885@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Instead hexadecimals in _long_from_uuid_t you can use _PyLong_FromByteArray.

However adding new C implemented module has hight cost. I doubt that the speed up of UUID generation is worth this cost.

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

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

From report at bugs.python.org  Sun Dec  1 10:33:02 2013
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Sun, 01 Dec 2013 09:33:02 +0000
Subject: [issue19834] Unpickling exceptions pickled by Python 2
In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za>
Message-ID: <1385890382.08.0.75756553967.issue19834@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

Here's an updated version of the patch, addressing most of Alexandre's comments.

----------
Added file: http://bugs.python.org/file32918/python-2-exception-pickling-2.diff

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

From report at bugs.python.org  Sun Dec  1 10:35:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Dec 2013 09:35:35 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1385890535.78.0.13944806508.issue19842@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I think that's a cleaner design.

For common containers like Sequence or Mapping, ABC are useful. But I don't expect new implementations of BaseSelector. Is it just for purity? :-p

----------
nosy: +haypo

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

From report at bugs.python.org  Sun Dec  1 10:36:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Dec 2013 09:36:45 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1385890605.5.0.527430793841.issue19842@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(I'm not opposed to the change, I'm just asking.)

----------

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

From report at bugs.python.org  Sun Dec  1 10:41:52 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 01 Dec 2013 09:41:52 +0000
Subject: [issue19776] Provide expanduser() on Path objects
In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za>
Message-ID: <1385890912.21.0.765313626285.issue19776@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello. Here's a patch for `expanduser()`.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file32919/pathlib.patch

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

From report at bugs.python.org  Sun Dec  1 10:43:12 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 01 Dec 2013 09:43:12 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1385890992.12.0.810153878305.issue19842@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

In those protocols where client and server exchange a lot of commands and responses in a single session, such as FTP, modify() is going to be called many times.
I don't have actual numbers but I remember that using epoll.modify() was one of those relatively small optimizations which all put together led to current pyftpdlib performances. For poll() and epoll() pollers I see no reason not to use the specialized modify().

That aside, what actually *does* make a big difference and it is very important is to "unregister" a fd for writing (EVENT_WRITE) when there's no more data to send, and that's something that should be done at a higher level (transport.write() and anywhere else some data is sent).

----------

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

From report at bugs.python.org  Sun Dec  1 10:57:54 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 09:57:54 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
Message-ID: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Steps to reproduce the bug:
1. Download cute cat picture from internet. Name it CuteCat.jpg.

>>> import os
>>> os.listdir('.')
['CuteCat.jpg']

2. Create symbolic link.

>>> os.symlink('CuteCat.jpg', 'Aaawww.lnk')
>>> os.listdir('.')
['Aaawww.lnk', 'CuteCat.jpg']

3. Do it again.

>>> os.symlink('CuteCat.jpg', 'Aaawww.lnk')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileExistsError: [Errno 17] File exists: 'CuteCat.jpg'

Amusingly, it only happens on 3.4 (both Windows and Linux). 3.3 gives correct error message (in Linux, I did not test it on Windows). 2.7 omits the file information (in Linux, I did not test it on Windows). I'll check again the behaviour on Windows for 2.7 and 3.3.

Do we need unit test for this? Will we change the error message again in the future? For now, I omit it. Let me know if we need unit test.

----------
components: Extension Modules, Windows
files: fix_error_message_on_creating_already_existed_symbolic_link.patch
keywords: patch
messages: 204899
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Misleading error on creating already existed symlink
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32920/fix_error_message_on_creating_already_existed_symbolic_link.patch

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

From report at bugs.python.org  Sun Dec  1 11:04:25 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 10:04:25 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
In-Reply-To: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>
Message-ID: <1385892265.43.0.316079593461.issue19848@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Python 2.7 on Windows does not have symlink.

Python 3.3 on Windows got the same symptom as Python 3.4. Do we need to fix it?

----------

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

From report at bugs.python.org  Sun Dec  1 11:04:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 10:04:59 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <3dXQ6z2f5Cz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset f48f302f54aa by Charles-Fran?ois Natali in branch 'default':
Issue #19842: Refactor BaseSelector to make it an actual usable ABC.
http://hg.python.org/cpython/rev/f48f302f54aa

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

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

From report at bugs.python.org  Sun Dec  1 11:12:49 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 10:12:49 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385890535.78.0.13944806508.issue19842@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2goqqwCi+qzmp7myVZSYE-fuXamu2r+4ag3NYNpE8sBA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> STINNER Victor added the comment:
>
>> I think that's a cleaner design.
>
> For common containers like Sequence or Mapping, ABC are useful. But I don't expect new implementations of BaseSelector. Is it just for purity? :-p

There are already implementations in the test suite, but the main
reason is for documentation purposes (i.e. to document clearly which
methods are available, and which are optional).
IMO, ABC make documentation more clear, and also make it easier for
third-party implementations.

I don't have a strong opinion on this, my real concern is really just
the documentation, so if you can propose a documentation patch that
makes things clear, I'm perfectly fine with removing BaseSelector from
the API :-)

----------

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

From report at bugs.python.org  Sun Dec  1 11:13:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 10:13:47 +0000
Subject: [issue19506] subprocess.communicate() should use a memoryview
In-Reply-To: <1385809774.64.0.738883993997.issue19506@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0CGm=xVWPoHwQi+H-CC=Tukgna7qKjO_rDDD_R84qFPA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Impressive speedup :-)

----------

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

From report at bugs.python.org  Sun Dec  1 11:36:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 10:36:17 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385862902.21.0.262884725829.issue19837@psf.upfronthosting.co.za>
Message-ID: <1385894175.2297.1.camel@fsol>


Antoine Pitrou added the comment:

> The problem with adding new APIs with different names to the JSON
> module is that it breaks symmetry with other wire protocols. The
> quartet of module level load, loads, dump and dumps functions has
> become a de facto standard API for wire protocols.

Breaking symmetry is terribly less silly than having a second module
doing almost the same thing, though.

> The advantage of a separate "jsonb" module is that it becomes easy to
> say "json is the text transform that dumps and loads from a Unicode
> string, jsonb is the wire protocol that dumps and loads a UTF encoded
> byte sequence".

This is a terribly lousy design.

----------

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

From report at bugs.python.org  Sun Dec  1 11:44:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 10:44:47 +0000
Subject: [issue10803] ctypes: better support of bytearray objects
In-Reply-To: <1293951546.17.0.00856255345379.issue10803@psf.upfronthosting.co.za>
Message-ID: <1385894687.74.0.21368462822.issue10803@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is preliminary patch which makes bytearray support in ctypes better.

----------
keywords: +patch
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.5 -Python 3.2
Added file: http://bugs.python.org/file32921/ctype_bytearray.patch

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

From report at bugs.python.org  Sun Dec  1 11:44:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 10:44:59 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <CAGE7PNKmVJk9oZJ-wr4G5z0pu7ihJxAg-51_DoNM00D6GLHKcQ@mail.gmail.com>
Message-ID: <1385894697.2297.7.camel@fsol>


Antoine Pitrou added the comment:

> Guido's point was that it is already a bug in code to not check the elapsed
> time after a select call returns rather than assuming the full timeout time
> has elapsed.

I don't understand how it's a bug. You're assuming select() has
unreliable timing, but it doesn't (if you are using the same clock).

----------

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

From report at bugs.python.org  Sun Dec  1 11:46:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 10:46:59 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <CAH_1eM2ejADUhf9RiUvrKkUWXhNuYSc7FMiGXBWWFUVm-H=w1w@mail.gmail.com>
Message-ID: <1385894817.2297.8.camel@fsol>


Antoine Pitrou added the comment:

On dim., 2013-12-01 at 08:14 +0000, Charles-Fran?ois Natali wrote:
> So really, I'm like Gregory: I don't care which solution we chose, but
> I just don't want to have to let the user handle EINTR.

Well this is wishing thinking, since by returning an empty list you
force the user to handle EINTR - just in a different way.

----------

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

From report at bugs.python.org  Sun Dec  1 11:54:38 2013
From: report at bugs.python.org (klappnase)
Date: Sun, 01 Dec 2013 10:54:38 +0000
Subject: [issue17397] ttk::themes missing from ttk.py
In-Reply-To: <1363005797.61.0.988966555267.issue17397@psf.upfronthosting.co.za>
Message-ID: <1385895278.91.0.920908263303.issue17397@psf.upfronthosting.co.za>


klappnase added the comment:

> Are 'unloaded but available' themes really available to use?

Yes.

> Does Style.theme_use(available_name) work?

Yes.

> If so, it seems to me that available_name should
> be reported by theme_names.

I agree, one should think so. I am not 100% certain about that, but to me it seems that on the tcl side ttk:themes is newer and thus preferable to theme names which maybe is only still there for backwards compatibility.

Since as a Tkinter user I like Tkinter methods to behave like their Tcl/Tk counterparts (which, if nothing else, helps a lot in reading and understanding  tcl code/documentation (and possibly "translating" tcl code into Python)) I had rather kept theme_names() intact to avoid confusion. Maybe there could simply a line like "Deprecated since Python-xy, use themes() instead." be added to theme_names' doc string ?

----------

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

From report at bugs.python.org  Sun Dec  1 12:03:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 11:03:16 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1385895796.68.0.933356286143.issue11489@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Arfrever. Does this patch fix the test?

----------
Added file: http://bugs.python.org/file32922/test_json_surrogates.patch

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

From report at bugs.python.org  Sun Dec  1 12:10:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 11:10:10 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>
Message-ID: <1385896210.2.0.760540687205.issue19804@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Where ifconfig is located?

----------

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

From report at bugs.python.org  Sun Dec  1 12:15:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 11:15:02 +0000
Subject: [issue16549] regression: -m json.tool module is broken
In-Reply-To: <1353799140.48.0.264325786565.issue16549@psf.upfronthosting.co.za>
Message-ID: <1385896502.18.0.204456425747.issue16549@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This doesn't look related to json tests. Are there other tests failures with similar symptoms (_assert_python is None)?

----------

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

From report at bugs.python.org  Sun Dec  1 12:33:45 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 11:33:45 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1385894817.2297.8.camel@fsol>
Message-ID: <CAH_1eM1xc6G2sR-MNbNJ1BF6cPSKHiE8pTD1-dvjemO6dZnuMw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Well this is wishing thinking, since by returning an empty list you
> force the user to handle EINTR - just in a different way.

I know that returning an empty list changes the semantics: I just
think that's better - or not as bad - than the current possibility of
having any single piece of code possibly die upon EINTR.

If you want to implement retry with timeout re-computation, I'm not
the one to who must be convinced :-)

(BTW, if we go this way, then time.sleep() should probably also be
fixed to retry upon EINTR).

----------

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

From report at bugs.python.org  Sun Dec  1 12:35:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 11:35:41 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <CAH_1eM1xc6G2sR-MNbNJ1BF6cPSKHiE8pTD1-dvjemO6dZnuMw@mail.gmail.com>
Message-ID: <1385897738.2297.9.camel@fsol>


Antoine Pitrou added the comment:

> I know that returning an empty list changes the semantics: I just
> think that's better - or not as bad - than the current possibility of
> having any single piece of code possibly die upon EINTR.
> 
> If you want to implement retry with timeout re-computation, I'm not
> the one to who must be convinced :-)

Or, since we now have the selectors module, we could let select() live
with the current semantics.

By the way, it's already too late for 3.4, which is in feature freeze.

----------

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

From report at bugs.python.org  Sun Dec  1 12:37:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 11:37:42 +0000
Subject: [issue19849] selectors behaviour on EINTR undocumented
Message-ID: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Selector.Select() may return an empty list when interrupted, but the doc doesn't say so. The reader will probably trust the statement that """If timeout is None, the call will block until a monitored file object becomes ready""".

----------
assignee: docs at python
components: Documentation
messages: 204914
nosy: docs at python, neologix, pitrou
priority: normal
severity: normal
status: open
title: selectors behaviour on EINTR undocumented
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  1 13:09:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 12:09:15 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
Message-ID: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

asyncio makes heavy use of SIGCHLD for subprocesses.
A consequence of this if that a lot of syscalls can fail with EINTR (see e.g. issue #18885).

The attached patch uses SA_RESTART (through signal.siginterrupt()) to limit EINTR occurrences, e.g. :
"""
$ ./python -c "import os; from signal import *; signal(SIGALRM, lambda *args: None); alarm(1); os.read(0, 1)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
InterruptedError: [Errno 4] Interrupted system call
"""

With siginterrupt(False):
"""
$ ./python -c "import os; from signal import *; signal(SIGALRM, lambda *args: None); siginterrupt(SIGALRM, False); alarm(1); os.read(0, 1)"
[manual interruption]
^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
KeyboardInterrupt
"""

It doesn't come with test because it's hard to come up with a syscall that's guaranteed to be restarted on al OS (and also because I'm having a hard time with all those mock-based asyncio tests ;-), but at least it doesn't break the test suite :-)

See https://groups.google.com/d/topic/python-tulip/9T2_tGWe0Sc/discussion for more background.

----------
components: Library (Lib)
files: asyncio_sa_restart.diff
keywords: patch
messages: 204915
nosy: gvanrossum, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: asyncio: limit EINTR occurrences with SA_RESTART
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32923/asyncio_sa_restart.diff

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

From report at bugs.python.org  Sun Dec  1 13:16:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 12:16:04 +0000
Subject: [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <1385900164.11.0.385561137376.issue19849@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

How about this?

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file32924/selectors_select_signal.diff

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

From report at bugs.python.org  Sun Dec  1 13:20:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 12:20:12 +0000
Subject: [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <1385900412.54.0.355063703889.issue19849@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Sun Dec  1 13:31:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 12:31:30 +0000
Subject: [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <3dXTN14FPCz7Lk7@mail.python.org>


Roundup Robot added the comment:

New changeset b0c4c7f04f05 by Charles-Fran?ois Natali in branch 'default':
Issue #19849: selectors: Document the possibility of early select() wakeup upon
http://hg.python.org/cpython/rev/b0c4c7f04f05

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

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

From report at bugs.python.org  Sun Dec  1 13:37:01 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 12:37:01 +0000
Subject: [issue19849] selectors behaviour on EINTR undocumented
In-Reply-To: <1385897862.95.0.970282300769.issue19849@psf.upfronthosting.co.za>
Message-ID: <1385901421.24.0.434234228314.issue19849@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


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

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

From report at bugs.python.org  Sun Dec  1 14:27:36 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 13:27:36 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1385904456.02.0.439343670222.issue18843@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


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

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

From report at bugs.python.org  Sun Dec  1 14:33:30 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 13:33:30 +0000
Subject: [issue1611154] os.path.exists("file/") failure on Solaris 9
Message-ID: <1385904810.29.0.288199627903.issue1611154@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


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

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

From report at bugs.python.org  Sun Dec  1 15:10:26 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 14:10:26 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
In-Reply-To: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>
Message-ID: <1385907026.22.0.546346162811.issue19848@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

This is the patch for Python 3.3.

----------
Added file: http://bugs.python.org/file32925/fix_python_33_windows_create_existed_symlink.patch

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

From report at bugs.python.org  Sun Dec  1 15:11:34 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 01 Dec 2013 14:11:34 +0000
Subject: [issue19851] imp.reload problem with submodule
Message-ID: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

To reproduce:

* create a package with the following structure:

    pkg/
      __init__.py
      _sub.py

* __init__.py contains:

   from pkg._sub import *

* the contents of _sub.py is not important

* in a python shell do:

>>> import pkg._sub as s
>>> import imp
>>> imp.reload(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/imp.py", line 297, in reload
    return importlib.reload(module)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/importlib/__init__.py", line 123, in reload
    raise ImportError(_bootstrap._ERR_MSG.format(name), name=name)
ImportError: No module named 'pkg._sub'
>>> 

In earlier python versions this reloaded the pkg._sub module.  Importing _sub from __init__ doesn't seem to be important.

----------
components: Library (Lib)
keywords: 3.3regression
messages: 204920
nosy: brett.cannon, eric.snow, ncoghlan, ronaldoussoren
priority: normal
severity: normal
stage: test needed
status: open
title: imp.reload problem with submodule
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun Dec  1 15:24:58 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 14:24:58 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>
Message-ID: <1385907898.72.0.41793042036.issue19804@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

/bin/ifconfig
(/bin is in ${PATH}.)

----------

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

From report at bugs.python.org  Sun Dec  1 15:25:58 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 14:25:58 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1385907958.6.0.281289531315.issue19828@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Before patch:
$ ./python -S Lib/test/test_site.py 
Traceback (most recent call last):
  File "Lib/test/test_site.py", line 28, in <module>
    raise unittest.SkipTest("importation of site.py suppressed")
unittest.case.SkipTest: importation of site.py suppressed

After patch:
$ ./python -S Lib/test/test_site.py 
sssssssssssssssssssss
----------------------------------------------------------------------
Ran 21 tests in 0.003s

OK (skipped=21)

With this patch, ./python -S Lib/test will report test_site as *skipped* not *failed*.

My grand plan is to make ./python -S Lib/test successful.

----------
Added file: http://bugs.python.org/file32926/fix_test_site_with_s_flag_v2.patch

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

From report at bugs.python.org  Sun Dec  1 15:31:55 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 14:31:55 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1385908315.11.0.975693077424.issue19775@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Updated grammar according to Arfrever's review. Thanks!

Anyway, should samefile accepts only string? Or should it accept Path object as well?

----------
Added file: http://bugs.python.org/file32927/pathlib_samefile_v2.patch

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

From report at bugs.python.org  Sun Dec  1 15:32:13 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 14:32:13 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>
Message-ID: <1385908333.87.0.206820735037.issue19804@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

This test passes (on all branches) after adding "/bin" to hardcoded list in uuid._find_mac().

Minimal solution: Add "/bin" and "/usr/bin" to that list.
Better solution: Search ${PATH}+['/sbin/', '/usr/sbin'] for "ifconfig". In >=3.2 os.get_exec_path() can be used.

----------

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

From report at bugs.python.org  Sun Dec  1 15:36:37 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 14:36:37 +0000
Subject: [issue16549] regression: -m json.tool module is broken
In-Reply-To: <1353799140.48.0.264325786565.issue16549@psf.upfronthosting.co.za>
Message-ID: <1385908597.6.0.375656835464.issue16549@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

No other tests fail in this way.

----------

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

From report at bugs.python.org  Sun Dec  1 15:36:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 01 Dec 2013 14:36:59 +0000
Subject: [issue19852] Misplaced private API method in pathlib.py
Message-ID: <1385908619.09.0.979627399509.issue19852@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In class Path, line 942, you have this comment:

# Public API

but down there, in line 1048, you have this private method:

    def _raw_open(self, flags, mode=0o777):
        """
        Open the file pointed by this path and return a file descriptor,
        as os.open() does.
        """
        if self._closed:
            self._raise_closed()
        return self._accessor.open(self, flags, mode)

Here is the patch to move this private method to where it belongs.

----------
components: Library (Lib)
files: move_private_method_to_its_place.patch
keywords: patch
messages: 204926
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Misplaced private API method in pathlib.py
versions: Python 3.4
Added file: http://bugs.python.org/file32928/move_private_method_to_its_place.patch

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

From report at bugs.python.org  Sun Dec  1 15:40:50 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 14:40:50 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1385908850.48.0.316166622245.issue11489@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

test_json_surrogates.patch fixes these tests.

----------

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

From report at bugs.python.org  Sun Dec  1 15:53:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 14:53:50 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
In-Reply-To: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>
Message-ID: <3dXXXF4lJrz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset 84148898a606 by Charles-Fran?ois Natali in branch 'default':
Issue #18994: Add a missing check for a return value in fcntmodule. Patch by
http://hg.python.org/cpython/rev/84148898a606

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

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

From report at bugs.python.org  Sun Dec  1 15:55:55 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 14:55:55 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
In-Reply-To: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>
Message-ID: <1385909755.94.0.308098838039.issue19848@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/issue19848>
_______________________________________

From report at bugs.python.org  Sun Dec  1 15:56:41 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 14:56:41 +0000
Subject: [issue19851] imp.reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1385909801.36.0.092424237148.issue19851@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/issue19851>
_______________________________________

From report at bugs.python.org  Sun Dec  1 15:56:49 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 14:56:49 +0000
Subject: [issue18994] Inside fcntl module,
 we does not check the return code of all_ins function
In-Reply-To: <1378796910.87.0.444759444485.issue18994@psf.upfronthosting.co.za>
Message-ID: <1385909809.66.0.539000893415.issue18994@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Vajrasky, thanks for the patch!

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

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

From report at bugs.python.org  Sun Dec  1 16:03:28 2013
From: report at bugs.python.org (Martin Natano)
Date: Sun, 01 Dec 2013 15:03:28 +0000
Subject: [issue19853] Add support for Bitrig
Message-ID: <1385910208.9.0.73177918579.issue19853@psf.upfronthosting.co.za>


New submission from Martin Natano:

This patch adds support for Bitrig to 2.7.

----------
components: Build
files: cpython2.7-bitrig.patch
keywords: patch
messages: 204930
nosy: Martin.Natano
priority: normal
severity: normal
status: open
title: Add support for Bitrig
versions: Python 2.7
Added file: http://bugs.python.org/file32929/cpython2.7-bitrig.patch

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

From report at bugs.python.org  Sun Dec  1 16:04:03 2013
From: report at bugs.python.org (Martin Natano)
Date: Sun, 01 Dec 2013 15:04:03 +0000
Subject: [issue19854] Add support for Bitrig to 3.4
Message-ID: <1385910243.77.0.484783750857.issue19854@psf.upfronthosting.co.za>


New submission from Martin Natano:

This patch adds support for Bitrig to 3.4.

----------
components: Build
files: cpython3.4-bitrig.patch
keywords: patch
messages: 204931
nosy: Martin.Natano
priority: normal
severity: normal
status: open
title: Add support for Bitrig to 3.4
versions: Python 3.4
Added file: http://bugs.python.org/file32930/cpython3.4-bitrig.patch

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

From report at bugs.python.org  Sun Dec  1 16:04:15 2013
From: report at bugs.python.org (Martin Natano)
Date: Sun, 01 Dec 2013 15:04:15 +0000
Subject: [issue19853] Add support for Bitrig to 2.7
In-Reply-To: <1385910208.9.0.73177918579.issue19853@psf.upfronthosting.co.za>
Message-ID: <1385910255.1.0.584634239545.issue19853@psf.upfronthosting.co.za>


Changes by Martin Natano <natanoptacek at gmail.com>:


----------
title: Add support for Bitrig -> Add support for Bitrig to 2.7

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

From report at bugs.python.org  Sun Dec  1 16:12:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:12:48 +0000
Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or
 /usr/sbin
Message-ID: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The uuid._find_mac() function tests that executable file exist before run it. First it tries to run unmodified executable name (i.e. from $PATH) and then from the /sbin or /usr/sbin directories. However test for unmodified executable name is wrong, actually it tests that executable name exists in current directory rather than in $PATH.

As a result uuid._find_mac() always fails on platforms where ifconfig located in $PATH but not in /sbin or /usr/sbin (i.e. Gentoo). If unixdll_getnode() fails too, uuid.getnode() fallbacks to use of _random_getnode(). This is security issue.

test_uuid fails on such platforms too.

Here is a patch for 3.3+. Other Python versions requires different solution. For example this check can be just removed.

----------
components: Library (Lib)
files: uuid_find_mac_which.patch
keywords: patch
messages: 204932
nosy: Arfrever, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: uuid._find_mac fails if an executable not in /sbin or /usr/sbin
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32931/uuid_find_mac_which.patch

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

From report at bugs.python.org  Sun Dec  1 16:15:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:15:29 +0000
Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or
 /usr/sbin
In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>
Message-ID: <1385910929.63.0.517919024602.issue19855@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Initially the issue was reported in msg204881.

----------

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

From report at bugs.python.org  Sun Dec  1 16:16:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:16:05 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>
Message-ID: <1385910965.31.0.344314699393.issue19804@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is different issue. See issue19855.

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

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

From report at bugs.python.org  Sun Dec  1 16:21:34 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 15:21:34 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>
Message-ID: <1385911294.37.0.713336361208.issue19804@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

The test currently uses:
@unittest.skipUnless(os.name == 'posix', 'requires Posix')

Maybe this test should be skipped also on posix systems with ifconfig not available at all?

----------

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

From report at bugs.python.org  Sun Dec  1 16:31:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 15:31:24 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <3dXYMc12Wsz7Ll1@mail.python.org>


Roundup Robot added the comment:

New changeset 02d186e3af09 by Serhiy Storchaka in branch '2.7':
Fixed JSON tests on wide build when ran from *.pyc files (issue #11489).
http://hg.python.org/cpython/rev/02d186e3af09

----------

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

From report at bugs.python.org  Sun Dec  1 16:39:43 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 01 Dec 2013 15:39:43 +0000
Subject: [issue10976] json.loads() raises TypeError on bytes object
In-Reply-To: <1295636509.41.0.0138366952356.issue10976@psf.upfronthosting.co.za>
Message-ID: <1385912383.26.0.603339173108.issue10976@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Bike-shedding: instead of jsonb, make it json.bytes. Else, it may get confused with other protocols, such as "JSONP" or "BSON".

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

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

From report at bugs.python.org  Sun Dec  1 16:42:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:42:22 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1385912542.58.0.460342831626.issue11489@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/issue11489>
_______________________________________

From report at bugs.python.org  Sun Dec  1 16:46:29 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 01 Dec 2013 15:46:29 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1385876171.82.0.699772233915.issue18716@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7LDD6SEJR1cZxhVtfg9VCuy_4eBKz2B9ZbXV289pZf7w@mail.gmail.com>


Brett Cannon added the comment:

On Sun, Dec 1, 2013 at 12:36 AM, Larry Hastings <report at bugs.python.org>wrote:

>
> Larry Hastings added the comment:
>
> They're not on Python 3.  I think we should keep the deprecation and let
> them roll their own when they upgrade.  It's not like the module provides
> much functionality in the first place.
>

What Larry said. =) Plus a single user in the world is not enough to
warrant keeping a module. The code is simple enough that if they want to
keep it they can simply copy it into their own code.

----------

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

From report at bugs.python.org  Sun Dec  1 16:55:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:55:34 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1385913334.59.0.0178571745655.issue19837@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree that adding a new module is very bad idea.

I think that the reviving the encoding parameter is a lest wrong way. json.dumps() should return bytes when the encoding argument is specifiead and str otherwise. json.dump() should write binary data when the encoding argument is specifiead and a text otherwise. This is not perfect design, but it has precendences in XML modules.

----------

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

From report at bugs.python.org  Sun Dec  1 16:59:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 15:59:41 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
In-Reply-To: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>
Message-ID: <1385913581.67.0.595717774982.issue19848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are several similar issues on the tracker.

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

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

From report at bugs.python.org  Sun Dec  1 16:59:47 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 01 Dec 2013 15:59:47 +0000
Subject: [issue19853] Add support for Bitrig to 2.7
In-Reply-To: <1385910208.9.0.73177918579.issue19853@psf.upfronthosting.co.za>
Message-ID: <1385913587.73.0.867201461736.issue19853@psf.upfronthosting.co.za>


Brett Cannon added the comment:

To prevent lesser-used OSs from being poorly serviced by Python we do not accept patches to add support for them. We suggest alternative OSs keep their own set of patches external to Python for ease of updating. We have mirrors on both bitbucket and github if you would like to maintain your patches on either site based off those mirrors.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 17:00:27 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 01 Dec 2013 16:00:27 +0000
Subject: [issue19854] Add support for Bitrig to 3.4
In-Reply-To: <1385910243.77.0.484783750857.issue19854@psf.upfronthosting.co.za>
Message-ID: <1385913627.19.0.0439547521044.issue19854@psf.upfronthosting.co.za>


Brett Cannon added the comment:

As I said on the similar bug for adding support in Python 2.7:

To prevent lesser-used OSs from being poorly serviced by Python we do not accept patches to add support for them. We suggest alternative OSs keep their own set of patches external to Python for ease of updating. We have mirrors on both bitbucket and github if you would like to maintain your patches on either site based off those mirrors.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 17:08:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 16:08:13 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
In-Reply-To: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>
Message-ID: <1385914093.88.0.86155567319.issue19848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue16074.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> bad error message in os.rename

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

From report at bugs.python.org  Sun Dec  1 17:09:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 16:09:43 +0000
Subject: [issue16074] bad error message in os.rename
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1385914183.65.0.792488573296.issue16074@psf.upfronthosting.co.za>


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


----------
keywords: +3.3regression

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

From report at bugs.python.org  Sun Dec  1 17:56:13 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 01 Dec 2013 16:56:13 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1385916973.21.0.728037535114.issue19850@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Do you haven an example of a program using asyncio that fails because of this?

Adding gps because he seems to agree that EINTR must die.

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

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

From report at bugs.python.org  Sun Dec  1 18:33:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 01 Dec 2013 17:33:04 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1385919184.37.0.105230856128.issue19828@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's not relevant, though.  In fact, the existing error message for running the module directly is exactly correct: the entire test module fails to run, which is a more accurate reflection of the reality than showing all of the individual tests as skipped.  

If you run test_site under the test harness you also currently get the correct result:

rdmurray at hey:~/python/p34>./python -S Lib/test test_site
[1/1] test_site
test_site skipped -- importation of site.py suppressed
1 test skipped:
    test_site

In other words, you don't need to do anything to test_site to get it to work correctly for your desired goal, it already does.

----------

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

From report at bugs.python.org  Sun Dec  1 18:58:30 2013
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 01 Dec 2013 17:58:30 +0000
Subject: [issue19839] bz2: regression wrt supporting files with trailing
 garbage after EOF
In-Reply-To: <1385806619.04.0.329117891617.issue19839@psf.upfronthosting.co.za>
Message-ID: <1385920710.21.0.277835602054.issue19839@psf.upfronthosting.co.za>


Nadeem Vawda added the comment:

I'll have a patch for this in the next couple of days (and a similar one
for the lzma module, which has the same issue (even though it's not a
regression in that case)).

In the meanwhile, you can work around this by feeding the compressed data
to a BZ2Decompressor yourself - it stops at the end of the bz2 stream,
with any leftover data stored in its 'unused_data' attribute.

----------
assignee:  -> nadeem.vawda
stage:  -> needs patch

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

From report at bugs.python.org  Sun Dec  1 19:28:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 18:28:39 +0000
Subject: [issue19804] test_uuid.TestUUID.test_find_mac() fails
In-Reply-To: <1385911294.37.0.713336361208.issue19804@psf.upfronthosting.co.za>
Message-ID: <3984829.Scirxt5xa0@raxxla>


Serhiy Storchaka added the comment:

When someone will report about failures on such systems.

----------

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

From report at bugs.python.org  Sun Dec  1 20:01:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 19:01:14 +0000
Subject: [issue19856] Possible bug in shutil.move() on Windows
Message-ID: <1385924474.74.0.566817188038.issue19856@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Perhaps following code fails on Windows (while successes on Linux): 

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo/', 'bar/')

However shutil.move('foo', 'bar/') and shutil.move('foo\\', 'bar/') should work.

----------
components: Library (Lib), Windows
messages: 204948
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Possible bug in shutil.move() on Windows
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec  1 20:14:01 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Dec 2013 19:14:01 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385925241.06.0.376665358842.issue18885@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I do not consider this a feature; that EINTR is exposed as an exception from the API is a bug.  But Larry is the only one who can actually make that decision as the 3.4 release manager (+nosy'd).

> by returning an empty list you force the user to handle EINTR -
> just in a different way.

The user now only has one thing to deal with instead of two: an empty list being returned; something they should already have been dealing with. Gone will be the OSError(EINTR) exception as a rare, often never tested for, alternate form of the same retry needed indication.

I never see code intentionally wanting to receive and handle an OSError(EINTR) exception but I constantly run into code that is buggy due to some library it is using not getting this right... Where it isn't up to the code exhibiting the problem because the only place to fix it is within the library they use that is outside of that code's control.

We've got the opportunity to fix this nit once and for all here, lets do it.

----------
nosy: +larry

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

From report at bugs.python.org  Sun Dec  1 20:40:24 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 01 Dec 2013 19:40:24 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1385926824.0.0.338852467339.issue19850@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

It sounds like doing this is fine (as Glyph suggests in the email thread) but it isn't magically going to solve all EINTR problems, just reduce the number of calls that could encounter them.

http://man7.org/linux/man-pages/man7/signal.7.html see the "Interruption of system calls and library functions" section.

Note that with this SA_RESTART flag set via siginterrupt you _may_ be making a trade off between being able to process python signal handlers during long reads or writes vs having to wait until the entire thing has finished.

given that, I'm ambivalent about this patch being worthy.

(re: Explicitly testing this, it is hard. for the broader Python test suite as a whole I've been pondering a regrtest mode that'll continually pester all of the test processes with signals to try and expose EINTR issues.  Low on my TODO ideas list, I haven't written code to do it.)

----------

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

From report at bugs.python.org  Sun Dec  1 20:44:48 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 19:44:48 +0000
Subject: [issue6477] Pickling of NoneType raises PicklingError
In-Reply-To: <1247505641.96.0.188774248495.issue6477@psf.upfronthosting.co.za>
Message-ID: <1385927088.67.0.315158143522.issue6477@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I thought it over. I don't think the fix is appropriate for 2.x, as it seems closer to being an extra feature than a bug fix.

Thanks Antoine for calling me out on this one.

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

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

From report at bugs.python.org  Sun Dec  1 21:01:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Dec 2013 20:01:33 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1385928093.98.0.240604491695.issue19100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Any review?

----------

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

From report at bugs.python.org  Sun Dec  1 21:03:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 20:03:01 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1385925241.06.0.376665358842.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385928178.2297.23.camel@fsol>


Antoine Pitrou added the comment:

> I do not consider this a feature; that EINTR is exposed as an
> exception from the API is a bug.

select() currently works as specified; you are proposing a
compatibility-breaking change to the API, not a bugfix.

We're left with the fact that the API is inconvenient: but we now have
the selectors module and can advocate that instead of breaking existing
code during a feature freeze period.

(or we can retry on EINTR, which has the benefit of not creating new
situations to deal with in existing code)

> The user now only has one thing to deal with instead of two: an empty
> list being returned; something they should already have been dealing
> with.

Returning an empty list when no timeout has been passed has never been a
feature of select(), which is why users are not expected to be dealing
with it.

----------

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

From report at bugs.python.org  Sun Dec  1 21:20:37 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 01 Dec 2013 20:20:37 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1385929237.81.0.587169208411.issue18843@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

Hi,
  I think I should report back what I found on the hardware side. While memory testing tools like memtest86+ and other did not find any error, the built in Dell ePSA test suite likely does compute a checksum of tested memory regions. It reported some addresses/regions as failed, sadly nobody seems to know details of the failing tests. On repeated testing different memory regions were reported, so I never understood whether that is a bad CPU cache or something randomizing the issue observed. At least, only one of the two SO-DIMMs caused the problems so lets conclude it was partly baked up and failing randomly. At that time it seemed the cause was either bad CPU producing just too much heat or the fan. Fan was replaced, max temps went down from 92 oC to 82 oC. Two months later I faced more and more often that an external HDMI-connected display did not receive signal, so even the CPU got replaced. I got another drop in max temperatures, now max are about 70 oC. Cool!

Back to python, the random crashes of my apps stopped after the memory module being replaced, actually who pair was replaced. I started to dream about linux kernel making mirroring inside memory for failure resiliency but there is nothing like that available.

In summary, this lesson was hard and showed that there are no good tools to test hardware. Checksums should be used always and bits tested for fading over the time. The mirroring trick could have also uncovered a failing memory or CPU. Seems there is still way to go to a perfect computer.

Thanks to everybody for their efforts on this issue. Whether python takes something from this lesson is up to you.

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

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

From report at bugs.python.org  Sun Dec  1 21:22:29 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 01 Dec 2013 20:22:29 +0000
Subject: [issue18897] Illegal instruction at Python-2.7.5/Modules/_sre.c:1173
In-Reply-To: <1377987974.98.0.815254157912.issue18897@psf.upfronthosting.co.za>
Message-ID: <1385929349.9.0.117737345824.issue18897@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

The issue could have been caused the malfunctioning memory or CPU.
http://bugs.python.org/issue18843#msg204954

----------

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

From report at bugs.python.org  Sun Dec  1 21:23:05 2013
From: report at bugs.python.org (Martin Mokrejs)
Date: Sun, 01 Dec 2013 20:23:05 +0000
Subject: [issue18845] 2.7.5-r2: Fatal Python error: Segmentation fault
In-Reply-To: <1377546426.38.0.266867499434.issue18845@psf.upfronthosting.co.za>
Message-ID: <1385929385.88.0.754581668897.issue18845@psf.upfronthosting.co.za>


Martin Mokrejs added the comment:

The issue could have been caused the malfunctioning memory or CPU.
http://bugs.python.org/issue18843#msg204954

----------

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

From report at bugs.python.org  Sun Dec  1 21:29:43 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 20:29:43 +0000
Subject: [issue3657] pickle can pickle the wrong function
In-Reply-To: <1219561308.34.0.393729548724.issue3657@psf.upfronthosting.co.za>
Message-ID: <1385929783.0.0.423760233385.issue3657@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

This was fixed in 3.4 with the introduction of method pickling. I don't think it would be appropriate to backport this to 2.7. Thus, I am closing this as a won't fix for 2.x.

----------
assignee:  -> alexandre.vassalotti
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Dec  1 21:38:49 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 20:38:49 +0000
Subject: [issue18843] Py_FatalError (msg=0x7f0e3b373232 "bad leading pad
 byte") at Python-2.7.5/Python/pythonrun.c:1689
In-Reply-To: <1377534511.92.0.663269448586.issue18843@psf.upfronthosting.co.za>
Message-ID: <1385930329.28.0.0981102041029.issue18843@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Thanks for the feedback!

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 21:56:47 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Dec 2013 20:56:47 +0000
Subject: [issue19848] Misleading error on creating already existed symlink
In-Reply-To: <1385891874.14.0.756593701822.issue19848@psf.upfronthosting.co.za>
Message-ID: <1385931407.17.0.235978602172.issue19848@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/issue19848>
_______________________________________

From report at bugs.python.org  Sun Dec  1 21:57:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 20:57:46 +0000
Subject: [issue10976] json.loads() raises TypeError on bytes object
In-Reply-To: <1385912383.26.0.603339173108.issue10976@psf.upfronthosting.co.za>
Message-ID: <CADiSq7enVZO-exTcMQ_420TFFJdx=QPPrHTw-mt1j7=PoH8xmA@mail.gmail.com>


Nick Coghlan added the comment:

json.bytes would also work for me. It wouldn't need to replicate the full
main module API, just combine the text transform with UTF-8 encoding and
decoding (as well as autodetected UTF-16 and UTF-32 decoding) for the main
4 functions (dump[s], load[s]).

If people want UTF-16 and UTF-32 *en*coding (which seem to be rarely used
in combination with JSON), then they can invoke the text transform version
directly, and then do a separate encoding step.

----------

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

From report at bugs.python.org  Sun Dec  1 22:03:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 21:03:44 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385913334.59.0.0178571745655.issue19837@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cXKkLbTmLHfhL5qaFaUZywAQWx+bAEHfXRGTnkPwEGAA@mail.gmail.com>


Nick Coghlan added the comment:

Changing return type based on argument *values* is still a bad idea in
general.

It also makes it hard to plug the API in to generic code that is designed
to work with any dump/load based serialisation protocol.

MvL suggested a json.bytes submodule (rather than a separate top level
module) in the other issue and that sounds reasonable to me, especially
since json is already implemented as a package.

----------

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

From report at bugs.python.org  Sun Dec  1 22:09:57 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 21:09:57 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385926824.0.0.338852467339.issue19850@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0u0BKBtV3ZZid=f1HzqpEUmsht7zdV+oHDR5ibMnvCqw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> It sounds like doing this is fine (as Glyph suggests in the email thread) but it isn't magically going to solve all EINTR problems, just reduce the number of calls that could encounter them.

Indeed, hence "*limit* EINTR occurrences" :-)

> Note that with this SA_RESTART flag set via siginterrupt you _may_ be making a trade off between being able to process python signal handlers during long reads or writes vs having to wait until the entire thing has finished.

asyncio uses a wakeup FD, registered in the main event loop: so as
soon as a signal is received, the main loop will wake up and run the
signal handler. So this would only be a problem if you were doing a
blocking syscall from the main loop thread, which would be a really
bad idea anyway.

----------

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

From report at bugs.python.org  Sun Dec  1 22:13:02 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Dec 2013 21:13:02 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385932382.69.0.259030898986.issue18885@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I don't want this checked in to 3.4.

(Congratulations, this is my first "no" as a release manager!)

----------

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

From report at bugs.python.org  Sun Dec  1 22:21:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 21:21:33 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <CADiSq7cXKkLbTmLHfhL5qaFaUZywAQWx+bAEHfXRGTnkPwEGAA@mail.gmail.com>
Message-ID: <1385932890.2297.25.camel@fsol>


Antoine Pitrou added the comment:

> MvL suggested a json.bytes submodule (rather than a separate top level
> module) in the other issue and that sounds reasonable to me, especially
> since json is already implemented as a package.

I don't really find it reasonable to add a phantom module entirely for
the purpose of exposing an API more similar to the Python 2 one. I don't
think this design pattern has already been used.

If we add a json_bytes method, it will be simple enough for folks to add
the appropriate rules in their compat module (and/or for six to expose
it).

----------

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

From report at bugs.python.org  Sun Dec  1 22:22:22 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:22:22 +0000
Subject: [issue5885] uuid.uuid1() is too slow
In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za>
Message-ID: <1385932942.36.0.368257586133.issue5885@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I agree that there is a maintenance cost associated with C extension modules. However, I would certainly be glad if it allowed us to eliminate uses of ctypes in this module because ctypes is quite unsafe and doesn't work well across platforms (though it is admittedly very convenient).

----------

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

From report at bugs.python.org  Sun Dec  1 22:26:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Dec 2013 21:26:58 +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: <3dXjFs5g0sz7LmB@mail.python.org>


Roundup Robot added the comment:

New changeset c6bb6f304f75 by Alexandre Vassalotti in branch '3.3':
Issue #11480: Fixed copy.copy to work with classes with custom metaclasses.
http://hg.python.org/cpython/rev/c6bb6f304f75

New changeset c4715c9f442f by Alexandre Vassalotti in branch 'default':
Issue #11480: Merge with 3.3.
http://hg.python.org/cpython/rev/c4715c9f442f

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

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

From report at bugs.python.org  Sun Dec  1 22:27:54 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:27:54 +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: <1385933274.67.0.296731111618.issue11480@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Thank you for the patch!

----------
assignee:  -> alexandre.vassalotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.4 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Dec  1 22:28:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Dec 2013 21:28:22 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1385933302.31.0.823251016313.issue18885@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sun Dec  1 22:29:14 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:29:14 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1385933354.89.0.607523787882.issue18473@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
assignee:  -> alexandre.vassalotti
priority: normal -> high
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.4

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

From report at bugs.python.org  Sun Dec  1 22:32:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Dec 2013 21:32:48 +0000
Subject: [issue19857] test_imaplib doesn't always reap SocketServer thread
Message-ID: <1385933568.04.0.453956644253.issue19857@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/5901/steps/test/logs/stdio

"""
[134/387/1] test_signal
Timeout (1:00:00)!
Thread 0x0000000801e24800 (most recent call first):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/socketserver.py", line 155 in _eintr_retry
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/socketserver.py", line 237 in serve_forever
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 869 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 889 in _bootstrap

Thread 0x0000000801407400 (most recent call first):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_signal.py", line 529 in test_itimer_real
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 571 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/case.py", line 610 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 117 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/suite.py", line 79 in __call__
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/unittest/runner.py", line 168 in run
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support/__init__.py", line 1685 in _run_suite
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support/__init__.py", line 1719 in run_unittest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_signal.py", line 934 in test_main
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 967 in runtest
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 763 in main
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/__main__.py", line 3 in <module>
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 73 in _run_code
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/runpy.py", line 160 in _run_module_as_main
*** Error code 1
"""

test_signal hangs, but that's because there's a dangling socketserver thread running from a failed test_imaplib test earlier in the test run:
"""
======================================================================
ERROR: test_login_cram_md5 (test.test_imaplib.ThreadedNetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 940, in _command
    self.send(CRLF)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 276, in send
    self.sock.sendall(data)
BrokenPipeError: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 216, in reaped_pair
    yield server, client
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 319, in test_login_cram_md5
    ret, data = client.login_cram_md5("tim", "tanstaaftanstaaf")
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 549, in login_cram_md5
    return self.authenticate('CRAM-MD5', self._CRAM_MD5_AUTH)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 380, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mech)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 1127, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 942, in _command
    raise self.abort('socket error: %s' % val)
imaplib.abort: socket error: [Errno 32] Broken pipe

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/support/__init__.py", line 1831, in decorator
    return func(*args)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 320, in test_login_cram_md5
    self.assertEqual(ret, "OK")
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_imaplib.py", line 218, in reaped_pair
    client.logout()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 570, in logout
    self.shutdown()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/imaplib.py", line 283, in shutdown
    self.sock.shutdown(socket.SHUT_RDWR)
ConnectionResetError: [Errno 54] Connection reset by peer
"""

Here's the code in charge of stopping the client and server:
"""
    def reaped_pair(self, hdlr):
        server, thread = self.make_server((support.HOST, 0), hdlr)
        client = self.imap_class(*server.server_address)
        try:
            yield server, client
        finally:
            client.logout()
            self.reap_server(server, thread)
"""

But if client.logout() raises and exception - as is the case above - reap_server() is never called.

----------
components: Tests
messages: 204967
nosy: neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: test_imaplib doesn't always reap SocketServer thread
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Dec  1 22:34:23 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:34:23 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1385933663.8.0.823990804938.issue11299@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Allowing generators to be deepcopied via their code object should be fine.

----------
stage: test needed -> needs patch
title: Allow deepcopying and pickling paused generators -> Allow deepcopying paused generators
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sun Dec  1 22:38:10 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:38:10 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1385933890.32.0.919123216374.issue3208@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy:  -alexandre.vassalotti
stage:  -> needs patch
versions: +Python 3.5 -Python 3.0

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

From report at bugs.python.org  Sun Dec  1 22:43:28 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 01 Dec 2013 21:43:28 +0000
Subject: [issue19707] Check if unittest.mock needs updating for PEP 451
Message-ID: <1385934208.56.0.732647798541.issue19707@psf.upfronthosting.co.za>


New submission from Michael Foord:

It shouldn't do, so long as __import__ supports PEP 451. unittest.mock.patch uses __import__ to find modules specified by name.

----------

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

From report at bugs.python.org  Sun Dec  1 22:44:07 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:44:07 +0000
Subject: [issue2295] cPickle corner case - docs or bug?
In-Reply-To: <1205608726.73.0.310899298914.issue2295@psf.upfronthosting.co.za>
Message-ID: <1385934247.18.0.725231599461.issue2295@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

We can't fix this without a working test case. Feel free to re-open if you find one.

----------
assignee: docs at python -> alexandre.vassalotti
components:  -Documentation
resolution:  -> works for me
status: open -> closed
versions: +Python 2.7 -Python 2.6, Python 3.1

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

From report at bugs.python.org  Sun Dec  1 22:52:10 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:52:10 +0000
Subject: [issue11349] _pickle should implement the module finalisation protocol
In-Reply-To: <1298856551.7.0.829193493202.issue11349@psf.upfronthosting.co.za>
Message-ID: <1385934730.01.0.775708806056.issue11349@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I have implemented PEP 3121 module finalization for _pickle in 64c6d52793be.

----------
assignee:  -> alexandre.vassalotti
nosy: +alexandre.vassalotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 22:56:56 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 21:56:56 +0000
Subject: [issue15667] PEP 3121, 384 refactoring applied to pickle module
In-Reply-To: <1345038957.09.0.78094807427.issue15667@psf.upfronthosting.co.za>
Message-ID: <1385935016.11.0.242345532381.issue15667@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I have implemented PEP 3121 module finalization for _pickle in 64c6d52793be. I don't see the use case for implementing PEP 384 stable ABI, since _pickle is only distributed with Python.

----------
assignee:  -> alexandre.vassalotti
nosy: +alexandre.vassalotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec  1 23:07:28 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 22:07:28 +0000
Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1385935648.67.0.660010779222.issue4727@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

PEP 3154 implemented support for pickling classes taking keyword-only arguments.

The copy module should be updated to use __getnewargs_ex__ when available through object.__reduce__(4).

----------
nosy: +alexandre.vassalotti
superseder:  -> Implement PEP 3154 (pickle protocol 4)
title: pickle/copyreg doesn't support keyword only arguments in __new__ -> copyreg doesn't support keyword only arguments in __new__
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Sun Dec  1 23:07:37 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 22:07:37 +0000
Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1385935657.3.0.383563984117.issue4727@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
superseder: Implement PEP 3154 (pickle protocol 4) -> 

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

From report at bugs.python.org  Sun Dec  1 23:42:02 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 22:42:02 +0000
Subject: [issue10717] Multiprocessing module Pickling unPickling issues
In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>
Message-ID: <1385937722.77.0.527801965465.issue10717@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Without a reproducible test case, I am afraid there is nothing we can do here.

----------
assignee:  -> alexandre.vassalotti
components: +Library (Lib) -None
nosy: +alexandre.vassalotti
resolution:  -> works for me
stage:  -> test needed
status: open -> closed
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Dec  2 00:04:43 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 01 Dec 2013 23:04:43 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1385939083.54.0.79310001605.issue7105@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Here's a different approach.
Simply avoid the use of iterators over the underlying container.
Instead, we iterate over lists of items/keys/values etc.

----------
Added file: http://bugs.python.org/file32932/weakref.patch

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

From report at bugs.python.org  Mon Dec  2 00:09:55 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Dec 2013 23:09:55 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385932890.2297.25.camel@fsol>
Message-ID: <CADiSq7cynVuOh5soq_-9cyFbt00bNfAQA3HG1qCC8t5mGJDB-g@mail.gmail.com>


Nick Coghlan added the comment:

The parallel API would have to be:

json.dump_bytes
json.dumps_bytes
json.load_bytes
json.loads_bytes

That is hardly an improvement over:

json.bytes.dump
json.bytes.dumps
json.bytes.load
json.bytes.loads

It doesn't need to be documented as a completely separate module, it can
just be a subsection in the json module docs with a reference to the
relevant RFC.

The confusion is inherent in the way the RFC was written, this is just an
expedient way to resolve that: the json module implements the standard, the
bytes submodule implements the RFC.

"Namespaces are a honking great idea; let's do more of those"

----------

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

From report at bugs.python.org  Mon Dec  2 00:19:21 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 23:19:21 +0000
Subject: [issue10717] Multiprocessing module Pickling unPickling issues
In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>
Message-ID: <1385939961.07.0.395100319113.issue10717@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Look like I isolated the problem. It seems multiprocessing is using cPickle which cannot be extended with ForkingPickler, unlike the Python version of the pickle module.

15:09:29 [ ~/pythondev/python2.7 ]$ ./python.exe issue10717.py
Traceback (most recent call last):
  File "issue10717.py", line 8, in <module>
    p.apply(Test().hello, ("jimbo",))
  File "/Users/avassalotti/PythonDev/python2.7/Lib/multiprocessing/pool.py", line 244, in apply
    return self.apply_async(func, args, kwds).get()
  File "/Users/avassalotti/PythonDev/python2.7/Lib/multiprocessing/pool.py", line 558, in get
    raise self._value
cPickle.PicklingError: Can't pickle <type 'instancemethod'>: attribute lookup __builtin__.instancemethod failed

----------
assignee: alexandre.vassalotti -> 
resolution: works for me -> 
stage: test needed -> needs patch
status: closed -> open
Added file: http://bugs.python.org/file32933/issue10717.py

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

From report at bugs.python.org  Mon Dec  2 00:19:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Dec 2013 23:19:29 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <CADiSq7cynVuOh5soq_-9cyFbt00bNfAQA3HG1qCC8t5mGJDB-g@mail.gmail.com>
Message-ID: <1385939966.2297.34.camel@fsol>


Antoine Pitrou added the comment:

> The parallel API would have to be:
> 
> json.dump_bytes
> json.dumps_bytes
> json.load_bytes
> json.loads_bytes

No, only one function dump_bytes() is needed, and it would return a
bytes object ("dumps" meaning "dump string", already). loads() can be
polymorphic without creating a new function.

I don't think the functions taking file objects are used often enough to
warrant a second API to deal with binary files.

> It doesn't need to be documented as a completely separate module, it can
> just be a subsection in the json module docs with a reference to the
> relevant RFC.

It's still completely weird and unusual.

> "Namespaces are a honking great idea; let's do more of those"

And also "flat is better than nested".

Especially when you're proposing than one API be at level N, and the
other, closely related API be at level N+1.

----------

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

From report at bugs.python.org  Mon Dec  2 00:59:52 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 01 Dec 2013 23:59:52 +0000
Subject: [issue10717] Multiprocessing module cannot call instance methods
 across processes
In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za>
Message-ID: <1385942392.3.0.683594302782.issue10717@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
title: Multiprocessing module Pickling unPickling issues -> Multiprocessing module cannot call instance methods across processes

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

From report at bugs.python.org  Mon Dec  2 01:03:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 00:03:43 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <3dXmkl00BNz7Ln0@mail.python.org>


Roundup Robot added the comment:

New changeset 2df5e1f537b0 by Gregory P. Smith in branch 'default':
Fixes issue #15798: subprocess.Popen() no longer fails if file
http://hg.python.org/cpython/rev/2df5e1f537b0

----------

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

From report at bugs.python.org  Mon Dec  2 01:19:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 00:19:31 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1385943571.78.0.892980480759.issue7105@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I appreciate the simplicity, but I don't think it is acceptable -- if the dict is large, materializing the entire list of keys/values/items might allocate a prohibitive amount of memory. It's worse if you have code that is expected to break out of the loop.

----------

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

From report at bugs.python.org  Mon Dec  2 01:28:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 00:28:02 +0000
Subject: [issue19754] pickletools.optimize doesn't reframe correctly
In-Reply-To: <1385299744.51.0.958781846562.issue19754@psf.upfronthosting.co.za>
Message-ID: <3dXnGk2B6Qz7Lkr@mail.python.org>


Roundup Robot added the comment:

New changeset bb71baa28f1b by Alexandre Vassalotti in branch 'default':
Issue #19754: Make pickletools.optimize respect the frame size target.
http://hg.python.org/cpython/rev/bb71baa28f1b

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

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

From report at bugs.python.org  Mon Dec  2 01:28:56 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 00:28:56 +0000
Subject: [issue19754] pickletools.optimize doesn't reframe correctly
In-Reply-To: <1385299744.51.0.958781846562.issue19754@psf.upfronthosting.co.za>
Message-ID: <1385944136.57.0.14491701114.issue19754@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Now, pickletools.optimize doesn't do anything on protocol 4. :)

----------
assignee:  -> alexandre.vassalotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Dec  2 01:32:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 00:32:00 +0000
Subject: [issue19754] pickletools.optimize doesn't reframe correctly
In-Reply-To: <1385299744.51.0.958781846562.issue19754@psf.upfronthosting.co.za>
Message-ID: <3dXnMM1ZlDz7Lp3@mail.python.org>


Roundup Robot added the comment:

New changeset 9feada79a411 by Alexandre Vassalotti in branch 'default':
Issue #19754: Fix typo.
http://hg.python.org/cpython/rev/9feada79a411

----------

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

From report at bugs.python.org  Mon Dec  2 01:52:35 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 00:52:35 +0000
Subject: [issue19780] Pickle 4 frame headers optimization
In-Reply-To: <1385416509.02.0.493465582704.issue19780@psf.upfronthosting.co.za>
Message-ID: <1385945555.64.0.859032395146.issue19780@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Yeah, let's close this. It is much simpler to just double the frame size target if the extra reads ever become a performance issue.

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

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

From report at bugs.python.org  Mon Dec  2 02:00:14 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 01:00:14 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
Message-ID: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

PEP 3154 introduced the MEMOIZE opcode which lowered the overhead of memoization compared to the PUT opcodes which were previously used.

We should update pickletools.optimize to remove superfluous uses of this new opcode.

----------
components: Library (Lib)
messages: 204985
nosy: alexandre.vassalotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Make pickletools.optimize aware of the MEMOIZE opcode.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec  2 02:10:44 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 01:10:44 +0000
Subject: [issue19834] Unpickling exceptions pickled by Python 2
In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za>
Message-ID: <1385946644.37.0.305698111424.issue19834@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Feel free to commit once you have addressed the remaining comments.

----------
assignee:  -> doerwalter

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

From report at bugs.python.org  Mon Dec  2 02:12:58 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 01:12:58 +0000
Subject: [issue18073] pickle.Unpickler may read too many bytes,
 causing hangs with blocking input stream
In-Reply-To: <1369677881.19.0.98233808248.issue18073@psf.upfronthosting.co.za>
Message-ID: <1385946778.4.0.954288385296.issue18073@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
assignee:  -> alexandre.vassalotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Dec  2 02:14:27 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 01:14:27 +0000
Subject: [issue19835] Add a MemoryError singleton to fix an unlimited loop
 when the memory is exhausted
In-Reply-To: <1385745842.98.0.409110544048.issue19835@psf.upfronthosting.co.za>
Message-ID: <1385946867.06.0.666913610502.issue19835@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy:  -alexandre.vassalotti

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

From report at bugs.python.org  Mon Dec  2 02:28:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 01:28:39 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <3dXpch4TzGz7LqC@mail.python.org>


Roundup Robot added the comment:

New changeset 07425df887b5 by Gregory P. Smith in branch '3.3':
Fixes issue #15798: subprocess.Popen() no longer fails if file
http://hg.python.org/cpython/rev/07425df887b5

----------

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

From report at bugs.python.org  Mon Dec  2 02:58:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 01:58:21 +0000
Subject: [issue19781] No SSL match_hostname() in ftplib
In-Reply-To: <1385423063.98.0.532680357118.issue19781@psf.upfronthosting.co.za>
Message-ID: <3dXqH047SCzLrD@mail.python.org>


Roundup Robot added the comment:

New changeset 373797990f57 by Christian Heimes in branch 'default':
Issue #19781: ftplib now supports SSLContext.check_hostname and server name
http://hg.python.org/cpython/rev/373797990f57

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

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

From report at bugs.python.org  Mon Dec  2 02:58:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 01:58:21 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <3dXqH12RvhzLrD@mail.python.org>


Roundup Robot added the comment:

New changeset aa531135bc6b by Christian Heimes in branch 'default':
Issue #19509: Add SSLContext.check_hostname to match the peer's certificate
http://hg.python.org/cpython/rev/aa531135bc6b

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

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

From report at bugs.python.org  Mon Dec  2 04:18:12 2013
From: report at bugs.python.org (Julian Berman)
Date: Mon, 02 Dec 2013 03:18:12 +0000
Subject: [issue17909] Autodetecting JSON encoding
In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za>
Message-ID: <1385954292.12.0.0223060694228.issue17909@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/issue17909>
_______________________________________

From report at bugs.python.org  Mon Dec  2 04:23:35 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Dec 2013 03:23:35 +0000
Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1385954615.13.0.859172783967.issue16074@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
title: bad error message in os.rename -> Bad error message in os.rename, os.link, and os.symlink

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

From report at bugs.python.org  Mon Dec  2 05:02:26 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 Dec 2013 04:02:26 +0000
Subject: [issue15798] subprocess.Popen() fails if 0,
 1 or 2 descriptor is closed
In-Reply-To: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>
Message-ID: <1385956946.01.0.996068172899.issue15798@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

i went with the less invasive in terms of behavior change approach of making sure that the errpipe_write fd is always >= 3.  In Python 3.4 the code change was different and much simpler and on the Python only side as all fd's are opened O_CLOEXEC by default.

I'm not entirely sure why the test_multiprocessing_forkserver and test_multiprocessing_spawn failures happened on 3.4 with the earlier change that attempted to always list 0,1,2 in the fds_to_keep (derived from pass_fds) list so there _may_ be a bug lurking elsewhere there but I suspect the bug is actually that we don't always want to blindly list them in fds_to_keep as some programs may have reused some of them for other non-stdio purposes but still want them closed.

The change has been backported to the python-subprocess32 repo.

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

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

From report at bugs.python.org  Mon Dec  2 05:11:55 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Dec 2013 04:11:55 +0000
Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1385957515.81.0.828199146021.issue16074@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch for Python 3.4. It removed file information for os.rename, os.link, and os.symlink.

I agree with Ezio that giving extra information is better but since Python 3.4 is in beta.... maybe we can defer this to Python 3.5.

There are couples of errno that need extra information. For example, in Linux:
[Errno 2] No such file or directory -> source
[Errno 17] File exists -> destination
[Errno 36] Filename too long -> tough to decide, can be source, can be destination
[Errno 27] File too large -> source
Anything left?

----------
nosy: +vajrasky
Added file: http://bugs.python.org/file32934/better_error_message_in_os_rename_link_symlink.patch

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

From report at bugs.python.org  Mon Dec  2 05:33:47 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Dec 2013 04:33:47 +0000
Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1385958827.48.0.855097287626.issue16074@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Patch for Python 3.3. It omitted file information for error messages in rename, symlink, and link.

I'll create a separate ticket for adding extra file information to these error messages.

----------
Added file: http://bugs.python.org/file32935/better_error_message_in_os_rename_link_symlink_for_python_33.patch

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

From report at bugs.python.org  Mon Dec  2 10:33:36 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Dec 2013 09:33:36 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1385976816.49.0.738122817405.issue19828@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Yeah, but...

$ ./python -S Lib/test
== CPython 3.4.0b1 (default:373797990f57, Dec 2 2013, 16:46:35) [GCC 4.7.2]
==   Linux-3.5.0-37-generic-x86_64-with-debian-wheezy-sid little-endian
==   hash algorithm: siphash24 64bit
==   /home/ethan/Documents/code/python/cpython3.4/build/test_python_28533
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=1, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[  1/387] test_grammar
[  2/387] test_opcodes
[  3/387] test_dict
...
[385/387/2] test_zipimport
[386/387/2] test_zipimport_support
[387/387/2] test_zlib
361 tests OK.
2 tests failed:
    test_site test_trace
2 tests altered the execution environment:
    test_idle test_importlib
22 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_devpoll
    test_gdb test_kqueue test_msilib test_ossaudiodev test_smtpnet
    test_socketserver test_startfile test_timeout test_tk
    test_ttk_guionly test_urllibnet test_winreg test_winsound
    test_xmlrpc_net test_zipfile64

Feel free to close this as wontfix. This issue is not a life and death situation anyway. :)

----------

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

From report at bugs.python.org  Mon Dec  2 10:39:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 02 Dec 2013 09:39:08 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1385977148.12.0.964210820644.issue19828@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Sorry to forget to add the relevant detail:

$ ./python -S Lib/test
....
[284/387] test_shutil
[285/387] test_signal
[286/387] test_site
test test_site failed -- multiple errors occurred; run in verbose mode for details
[287/387/1] test_slice
[288/387/1] test_smtpd
[289/387/1] test_smtplib
....

----------

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

From report at bugs.python.org  Mon Dec  2 11:27:47 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Mon, 02 Dec 2013 10:27:47 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
Message-ID: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>


New submission from Radomir Dopieralski:

As most na?ve "memoized" decorator implementations, lru_cache keeps references to all the values of arguments of the decorated function in the cache. That means, that if we call such a decorated function with an object as a parameter, that object will be kept alive in memory forever -- that is, until the program ends. This is an obvious waste, since when we no longer have any other reference to that object, we are unable to call that function with the same parameter ever again, so it just wastes the cache space.

This is a very common case when we decorate a method -- the first parameter is "self". One solution for this particular case is to use a dedicated "memoized_method" decorator, that stores the cache on the "self" object itself, so that it can be released together with the object.

A more general solution uses weakrefs where possible in the cache key, maybe even with an additional callback that removes the cache entry when any of its parameters is dead. Obviously it adds some overhead and makes the caching decorator even slower, but it can let us save a lot of memory, especially in long-running applications.

To better illustrate what I mean, here is an example of such an improved @memoized decorator that I wrote: https://review.openstack.org/#/c/54117/5/horizon/utils/memoized.py

It would be great to have an option to do something similar with lru_cache, and if there is an interest, I would like to work on that.

----------
components: Library (Lib)
messages: 204995
nosy: thesheep
priority: normal
severity: normal
status: open
title: functools.lru_cache keeps objects alive forever
type: resource usage
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/issue19859>
_______________________________________

From report at bugs.python.org  Mon Dec  2 11:44:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 10:44:22 +0000
Subject: [issue19834] Unpickling exceptions pickled by Python 2
In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za>
Message-ID: <3dY2xx4v3QzSyK@mail.python.org>


Roundup Robot added the comment:

New changeset 7d3297f127ae by Walter Doerwald in branch '3.3':
Fix issue #19834: Support unpickling of exceptions pickled by Python 2.
http://hg.python.org/cpython/rev/7d3297f127ae

New changeset 9685c9d1d67f by Walter Doerwald in branch 'default':
Fix #19834: merge with 3.3.
http://hg.python.org/cpython/rev/9685c9d1d67f

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

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

From report at bugs.python.org  Mon Dec  2 11:46:06 2013
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 02 Dec 2013 10:46:06 +0000
Subject: [issue19834] Unpickling exceptions pickled by Python 2
In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za>
Message-ID: <1385981166.69.0.491190935273.issue19834@psf.upfronthosting.co.za>


Changes by Walter D?rwald <walter at livinglogic.de>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Mon Dec  2 12:07:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:07:10 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1385982430.04.0.220107021652.issue19850@psf.upfronthosting.co.za>


STINNER Victor added the comment:

asyncio_sa_restart.diff looks good to me, it cannot make the situation worse.

signal.siginterrupt() looks to be available on all non-Windows buildbots and working correctly: test_signal tests it and the test pass.

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Dec  2 12:08:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:08:48 +0000
Subject: [issue16404] Uses of PyLong_FromLong that don't check for errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1385982528.72.0.572798632896.issue16404@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/issue16404>
_______________________________________

From report at bugs.python.org  Mon Dec  2 12:14:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:14:54 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385982894.09.0.140392910897.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"sys.getfilesystemencoding() says for Unix: On Unix, the encoding is the user?s preference according to the result of nl_langinfo(CODESET), or 'utf-8' if nl_langinfo(CODESET) failed."

Oh, this documentation is wrong since at least Python 3.2: if nl_langinfo(CODESET) fails, Python exits immediatly with a (fatal) error.

There is no (more?) such fallback to "utf-8".

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Dec  2 12:18:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 11:18:04 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <3dY3hq3MD6z7LrB@mail.python.org>


Roundup Robot added the comment:

New changeset b231e0c3fd26 by Victor Stinner in branch '3.3':
Issue #19728: Fix sys.getfilesystemencoding() documentation
http://hg.python.org/cpython/rev/b231e0c3fd26

New changeset e3c48bddf621 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #19728: Fix sys.getfilesystemencoding() documentation
http://hg.python.org/cpython/rev/e3c48bddf621

----------

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

From report at bugs.python.org  Mon Dec  2 12:18:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:18:32 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385983112.0.0.768072005977.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I fixed the documentation, thanks for your report!

----------
assignee:  -> docs at python
components: +Documentation -IO
nosy: +docs at python
resolution:  -> fixed
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Mon Dec  2 12:19:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:19:53 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385983193.03.0.350511467508.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Code in Python 3.4.

initfsencoding():
http://hg.python.org/cpython/file/e3c48bddf621/Python/pythonrun.c#l965

get_locale_encoding():
http://hg.python.org/cpython/file/e3c48bddf621/Python/pythonrun.c#l250

----------

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

From report at bugs.python.org  Mon Dec  2 12:28:38 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 02 Dec 2013 11:28:38 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385983718.92.0.36418796316.issue19847@psf.upfronthosting.co.za>


Sworddragon added the comment:

It is nice that you could fixed the documentation due to this report but this was just a sideeffect - so closing this report and moving it to "Documentation" was maybe wrong.

----------

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

From report at bugs.python.org  Mon Dec  2 12:42:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 11:42:12 +0000
Subject: [issue19833] asyncio: patches to document EventLoop and add more
 examples
In-Reply-To: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>
Message-ID: <3dY4Dg60y5z7Lsh@mail.python.org>


Roundup Robot added the comment:

New changeset 7b4d046dbf56 by Victor Stinner in branch 'default':
Issue #19833: asyncio doc: add class name to methods
http://hg.python.org/cpython/rev/7b4d046dbf56

New changeset b25458022965 by Victor Stinner in branch 'default':
Issue #19833: add 2 examples to asyncio doc (hello world)
http://hg.python.org/cpython/rev/b25458022965

New changeset 5e4ea92f9a9b by Victor Stinner in branch 'default':
Issue #19833: Document more asyncio.BaseEventLoop methods
http://hg.python.org/cpython/rev/5e4ea92f9a9b

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

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

From report at bugs.python.org  Mon Dec  2 12:45:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 11:45:59 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
Message-ID: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The BaseSelectorEventLoop class (inherited by UnixSelectorEventLoop) creates a socketpair in its constructor. So if you don't call close(), the socketpair may stay alive.

It would be convinient to support the context manager to be able to write:

with asyncio.get_event_loop() as loop
   # ... prepare loop ...
   loop.run_forever()
# KeyboardInterrupt or SystemExit: loop.close() is called

Hello World examples don't call close(), so the sockets are not closed when the example is stopped using CTRL+c.

Attached patch adds __enter__/__exit__ methods to BaseEventLoop and use it in the two Hello World examples.

----------
files: eventloop_context_manager.patch
keywords: patch
messages: 205004
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio: Add context manager to BaseEventLoop?
versions: Python 3.4
Added file: http://bugs.python.org/file32936/eventloop_context_manager.patch

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

From report at bugs.python.org  Mon Dec  2 13:23:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 12:23:02 +0000
Subject: [issue19861] Update What's New for Python 3.4
Message-ID: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Many features and changes were not mentioned in What's New (especially added early). Here is main features which possible worth to mention:

abc:  The ABC class, the get_cache_token function.

aifc:  Any bytes-like objects are now accepted.

audioop:  Any bytes-like objects are now accepted.  Strings no more supported.

base64:  ascii85/base85 codecs.

bz2:  The 'x' mode.

codecs:  The cp1125 encoding.

collections:  New optional parameter in ChainMap.new_child().

dbm:  Support for the context management protocol.

dis:  Added the file parameter to many functions. Added the stack_effect() 
function.

email:  The policy keyword argument was added in email.message.Message 
constructor. The replace keyword argument was added in the set_param() 
method. 
The EmailPolicy.content_manager attribute was added 

filecmp:  Added the clear_cache() function and the dircmp.DEFAULT_IGNORES 
attribute.

functools:  total_ordering now supports the NotImplemented value.

gc:  Added the get_stats() function.

glob:  Added the escape() function.

gzip: The 'x' mode.

http:  HTTP 0.9-style "Simple Responses" are not supported. Added the explain 
argument in BaseHTTPRequestHandler.send_error(). Added the --bind option in 
the http.server module CLI.

ipaddress:  Added the IPv4Address.is_global attribute.

json:  Used ``(',', ': ')`` as default in dump() and dumps() if indent is not 
None. I.e. trailing spaces no more produced by default.

logging:  An instance of a subclass of RawConfigParser is now accepted as a 
value for fname in the fileConfig() function. The verify argument was added in 
the listen() function. The atTime parameter was added in 
TimedRotatingFileHandler constructor.  Added support of Unix domain sockets 
in SocketHandler and DatagramHandler.

lzma:  The 'x' mode.

multiprocessing:  Added following functions: get_all_start_methods(), 
get_context(), get_start_method(), and set_start_method(). set_executable() 
is now supported on Unix when the 'spawn' start method is used. Added the 
context parameter in Pool constructor.

operator:  Added the length_hint() function.

os.path:  samestat() now is supported on Windows.

os:  Add O_TMPFILE constant on Linux.

plistlib:  Added support for binary format. Added load(), loads(), dump(), and 
dumps() functions. Deprecated readPlist(), writePlist() readPlistFromBytes(), 
and writePlistToBytes() functions, the Data class.

select:  epoll() now supports the context management protocol. Added the 
close() and fileno() methods and the closed attribute in the devpoll class.

shelve:  Added context manager support.

shutil:  Added the SameFileError exception.

smtpd:  The map argument was added in SMTPServer constructor.

socket:  The CAN_BCM protocol was added. The AF_LINK family was added.

sqlite3:  Added support for URI.

subprocess: The input parameter was added in the check_output() function.

sunau:  Added support for 24-bit samples. Any bytes-like objects are now 
accepted.

sys:  Added the getallocatedblocks() function. Added the __interactivehook__ 
hook.

tarfile:  Added command-line interface.

textwrap:  Added support for truncating.

threading:  Added the main_thread() function.

unittest:  Added the TestCase.assertLogs() method. The TestSuite no more held 
references to each TestCase after TestSuite.run(). Modules that raise SkipTest 
on import are recorded as skips, not errors. Paths are sorted before being 
imported to ensure execution order for a given test suite is the same.

urllib:  Added the HTTPError.headers attribute. Added the Request.full_url 
attribute and the Request.remove_header() and Request.get_full_url() methods. 
Default Request.method may be indicated at the class level.

venv:  Added the ``with_pip`` parameter in EnvBuilder.

wave:  Any bytes-like objects are now accepted. Added support for unseekable 
files.

xml.etree.elementtree:  Added support to output empty elements in short form.

zipfile:  ZIP64 extensions are enabled by default.


Other enhancements:le.

memoryview is now registered automatically with collections.abc.Sequence.

Deprecations:

The 'U' mode in open() for file objects, in the fileinput and zipfile modules. A couple of plistlib functions. The html argument of XMLParser() and the parser argument of iterparse() in the xml.etree.elementtree module.

----------
assignee: docs at python
components: Documentation
messages: 205005
nosy: docs at python, larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: Update What's New for Python 3.4
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Dec  2 13:24:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 12:24:26 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385987066.37.0.6943147287.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Oops, I specified the wrong issue number in my commits.)

New changeset b231e0c3fd26 by Victor Stinner in branch '3.3':
Issue #19728: Fix sys.getfilesystemencoding() documentation
http://hg.python.org/cpython/rev/b231e0c3fd26

New changeset e3c48bddf621 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #19728: Fix sys.getfilesystemencoding() documentation
http://hg.python.org/cpython/rev/e3c48bddf621

----------

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

From report at bugs.python.org  Mon Dec  2 13:24:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 12:24:35 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <1385987075.96.0.23574193647.issue19728@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


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

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

From report at bugs.python.org  Mon Dec  2 13:32:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 12:32:49 +0000
Subject: [issue18073] pickle.Unpickler may read too many bytes,
 causing hangs with blocking input stream
In-Reply-To: <1369677881.19.0.98233808248.issue18073@psf.upfronthosting.co.za>
Message-ID: <1385987569.73.0.764218332301.issue18073@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If issue17897 fixes this bug (I'm not absolutely sure), perhaps it should be backported to 3.3.

----------

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

From report at bugs.python.org  Mon Dec  2 13:34:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 12:34:18 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1385987658.05.0.749644891742.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"It is nice that you could fixed the documentation due to this report but this was just a sideeffect - so closing this report and moving it to "Documentation" was maybe wrong."

Oh sorry, I read the issue too quickly, I stopped at the first sentence. I reopen the issue the reply to the other points.


"In my opinion relying on the locale environment is risky since filesystem-encoding != locale. This is especially the case if working on a filesystem from an external media like an external hard disk drive. Operating on multiple media can also result in different filesystem-encodings."

This issue is not specific to Python. If you mount an USB key formated in VFAT with the wrong encoding on Linux, you will get mojibake in your file explorer. Same issue if you connect a network share (ex: NFS) using a different encoding than the server. You can find many other examples (hint: Mac OS X and Unicode normalization).

There is no good compromise here. The only two safe options are:

(A) convert filenames of your filesystem to the same encoding than your computer (there are tools for that, like convmv)

(B) use raw bytes instead of Unicode, Python 3 should accept bytes anywhere that OS data is expected (filenames, command line arguments, environment variables)

All operating systems (except Windows) are now using UTF-8 by default for the locale encoding. So slowly, mojibake issues on filename should become very rare.


"It would be useful if the user can make his own checks and change the default filesystem-encoding if needed."

This idea was already proposed in issue #8622, but it was a big fail. Please read my following email for more information:
https://mail.python.org/pipermail/python-dev/2010-October/104509.html

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

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

From report at bugs.python.org  Mon Dec  2 14:07:32 2013
From: report at bugs.python.org (era)
Date: Mon, 02 Dec 2013 13:07:32 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1385989652.66.0.810468267251.issue17305@psf.upfronthosting.co.za>


era added the comment:

At least the following existing domain names are rejected by the current implementation, apparently because they are not IDNA2003-compatible.

XN----NNC9BXA1KSA.COM
XN--14-CUD4D3A.COM
XN--YGB4AR5HPA.COM
XN---14-00E9E9A.COM
XN--MGB2DAM4BK.COM
XN--6-ZHCPPA1B7A.COM
XN--3-YMCCH8IVAY.COM
XN--3-YMCLXLE2A3F.COM
XN--4-ZHCJXA0E.COM
XN--014-QQEUW.COM
XN--118-Y2EK60DC2ZB.COM

As a workaround, in the code where I needed to process these, I used a fallback to string[4:].decode('punycode'); this was in a code path where I had already lowercased the string and established that string[0:4] == 'xn--'.

As a partial remedy, supporting a relaxed interpretation of the spec somehow would be useful; see also (tangentially) issue #12263.

----------
nosy: +era

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

From report at bugs.python.org  Mon Dec  2 14:50:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 13:50:50 +0000
Subject: [issue19814] Document prefix matching behavior of argparse,
 particularly for parse_known_args
In-Reply-To: <1385561761.38.0.108882000791.issue19814@psf.upfronthosting.co.za>
Message-ID: <3dY75618tgz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset c457bd1935f9 by Eli Bendersky in branch '3.3':
Issue #19814: Clarify argparse's docs w.r.t prefix matching
http://hg.python.org/cpython/rev/c457bd1935f9

New changeset 46976bd44bfc by Eli Bendersky in branch 'default':
Issue #19814: Clarify argparse's docs w.r.t prefix matching
http://hg.python.org/cpython/rev/46976bd44bfc

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

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

From report at bugs.python.org  Mon Dec  2 14:53:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 13:53:36 +0000
Subject: [issue19814] Document prefix matching behavior of argparse,
 particularly for parse_known_args
In-Reply-To: <1385561761.38.0.108882000791.issue19814@psf.upfronthosting.co.za>
Message-ID: <3dY78H47KCz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 181ced5bf0be by Eli Bendersky in branch '2.7':
Issue #19814: Clarify argparse's docs w.r.t prefix matching
http://hg.python.org/cpython/rev/181ced5bf0be

----------

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

From report at bugs.python.org  Mon Dec  2 14:53:52 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 02 Dec 2013 13:53:52 +0000
Subject: [issue19814] Document prefix matching behavior of argparse,
 particularly for parse_known_args
In-Reply-To: <1385561761.38.0.108882000791.issue19814@psf.upfronthosting.co.za>
Message-ID: <1385992432.03.0.129416902431.issue19814@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Mon Dec  2 14:56:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 13:56:03 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1385992563.47.0.433464049701.issue14455@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These changes are worth to mention in What's News.

"versionchanged" below writePlistToBytes() is wrong. Perhaps below dump() too. "versionadded" is needed for new functions: dump(), dumps(), load(), loads().

----------

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

From report at bugs.python.org  Mon Dec  2 15:11:53 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 02 Dec 2013 14:11:53 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1385993513.13.0.36769317594.issue7105@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Yes, the old memory argument.
But is it valid? Is there a conceivable application where a dict of weak references would be storing a large chunk of the application memory?
Remember, all of the data must be referred to from elsewhere, or else, the weak refs would not exist.  An extra list of pointers is unlikely to make a difference.
I think the chief reason to use iterators has to do with performance by avoiding the creation of temporary objects, not saving memory per-se.

Before the invention of "iteritems()" and friends, all such iteration was by lists (and hence, memory usage).  We should try to remain nimble enough so that we can undo an optimization previously done, if the requirements merit us doing so.

As a completely unrelated example of such nimbleness:  Faced with stricter regulations in the 70s, american car makers had to sell their muscle cars with increasingly less powerful engines, efectively rolling back previous optimizations :)

Anyway, it's not for me to decide.  We have currently three options:
a) my first patch, which is a duplication of the 3.x work but is non-trivial and could bring stability issues
b) my second patch, which will increase memory use, but to no more than previous versions of python used while iterating
c) do nothing and have iterations over weak dicts randomly break when an underlying cycle is unraveled during iteration.

Cheers!

----------

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

From report at bugs.python.org  Mon Dec  2 15:30:24 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 14:30:24 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1385993513.13.0.36769317594.issue7105@psf.upfronthosting.co.za>
Message-ID: <1385994621.2301.0.camel@fsol>


Antoine Pitrou added the comment:

> Anyway, it's not for me to decide.  We have currently three options:
> a) my first patch, which is a duplication of the 3.x work but is
> non-trivial and could bring stability issues
> b) my second patch, which will increase memory use, but to no more
> than previous versions of python used while iterating
> c) do nothing and have iterations over weak dicts randomly break when
> an underlying cycle is unraveled during iteration.

Either a) or c), for me. We shouldn't change semantics in bugfix
releases.

----------

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

From report at bugs.python.org  Mon Dec  2 15:49:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2013 14:49:31 +0000
Subject: [issue19781] No SSL match_hostname() in ftplib
In-Reply-To: <1385423063.98.0.532680357118.issue19781@psf.upfronthosting.co.za>
Message-ID: <1385995771.0.0.00866017489147.issue19781@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Mon Dec  2 16:18:46 2013
From: report at bugs.python.org (=?utf-8?b?0JLQsNC70LXRgNC40Lk=?=)
Date: Mon, 02 Dec 2013 15:18:46 +0000
Subject: [issue19862] Unclear xpath caching for custom  namespaces
Message-ID: <1385997526.09.0.197144583843.issue19862@psf.upfronthosting.co.za>


New submission from ???????:

Consider repeated executions of a code like this:
>tree = xml.etree.ElementTree.parse( full_name ) # many different files
>report_type = tree.getroot().attrib['Name'] # something changing
>tree.getroot().find( ".//t:Detail", {'t' : report_type} )

There is a _cache variable in \Lib\xml\etree\ElementPath.py:
>def iterfind(elem, path, namespaces=None):
>    // ...
>    try:
>        selector = _cache[path]
>    except KeyError:
>    // ...

In my code I use the same path (".//t:Detail"), so no KeyError exception is raised and cached (the same) value is used, but full path should be different ('.//{url_one}Detail', './/{url_two}Detail', etc) depending on namespaces dictionary.

----------
components: XML
messages: 205015
nosy: valeriy.nov
priority: normal
severity: normal
status: open
title: Unclear xpath caching for custom  namespaces
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Dec  2 16:18:59 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 02 Dec 2013 15:18:59 +0000
Subject: [issue19707] Check if unittest.mock needs updating for PEP 451
In-Reply-To: <1385934208.56.0.732647798541.issue19707@psf.upfronthosting.co.za>
Message-ID: <1385997539.95.0.246237917506.issue19707@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Based on what Michael said there is nothing to update.

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

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

From report at bugs.python.org  Mon Dec  2 16:29:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 15:29:40 +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: <1385998180.49.0.0833634649071.issue9856@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps the versionchanged tag for format() is more suitable than versionadded.

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

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

From report at bugs.python.org  Mon Dec  2 16:38:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 15:38:00 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1385998680.18.0.432549761374.issue14455@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Currently negative integers are not supported in binary format. Here is a patch which adds support for negative integers and large integers up to 128 bit.

----------
Added file: http://bugs.python.org/file32937/plistlib_int.patch

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

From report at bugs.python.org  Mon Dec  2 16:41:01 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 15:41:01 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1385998861.52.0.898919888033.issue7105@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm with Antoine.  Have we heard of any problems with the 3.x version of the patch?  How different is it?

----------

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

From report at bugs.python.org  Mon Dec  2 16:53:11 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 15:53:11 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1385999591.81.0.284412493605.issue19860@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Isn't this mostly political correctness? The hello world programs really don't need to worry about closing the socket pair. Most real-world programs don't either -- the recommended pattern is just to loop until the end of the world, and then exit the program.

I'd like to counter with some political correctness of my own -- this smells like a new feature and therefore shouldn't be added to 3.4.  (Adding Larry -- if Larry is fine with making small additions to asyncio during the beta, I am also okay with adding this.)

----------
nosy: +larry

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

From report at bugs.python.org  Mon Dec  2 16:58:02 2013
From: report at bugs.python.org (Martijn Faassen)
Date: Mon, 02 Dec 2013 15:58:02 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1385999882.4.0.920055878604.issue14787@psf.upfronthosting.co.za>


Martijn Faassen added the comment:

I just ran into this bug myself with namespace packages (in Python 2.7). When you have multiple packages (ns.a, ns.b) under a namespace package (ns), and constrain the paths in walk_packages so it should only pick up ns.a, it will pick up ns.b as well.

Any hope for a fix or workaround?

----------
nosy: +faassen

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

From report at bugs.python.org  Mon Dec  2 16:59:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 15:59:47 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1385999987.78.0.1050669401.issue19860@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

There's another problem: get_event_loop() returns a persistent object, not a new instance every time. So you can't write:

  with get_event_loop() as loop:
      # ...

twice in a row if the loop is closed at the end of the "with" block.

----------

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

From report at bugs.python.org  Mon Dec  2 17:19:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 16:19:03 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1386001143.57.0.27841140077.issue19837@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Changing return type based on argument *values* is still a bad idea in
> general.

However load() and loads() do this. ;)

> It also makes it hard to plug the API in to generic code that is designed
> to work with any dump/load based serialisation protocol.

For dumps() it will be simple -- `lambda x: json.dumps(x, encoding='utf-8')`. For loads() it will be even simpler -- loads() will accept both strings and bytes.

Note that dumps() with the encoding parameter will be more 2.x compatible than current implementation. This will help in writing compatible code.

----------

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

From report at bugs.python.org  Mon Dec  2 17:19:04 2013
From: report at bugs.python.org (Tom Tromey)
Date: Mon, 02 Dec 2013 16:19:04 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1386001144.01.0.624868421773.issue11410@psf.upfronthosting.co.za>


Changes by Tom Tromey <tromey at redhat.com>:


----------
nosy: +tromey

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

From report at bugs.python.org  Mon Dec  2 17:21:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 16:21:29 +0000
Subject: [issue19834] Unpickling exceptions pickled by Python 2
In-Reply-To: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za>
Message-ID: <3dYBQx136kz7LmG@mail.python.org>


Roundup Robot added the comment:

New changeset a270370ec487 by Walter Doerwald in branch '3.3':
Add NEWS entry for issue #19834.
http://hg.python.org/cpython/rev/a270370ec487

New changeset ef6ad7172d50 by Walter Doerwald in branch 'default':
Add NEWS entry for issue #19834: merge with 3.3.
http://hg.python.org/cpython/rev/ef6ad7172d50

----------

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

From report at bugs.python.org  Mon Dec  2 17:22:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 16:22:08 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1386001328.34.0.121627534565.issue19860@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"There's another problem: get_event_loop() returns a persistent object, not a new instance every time."

Oh, I didn't know that, but it makes sense. It should be documented.

It is possible to create a second event loop, only used to execute a short one-shot task? I don't see how to instanciate a second event loop.

----------

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

From report at bugs.python.org  Mon Dec  2 17:27:19 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 02 Dec 2013 16:27:19 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1386001639.53.0.990570772411.issue14455@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

oops... thanks for the patch. I'll review later this week, in particular the 128 bit integer support because I don't know if Apple's libraries support those.

----------

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

From report at bugs.python.org  Mon Dec  2 17:47:41 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 16:47:41 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1386002861.17.0.382479151286.issue19860@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

To create a new event loop, use set_event_loop(new_event_loop()).  You have to do that if you want an event loop in a thread; it's also handy in unit tests.  (However asyncio's own unit tests only call new_event_loop() and pass it around explicitly with loop=...; they set the default event loop to None with set_event_loop(None).)

Creating a second event loop (in the same thread) while you already have an event loop is fraught with problems -- while the second one is running any events associated with the first one won't fire.

(This API is not random -- it is intentionally restricted to allow certain platform event loops to be adapted.)

----------

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

From report at bugs.python.org  Mon Dec  2 17:54:27 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 16:54:27 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1386003267.18.0.726296933745.issue19850@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I have a question. Is there actually any need for this with asyncio? The selector already handles EINTR, and all the I/O done by asyncio's transports already handles it too (there are "except (BlockingIOError, InterruptedError)" clauses all over the place).

Any *other* I/O syscalls (unless a program violates the asyncio rules against doing your own blocking I/O) would either be disk file I/O, which IIUC cannot elicit EINTR, or run in a separate thread, where presumably it wouldn't be interrupted by a signal handler, since SIGCHLD is delivered to the main thread.  (It's actually the last part I am not 100% sure of.)

----------

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

From report at bugs.python.org  Mon Dec  2 17:58:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 16:58:13 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1386003267.18.0.726296933745.issue19850@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaKhVsBo_j59qUxFTSOwVZmk_VA8+oVhDNg_AWfvMS3Dw@mail.gmail.com>


STINNER Victor added the comment:

> I have a question. Is there actually any need for this with asyncio?

I believe that the libc and the kernel knows better than Python how to
restart a syscalls, than Python. I expect more reliable timeout, or
the kernel may avoid context switches (don't wake up the process).

In practice, you should not see any difference. Or maybe only on some
corner cases. But do you want to handle these corner cases while there
is already a portable flag for them? :-)

----------

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

From report at bugs.python.org  Mon Dec  2 17:59:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Dec 2013 16:59:26 +0000
Subject: [issue19833] asyncio: patches to document EventLoop and add more
 examples
In-Reply-To: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>
Message-ID: <1386003566.26.0.848155500307.issue19833@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I documented many new classes. I read the source code and copied classes to extract docstrings.

Instead of BaseXXX classes, it's maybe better to document AbstractXXX classes.

----------

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

From report at bugs.python.org  Mon Dec  2 18:04:17 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 17:04:17 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1386003857.64.0.559906602661.issue19850@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

That's just rhetoric -- I am beginning to believe that nobody has any data.  Here's some opposite rhetoric.  If it ain't broke, don't fix it.  Plus, if it's so much better, why isn't it the default?  If you say "for backward compatibility" I will say "exactly!"

----------

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

From report at bugs.python.org  Mon Dec  2 18:05:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 17:05:40 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386003940.48.0.863443757354.issue19858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I afraid this is not a feature, but a bug. pickletools.optimize() can produce invalid pickled data when *PUT and MEMOIZE opcodes are used.

>>> import pickle, pickletools
>>> p = b'\x80\x04]\x94(\x8c\x04spamq\x01\x8c\x03ham\x94h\x02e.'
>>> pickle.loads(p)
['spam', 'ham', 'ham']
>>> pickletools.dis(p)
    0: \x80 PROTO      4
    2: ]    EMPTY_LIST
    3: \x94 MEMOIZE
    4: (    MARK
    5: \x8c     SHORT_BINUNICODE 'spam'
   11: q        BINPUT     1
   13: \x8c     SHORT_BINUNICODE 'ham'
   18: \x94     MEMOIZE
   19: h        BINGET     2
   21: e        APPENDS    (MARK at 4)
   22: .    STOP
highest protocol among opcodes = 4
>>> p2 = pickletools.optimize(p)
>>> p2
b'\x80\x04\x95\x13\x00\x00\x00\x00\x00\x00\x00]\x94(\x8c\x04spam\x8c\x03ham\x94h\x02e.'
>>> pickle.loads(p2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 2
>>> pickletools.dis(p2)
    0: \x80 PROTO      4
    2: \x95 FRAME      19
   11: ]    EMPTY_LIST
   12: \x94 MEMOIZE
   13: (    MARK
   14: \x8c     SHORT_BINUNICODE 'spam'
   20: \x8c     SHORT_BINUNICODE 'ham'
   25: \x94     MEMOIZE
   26: h        BINGET     2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pickletools.py", line 2458, in dis
    raise ValueError(errormsg)
ValueError: memo key 2 has never been stored into

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

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

From report at bugs.python.org  Mon Dec  2 18:12:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 17:12:09 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1386004328.98.0.632511336562.issue14455@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

According to [1] Apple's libraries write any signed 128-bit integers, but read only integers from -2**63 to 2**64-1 (e.g. signed and unsigned 64-bit integers).

[1] http://opensource.apple.com/source/CF/CF-550/CFBinaryPList.c

----------

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

From report at bugs.python.org  Mon Dec  2 18:14:07 2013
From: report at bugs.python.org (Marten Lehmann)
Date: Mon, 02 Dec 2013 17:14:07 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1386004447.69.0.0766508132176.issue17305@psf.upfronthosting.co.za>


Marten Lehmann added the comment:

There's nice library called idna on PyPI doing idna2008: https://pypi.python.org/pypi/idna/0.1

I'd however prefer this standard encoding to be part of standard python.

----------

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

From report at bugs.python.org  Mon Dec  2 18:17:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 17:17:10 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1386004630.45.0.629475073407.issue14455@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one nitpick. Perhaps _write_object() should raise TypeError instead of InvalidFileException.

----------

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

From report at bugs.python.org  Mon Dec  2 19:13:37 2013
From: report at bugs.python.org (HCT)
Date: Mon, 02 Dec 2013 18:13:37 +0000
Subject: [issue19803] memoryview complain ctypes byte array are not native
 single character
In-Reply-To: <1385499249.85.0.446556603594.issue19803@psf.upfronthosting.co.za>
Message-ID: <1386008017.04.0.491940683133.issue19803@psf.upfronthosting.co.za>


HCT added the comment:

I wonder why "_pack_ = 1" has significant impact on the behaviour of memoryview if memoryview is not a sub class of ctypes structure. unless memoryview was specifically coded to understand ctypes structure, I don't see why "_pack_ = 1" should make any difference.

----------

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

From report at bugs.python.org  Mon Dec  2 19:33:54 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 02 Dec 2013 18:33:54 +0000
Subject: [issue19803] memoryview complain ctypes byte array are not native
 single character
In-Reply-To: <1386008017.04.0.491940683133.issue19803@psf.upfronthosting.co.za>
Message-ID: <20131202183353.GA6479@sleipnir.bytereef.org>


Stefan Krah added the comment:

Memoryview sends a *request* to ctypes to fill in a Py_buffer struct according
to the buffer *protocol*.  IOW, memoryview knows nothing about ctypes.

For some reason ctypes fills in 'B' as the format if _pack_ is set.  I do not
know if that is intended, it could be a ctypes issue.

----------

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

From report at bugs.python.org  Mon Dec  2 19:57:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 18:57:33 +0000
Subject: [issue19862] Unclear xpath caching for custom  namespaces
In-Reply-To: <1385997526.09.0.197144583843.issue19862@psf.upfronthosting.co.za>
Message-ID: <1386010653.83.0.213318248161.issue19862@psf.upfronthosting.co.za>


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


----------
nosy: +eli.bendersky, scoder

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

From report at bugs.python.org  Mon Dec  2 19:57:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 18:57:53 +0000
Subject: [issue19863] Missing function attributes in 2.7 docs.
Message-ID: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The attached patch fills in some missing function attributes from the Python 2.7 datamodel docs.

----------
assignee: docs at python
components: Documentation
files: missing_function_attributes.patch
keywords: patch
messages: 205038
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Missing function attributes in 2.7 docs.
versions: Python 2.7
Added file: http://bugs.python.org/file32938/missing_function_attributes.patch

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

From report at bugs.python.org  Mon Dec  2 19:58:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 18:58:32 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386010712.02.0.4821353428.issue19859@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Dec  2 20:00:54 2013
From: report at bugs.python.org (Max Polk)
Date: Mon, 02 Dec 2013 19:00:54 +0000
Subject: [issue19864] multiprocessing Proxy docs need locking semantics
 explained
Message-ID: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>


New submission from Max Polk:

In the docs (both Python 2 and 3) for the multiprocessing module, the Proxy section needs to be explicit about the fact that is does NOT create locks around access to shared objects.

Why?  Because on the same page, we read about multiprocessing.managers.SyncManager's Queue method to create a shared queue.Queue object and return a proxy for it, next to other methods like SyncManager.list to create a "process safe" list.

But later, a willful violation of these semantics exists in the "Using a remote manager" section where a Proxy is implicitly created (via the register method of multiprocessing.managers.BaseManager) surrounding a Queue.Queue object.

Note that it did not create a proxy around a SyncManager.Queue, it created it around a Queue.Queue.  A user who copies this code and replaces Queue.Queue with a plain Python list gets the sense that all the needed locks will be created to protect the shared list.

However, due to lack of documentation in the Proxy section, the user will not know it's an unsafe list, and Proxy isn't helping them.  I'm guessing that Queue.Queue has its own locks to protect it in a process-shared setting, and we "lucked out" in this example, but an unwary reader's luck runs out if they replace it with a plain Python list.

Therefore, may I suggest two changes: (1) replace Queue.Queue with SyncManager.Queue in the "Using a remote manager" section to avoid misleading readers; and (2) be explicit in Proxy class docs that "no locks are created" to protect against concurrent access, and maybe add that the user must go to the multiprocessing.managers.SyncManager methods (Queue, list, etc) to get "process safe" objects to place behind the Proxy.

----------
assignee: docs at python
components: Documentation
messages: 205039
nosy: docs at python, maxpolk
priority: normal
severity: normal
status: open
title: multiprocessing Proxy docs need locking semantics explained

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

From report at bugs.python.org  Mon Dec  2 20:01:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 19:01:48 +0000
Subject: [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386010908.87.0.0078776145484.issue19863@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps aliases should be added in same cell as original names?

       +-----------------------+-------------------------------+-----------+
       | :attr:`func_code`,    | The code object representing  | Writable  |
       | :attr:`__code__`      | the compiled function body.   |           |
       +-----------------------+-------------------------------+-----------+

Or add new "Alias" column?

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

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

From report at bugs.python.org  Mon Dec  2 20:02:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 19:02:17 +0000
Subject: [issue19782] No SSL match_hostname() in imaplib
In-Reply-To: <1385423128.55.0.373615853043.issue19782@psf.upfronthosting.co.za>
Message-ID: <3dYG0S0b7Jz7Lkv@mail.python.org>


Roundup Robot added the comment:

New changeset 23001d915b39 by Christian Heimes in branch 'default':
Issue #19782: imaplib now supports SSLContext.check_hostname and server name
http://hg.python.org/cpython/rev/23001d915b39

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

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

From report at bugs.python.org  Mon Dec  2 20:02:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2013 19:02:42 +0000
Subject: [issue19782] No SSL match_hostname() in imaplib
In-Reply-To: <1385423128.55.0.373615853043.issue19782@psf.upfronthosting.co.za>
Message-ID: <1386010962.87.0.065082074251.issue19782@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Mon Dec  2 20:11:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 19:11:01 +0000
Subject: [issue19784] No SSL match_hostname() in poplib
In-Reply-To: <1385423247.18.0.333542654641.issue19784@psf.upfronthosting.co.za>
Message-ID: <3dYGBW432jzSDW@mail.python.org>


Roundup Robot added the comment:

New changeset 1ce752754280 by Christian Heimes in branch 'default':
Issue #19784: poplib now supports SSLContext.check_hostname and server name
http://hg.python.org/cpython/rev/1ce752754280

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

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

From report at bugs.python.org  Mon Dec  2 20:11:45 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2013 19:11:45 +0000
Subject: [issue19784] No SSL match_hostname() in poplib
In-Reply-To: <1385423247.18.0.333542654641.issue19784@psf.upfronthosting.co.za>
Message-ID: <1386011505.86.0.650988401559.issue19784@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Mon Dec  2 20:20:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 19:20:20 +0000
Subject: [issue19783] No SSL match_hostname() in nntplib
In-Reply-To: <1385423208.98.0.59627306788.issue19783@psf.upfronthosting.co.za>
Message-ID: <3dYGPH4C0rz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset 42a6919ee7e5 by Christian Heimes in branch 'default':
Issue #19783: nntplib now supports SSLContext.check_hostname and server name
http://hg.python.org/cpython/rev/42a6919ee7e5

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

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

From report at bugs.python.org  Mon Dec  2 20:20:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2013 19:20:36 +0000
Subject: [issue19783] No SSL match_hostname() in nntplib
In-Reply-To: <1385423208.98.0.59627306788.issue19783@psf.upfronthosting.co.za>
Message-ID: <1386012036.17.0.571759666336.issue19783@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Mon Dec  2 20:23:55 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 19:23:55 +0000
Subject: [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386012235.09.0.747900385649.issue19863@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Perhaps aliases should be added in same cell as original names?

That sounds good to me.  Perhaps with a single explanatory line below the table to explain that the double-underscore variants were introduced for compatibility with Python 3.

----------

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

From report at bugs.python.org  Mon Dec  2 20:36:46 2013
From: report at bugs.python.org (=?utf-8?q?Gergely_Erd=C3=A9lyi?=)
Date: Mon, 02 Dec 2013 19:36:46 +0000
Subject: [issue19865] create_unicode_buffer() fails on non-BMP strings on
 Windows
Message-ID: <1386013006.0.0.412572088185.issue19865@psf.upfronthosting.co.za>


New submission from Gergely Erd?lyi:

create_unicode_buffer() fails on Windows if the initializer string contains unicode code points outside of the Basic Multilingual Plane and an explicit length is not specified.

The problem appears to be rooted in the fact that, since PEP 393, len() returns the number of code points, which does not always correspond to the number of 16-bit wchar words needed for the encoding on Windows. Because of that, the preallocated c_wchar buffer will be too short for the UTF-16 string.

The following small snippet demonstrates the problem:

from ctypes import create_unicode_buffer
b = create_unicode_buffer("\U00028318\U00028319")
print(b)

  File "c:\Python33\lib\ctypes\__init__.py", line 294, in create_unicode_buffer
    buf.value = init
ValueError: string too long

----------
components: ctypes
messages: 205045
nosy: gergely.erdelyi
priority: normal
severity: normal
status: open
title: create_unicode_buffer() fails on non-BMP strings on Windows
type: crash
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec  2 20:43:44 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Dec 2013 19:43:44 +0000
Subject: [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386013424.49.0.283427446468.issue19863@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file32939/missing_function_attributes_v2.patch

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

From report at bugs.python.org  Mon Dec  2 20:44:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 19:44:26 +0000
Subject: [issue19785] No SSL match_hostname() in smtplib
In-Reply-To: <1385423279.73.0.0929925715399.issue19785@psf.upfronthosting.co.za>
Message-ID: <3dYGx54s9Hz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset c0079358e791 by Christian Heimes in branch 'default':
Issue #19785: smtplib now supports SSLContext.check_hostname and server name
http://hg.python.org/cpython/rev/c0079358e791

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

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

From report at bugs.python.org  Mon Dec  2 20:45:11 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2013 19:45:11 +0000
Subject: [issue19785] No SSL match_hostname() in smtplib
In-Reply-To: <1385423279.73.0.0929925715399.issue19785@psf.upfronthosting.co.za>
Message-ID: <1386013511.71.0.0887564913884.issue19785@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


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

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

From report at bugs.python.org  Mon Dec  2 21:07:07 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Dec 2013 20:07:07 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1386014827.92.0.897593080077.issue19860@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Since this is a new library in 3.4, I can be more flexible.  And since you're talking about adding a new feature (rather than changing or removing an existing feature), this has a vanishingly small chance of screwing anything up.  Therefore I'm okay with adding this feature.

I suppose Python 3.4 only supports platforms that auto-close sockets at the end of a process, but I dimly recall Windows 95/98/ME didn't do that.  And there are crazy people porting to platforms like Amiga.  And I can hardly disapprove of something as wholesome as making sure people call .close().  So if Guido says okay, go ahead and check it in.

----------

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

From report at bugs.python.org  Mon Dec  2 21:13:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 20:13:13 +0000
Subject: [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1386015193.39.0.530867470344.issue19863@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then write the double-underscore variants at first place.

----------

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

From report at bugs.python.org  Mon Dec  2 21:14:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Dec 2013 20:14:41 +0000
Subject: [issue19865] create_unicode_buffer() fails on non-BMP strings on
 Windows
In-Reply-To: <1386013006.0.0.412572088185.issue19865@psf.upfronthosting.co.za>
Message-ID: <1386015281.5.0.779988845522.issue19865@psf.upfronthosting.co.za>


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


----------
type: crash -> behavior

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

From report at bugs.python.org  Mon Dec  2 21:18:56 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 20:18:56 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1386015536.91.0.716844095791.issue19860@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

But there is Antoine's point.  This makes

  with get_event_loop() as loop:
      <do stuff with loop>

an attractive nuisance if it's used in the wrong place.

----------

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

From report at bugs.python.org  Mon Dec  2 21:19:29 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 02 Dec 2013 20:19:29 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386015569.82.0.223987540114.issue19858@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Well, that can only happen if MEMOIZE and PUT are both used together, which won't happen with the Pickler classes we support. The easiest thing to do here is to disable pickletools.optimize on protocol 4.

----------

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

From report at bugs.python.org  Mon Dec  2 21:20:04 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 Dec 2013 20:20:04 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386015604.7.0.229499440903.issue19509@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have addressed the five libraries in five sub-issues. http.client and asyncio.selector_events need small adjustments to use the new feature. Please review the patch.

----------
nosy: +gvanrossum
Added file: http://bugs.python.org/file32940/check_hostname_adjustments.patch

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

From report at bugs.python.org  Mon Dec  2 21:23:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 20:23:41 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386015821.41.0.15483996791.issue19858@psf.upfronthosting.co.za>


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


----------
nosy: +tim.peters

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

From report at bugs.python.org  Mon Dec  2 21:25:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Dec 2013 20:25:25 +0000
Subject: [issue19852] Misplaced private API method in pathlib.py
In-Reply-To: <1385908619.09.0.979627399509.issue19852@psf.upfronthosting.co.za>
Message-ID: <3dYHrN2NvWz7LkC@mail.python.org>


Roundup Robot added the comment:

New changeset cd8230437f40 by Antoine Pitrou in branch 'default':
Issue #19852: move Path._raw_open() around, as it is now a private method.
http://hg.python.org/cpython/rev/cd8230437f40

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

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

From report at bugs.python.org  Mon Dec  2 21:26:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 20:26:09 +0000
Subject: [issue19852] Misplaced private API method in pathlib.py
In-Reply-To: <1385908619.09.0.979627399509.issue19852@psf.upfronthosting.co.za>
Message-ID: <1386015969.05.0.0415486449798.issue19852@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks! Patch now applied.

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

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

From report at bugs.python.org  Mon Dec  2 21:30:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 20:30:19 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386016219.84.0.215001276675.issue19858@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

By the way, I was curious if there were many users of pickletools.optimize(), so I did a search and most matches seem to be copies of the stdlib source tree:

http://code.ohloh.net/search?s=pickletools%20optimize&p=0&pp=0&fl=Python&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true

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

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

From report at bugs.python.org  Mon Dec  2 21:50:20 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Dec 2013 20:50:20 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1386017420.94.0.636898900127.issue19860@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Okay, yeah.  I assumed calling .close() was best practice.  If it's not, then...

Guido, since this is your library, I delegate the decision to you.  You guys can add this any time before I tag beta 2 if Guido's on board.

----------

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

From report at bugs.python.org  Mon Dec  2 22:46:16 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 Dec 2013 21:46:16 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <CAMpsgwaKhVsBo_j59qUxFTSOwVZmk_VA8+oVhDNg_AWfvMS3Dw@mail.gmail.com>
Message-ID: <CAGE7PNJs0T01BtKnpc5YNZVAd1ufBPy2EcK4hTdWkJyH+KLCBQ@mail.gmail.com>


Gregory P. Smith added the comment:

>
> I believe that the libc and the kernel knows better than Python how to
> restart a syscalls, than Python. I expect more reliable timeout, or
> the kernel may avoid context switches (don't wake up the process).
>

See the man page i linked to, calls like select and poll with timeouts are
not auto-restarted.

----------

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

From report at bugs.python.org  Mon Dec  2 22:49:42 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 02 Dec 2013 21:49:42 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386020982.3.0.960321395728.issue19847@psf.upfronthosting.co.za>


Sworddragon added the comment:

> This idea was already proposed in issue #8622, but it was a big fail.

Not completely: If your locale is utf-8 and you want to operate on an utf-8 filesystem all is fine. But what if you want then to operate on a ntfs (non-utf-8) partition? As I know there is no way to apply Python-environment variables on the fly with an effect to the interpreter. In my opinion this is the reason why a setter is needed here.

Otherwise the user has to go sure to use .encode() on all filesystem operations. Also he must ensure that .encode() doesn't throw any exception if the code must be robust. And with issue http://bugs.python.org/issue19846 this must likely be done with the content too. This will be really a hell in increasing the number of lines due to exception checking.

Is there a special reason that is against such a setter? The current advantage would be a huge increasing in maintainability of Python scripts who are relying on a high stability.

----------

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

From report at bugs.python.org  Mon Dec  2 22:54:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Dec 2013 21:54:00 +0000
Subject: [issue19864] multiprocessing Proxy docs need locking semantics
 explained
In-Reply-To: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>
Message-ID: <1386021240.84.0.0323635093482.issue19864@psf.upfronthosting.co.za>


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


----------
nosy: +sbt
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec  2 23:23:28 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 02 Dec 2013 22:23:28 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
Message-ID: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>


New submission from Francisco Mart?n Brugu?:

I've just installed Cpython 2.7.6 32bit on Windows64, run the tests [1]
and some of them failed. Some of them seems related to audiodata not beeing installed.

.\python.exe Lib\test\regrtest.py -v
== CPython 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] 
== Windows-7-6.1.7601-SP1 little-endian 
== c:\users\brugue\appdata\local\temp\test_python_1388 
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_aifc
...
======================================================================
ERROR: test_close (test.test_aifc.AifcPCM8Test)
----------------------------------------------------------------------
Traceback (most recent call last):
? File "D:\programs\Python27\lib\test\audiotests.py", line 148, in test_close
? ? with open(self.sndfilepath, 'rb') as testfile:
IOError: [Errno 2] No such file or directory: 'audiodata\\pluck-pcm8.aiff'
...
and more...
FAILED (errors=30)
...
test_sunau
======================================================================
ERROR: test_close (test.test_sunau.SunauPCM8Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\programs\Python27\lib\test\audiotests.py", line 148, in test_close
    with open(self.sndfilepath, 'rb') as testfile:
IOError: [Errno 2] No such file or directory: 'audiodata\\pluck-pcm8.au'
...
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3738>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3738>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3AA8>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3C60>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A4F3F58>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A481B98>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A481B98>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596CB0>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596FD0>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596918>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47F508>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A596918>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47FFA8>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47F508>> ignored
Exception AttributeError: "Au_read instance has no attribute '_file'" in <bound method Au_read.__del__ of <sunau.Au_read instance at 0x0A47F288>> ignored
test test_sunau failed -- multiple errors occurred
...
and more ...
...
FAILED (errors=25)
...
test_wave
...
======================================================================
ERROR: test_close (test.test_wave.WavePCM8Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\programs\Python27\lib\test\audiotests.py", line 148, in test_close
    with open(self.sndfilepath, 'rb') as testfile:
IOError: [Errno 2] No such file or directory: 'audiodata\\pluck-pcm8.wav'
...
FAILED (errors=20)
...
See attached files

----------
components: Windows
files: failed_test_aifc.txt
messages: 205059
nosy: francismb
priority: normal
severity: normal
status: open
title: tests aifc, sunau and wave failures on a fresh Win64 installation
versions: Python 2.7
Added file: http://bugs.python.org/file32941/failed_test_aifc.txt

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

From report at bugs.python.org  Mon Dec  2 23:23:47 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 02 Dec 2013 22:23:47 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>
Message-ID: <1386023027.91.0.730365193608.issue19866@psf.upfronthosting.co.za>


Changes by Francisco Mart?n Brugu? <francismb at email.de>:


Added file: http://bugs.python.org/file32942/failed_test_sunau.txt

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

From report at bugs.python.org  Mon Dec  2 23:24:00 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Mon, 02 Dec 2013 22:24:00 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>
Message-ID: <1386023040.67.0.514722182533.issue19866@psf.upfronthosting.co.za>


Changes by Francisco Mart?n Brugu? <francismb at email.de>:


Added file: http://bugs.python.org/file32943/failed_test_wave.txt

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

From report at bugs.python.org  Mon Dec  2 23:25:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 02 Dec 2013 22:25:47 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1386003857.64.0.559906602661.issue19850@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2jMrD4aUN05MOu4Ag8_5mewhuEskuTU+4ZB5AQMAJ3fw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
>
> That's just rhetoric -- I am beginning to believe that nobody has any data.  Here's some opposite rhetoric.  If it ain't broke, don't fix it.  Plus, if it's so much better, why isn't it the default?  If you say "for backward compatibility" I will say "exactly!"

Well, it's the default on BSD and Linux, but Python deliberately disables it:
"""
PyOS_setsig(int sig, PyOS_sighandler_t handler)
{
#ifdef HAVE_SIGACTION
    /* Some code in Modules/signalmodule.c depends on sigaction() being
     * used here if HAVE_SIGACTION is defined.  Fix that if this code
     * changes to invalidate that assumption.
     */
    struct sigaction context, ocontext;
    context.sa_handler = handler;
    sigemptyset(&context.sa_mask);
    context.sa_flags = 0;
    if (sigaction(sig, &context, &ocontext) == -1)
        return SIG_ERR;
    return ocontext.sa_handler;
#else
    PyOS_sighandler_t oldhandler;
    oldhandler = signal(sig, handler);
#ifdef HAVE_SIGINTERRUPT
    siginterrupt(sig, 1);
#endif
    return oldhandler;
#endif
}
"""

It's done because we want syscalls to return with EINTR to be able to
run signal handlers, but since asyncio uses a wakeup file descriptor,
it's unnecessary here.

> Any *other* I/O syscalls (unless a program violates the asyncio rules against
> doing your own blocking I/O) would either be disk file I/O, which IIUC cannot
> elicit EINTR, or run in a separate thread, where presumably it wouldn't be
> interrupted by a signal handler, since SIGCHLD is delivered to the main thread.
>  (It's actually the last part I am not 100% sure of.)

In order:
- Linux avoids EINTR on file I/O, but that's not necessarily the case
on other OS (e.g. on NFS)
- Many syscalls can return EINTR, not only I/O related, e.g. waitpid().
- As for threads, there's absolutely no guarantee that the signal will
be delivered to the main thread.

----------

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

From report at bugs.python.org  Mon Dec  2 23:27:16 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 Dec 2013 22:27:16 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>
Message-ID: <1386023236.22.0.460177564113.issue19866@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +zach.ware

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

From report at bugs.python.org  Mon Dec  2 23:37:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 22:37:50 +0000
Subject: [issue19865] create_unicode_buffer() fails on non-BMP strings on
 Windows
In-Reply-To: <1386013006.0.0.412572088185.issue19865@psf.upfronthosting.co.za>
Message-ID: <1386023870.6.0.57541067733.issue19865@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc, belopolsky, haypo, meador.inge

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

From report at bugs.python.org  Mon Dec  2 23:43:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 22:43:57 +0000
Subject: [issue19867] pickletools.OpcodeInfo.code is a string
Message-ID: <1386024237.29.0.240373861832.issue19867@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It should probably be a bytes object instead:

>>> op
<pickletools.OpcodeInfo object at 0x7f1e119db448>
>>> op.code
'\x95'
>>> op.name
'FRAME'
>>> pickle.FRAME
b'\x95'

----------
components: Library (Lib)
messages: 205061
nosy: alexandre.vassalotti, pitrou
priority: normal
severity: normal
status: open
title: pickletools.OpcodeInfo.code is a string
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec  2 23:49:56 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 22:49:56 +0000
Subject: [issue19860] asyncio: Add context manager to BaseEventLoop?
In-Reply-To: <1385984759.42.0.47454056153.issue19860@psf.upfronthosting.co.za>
Message-ID: <1386024596.31.0.84711533054.issue19860@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, calling close() is best practice *if you own the loop*.  But the thing is that you may not own what get_event_loop() returns, and in fact in most cases where it is called you don't own it.  This is very different from files:

  with open(...) as f:
      ...

In that idiom you clearly own f.  Both of these are also very different from locks and the like, because you can repeatedly acquire and release a lock (but you can only close a file or event loop once).

I tried to come up with a design for a helper that in __enter__() creates a new event loop and makes it the current event loop, then in __exit__() closes it and sets the current event loop to None.  But this doesn't work well with the way get_event_loop() can sometimes auto-creates the loop.

Therefore I am closing this as "rejected".

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Mon Dec  2 23:57:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 22:57:36 +0000
Subject: [issue19800] Write more detailed framing tests
In-Reply-To: <1385478625.17.0.0337296712121.issue19800@psf.upfronthosting.co.za>
Message-ID: <1386025056.81.0.272084137614.issue19800@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file32944/frame_tests.patch

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

From report at bugs.python.org  Mon Dec  2 23:58:44 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 22:58:44 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386025124.47.0.118487144707.issue19509@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The asyncio patch looks fine, but I'd like to see a unittest that actually fails (or mocks failing) the hostname check where it is now performed (in wrap_socket() IIUC?), to make sure that the exception is propagated out properly.

----------

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

From report at bugs.python.org  Tue Dec  3 00:01:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 23:01:34 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386025294.38.0.244819455301.issue19717@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(note that POSIX realpath() fails with ENOENT if the file doesn't exist: http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html )

----------

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

From report at bugs.python.org  Tue Dec  3 00:19:44 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 23:19:44 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386026384.73.0.393007369043.issue19717@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Hm, so we can choose to be more like POSIX realpath() or more like os.path.realpath().  I guess your original intuition was right.  Close with no action is fine.  If I need a partial real path I can always crawl up parents() until I find a path that does exist.

----------

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

From report at bugs.python.org  Tue Dec  3 00:23:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Dec 2013 23:23:37 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386026617.36.0.593493371888.issue19717@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think there's value in allowing the "less strict" behaviour with an optional arg, though. i.e.:

>>> Path('toto').resolve()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/cpython/default/Lib/pathlib.py", line 1024, in resolve
    s = self._flavour.resolve(self)
  File "/home/antoine/cpython/default/Lib/pathlib.py", line 282, in resolve
    target = accessor.readlink(cur)
  File "/home/antoine/cpython/default/Lib/pathlib.py", line 372, in readlink
    return os.readlink(path)
FileNotFoundError: [Errno 2] No such file or directory: '/home/antoine/cpython/default/toto'
>>> Path('toto').resolve(strict=False)
PosixPath('/home/antoine/cpython/default/toto')

----------

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

From report at bugs.python.org  Tue Dec  3 00:39:08 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 Dec 2013 23:39:08 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386027548.83.0.986976436582.issue19717@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sure.

----------

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

From report at bugs.python.org  Tue Dec  3 01:25:08 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Dec 2013 00:25:08 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>
Message-ID: <1386030308.69.0.445692089809.issue19866@psf.upfronthosting.co.za>


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


----------
nosy: +loewis, serhiy.storchaka

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

From report at bugs.python.org  Tue Dec  3 02:41:19 2013
From: report at bugs.python.org (Daniel Blanchard)
Date: Tue, 03 Dec 2013 01:41:19 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1386034879.62.0.811827954221.issue9998@psf.upfronthosting.co.za>


Daniel Blanchard added the comment:

Any chance of this making it into 3.4? This is a rather annoying deficiency of find_library().

----------
nosy: +Daniel.Blanchard

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

From report at bugs.python.org  Tue Dec  3 03:46:32 2013
From: report at bugs.python.org (Sworddragon)
Date: Tue, 03 Dec 2013 02:46:32 +0000
Subject: [issue19801] Concatenating bytes is much slower than concatenating
 strings
In-Reply-To: <1385485030.81.0.978810196169.issue19801@psf.upfronthosting.co.za>
Message-ID: <1386038792.38.0.433885319545.issue19801@psf.upfronthosting.co.za>


Sworddragon added the comment:

I have extended the benchmark a little and here are my new results:

concatenate_string()           : 0.037489
concatenate_bytes()            : 2.920202
concatenate_bytearray()        : 0.157311
concatenate_string_io()        : 0.035397
concatenate_bytes_io()         : 0.032835
concatenate_string_join()      : 0.170623
concatenate_string_and_encode(): 0.037280

- As we already know concatenating bytes is much slower then concatenating strings.
- concatenate_bytearray() shows that doing this with bytearrays is 5 times slower than concatenating strings. Also it will return a bytearray and I couldn't figure out how to convert it simply to a bytes object in this short time.
- Interestingly concatenate_string_io() shows that using a StringIO object is faster than concatenating strings directly.
- Even more interesting is that concatenate_bytes_io() shows that a BytesIO object is the fastest solution of all.
- Using .join in concatenate_string_join() shows that it is slow too.
- Curiously I couldn't test concatenate_bytes_join() as it will result in an exception. Searching the documentation resulted that I can't find a join method for bytes objects to look what is wrong.
- I have also tested in concatenate_string_and_encode() how fast it is to concatenate strings and then simply encode them. The performance impact compared to concatenating strings directly is low enough that the test couldn't measure it anymore.


Summary: BytesIO is the fastest solution but needs to import an extra library. Concatenating strings and then encode them seems to be the most practicable solution if io is not already imported.

But I'm wondering why Python can't simply have the string optimization on bytes too.

----------
Added file: http://bugs.python.org/file32945/test.py

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

From report at bugs.python.org  Tue Dec  3 04:55:36 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 03 Dec 2013 03:55:36 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386042936.71.0.202352247578.issue19858@psf.upfronthosting.co.za>


Tim Peters added the comment:

Is it _documented_ that MEMOIZE and PUT can't be used together?  If not, it should be documented; and pickletools dis() and optimize() should verify that this restriction is honored in their inputs.

----------

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

From report at bugs.python.org  Tue Dec  3 05:23:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Dec 2013 04:23:09 +0000
Subject: [issue19801] Concatenating bytes is much slower than concatenating
 strings
In-Reply-To: <1385485030.81.0.978810196169.issue19801@psf.upfronthosting.co.za>
Message-ID: <1386044589.47.0.703683030734.issue19801@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please take these observations and questions to python-list.  They aren't really appropriate for the bug tracker.  We aren't going to add the optimization shortcut for bytes unless someone does a bunch of convincing on python-ideas, which seems unlikely (but not impossible).

----------

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

From report at bugs.python.org  Tue Dec  3 05:32:11 2013
From: report at bugs.python.org (Sworddragon)
Date: Tue, 03 Dec 2013 04:32:11 +0000
Subject: [issue19801] Concatenating bytes is much slower than concatenating
 strings
In-Reply-To: <1385485030.81.0.978810196169.issue19801@psf.upfronthosting.co.za>
Message-ID: <1386045131.58.0.0461231531342.issue19801@psf.upfronthosting.co.za>


Sworddragon added the comment:

> We aren't going to add the optimization shortcut for bytes

There is still the question: Why isn't this going to be optimized?

----------

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

From report at bugs.python.org  Tue Dec  3 05:41:53 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Tue, 03 Dec 2013 04:41:53 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386045713.89.0.742198700683.issue19858@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

MEMOIZE and PUT can be used together. They just need to not step on each other toes when they write to the memo table. As specified by PEP 3154, the memo index used by MEMOIZE is the number of elements currently in the memo table. This obviously means functions like, pickletools.optimize, have to be more careful when they rewrite pickles.

----------

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

From report at bugs.python.org  Tue Dec  3 06:13:06 2013
From: report at bugs.python.org (Drew)
Date: Tue, 03 Dec 2013 05:13:06 +0000
Subject: [issue19868] Importing humanhash and uuid causes a segmentation fault
 crash
Message-ID: <1386047585.47.0.784915369979.issue19868@psf.upfronthosting.co.za>


New submission from Drew:

$ pip-3.3 install humanhash
$ python3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import uuid
>>> import humanhash
Segmentation fault: 11

----------
assignee: ronaldoussoren
components: Macintosh
files: Python_2013-12-02-231131_shadowfax.crash
messages: 205075
nosy: compaqdrew, ronaldoussoren
priority: normal
severity: normal
status: open
title: Importing humanhash and uuid causes a segmentation fault crash
versions: Python 3.3
Added file: http://bugs.python.org/file32946/Python_2013-12-02-231131_shadowfax.crash

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

From report at bugs.python.org  Tue Dec  3 06:19:32 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Dec 2013 05:19:32 +0000
Subject: [issue19868] Importing humanhash and uuid causes a segmentation fault
 crash
In-Reply-To: <1386047585.47.0.784915369979.issue19868@psf.upfronthosting.co.za>
Message-ID: <1386047972.03.0.285726324038.issue19868@psf.upfronthosting.co.za>


Ned Deily added the comment:

If you are running on OS X 10.9 Mavericks, install Python 3.3.3.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update

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

From report at bugs.python.org  Tue Dec  3 08:23:01 2013
From: report at bugs.python.org (Florian Pilz)
Date: Tue, 03 Dec 2013 07:23:01 +0000
Subject: [issue19869] BaseCookie does not complain if a non RFC compliant
 cookie header was given
Message-ID: <1386055381.8.0.960410220021.issue19869@psf.upfronthosting.co.za>


New submission from Florian Pilz:

BaseCookie should give an informative error, if a non RFC compliant header was given. The problem was, that we thought several cookies are allowed in one header in a cookie *response* header. However, this is only allowed in cookie *request* headers.

In those cases the output of BaseCookie looks broken, which caused a lot of confusion, since a standard library should not have so many flaws.

Example with parsing a response header with several cookies separated by comma (not allowed by RFC):

http.cookies.BaseCookie('foo=bar, oof=rab; httponly, bar=baz').output()
'Set-Cookie: bar=baz\r\nSet-Cookie: foo=bar,\r\nSet-Cookie: oof=rab'

Flaws:

* comma after 'foo=bar' in output
* the httponly flag was omitted (it would show up with a semi-colon after it, i.e. 'oof=rab; httponly;')
* input and output style are different, i.e. several cookies in one line were transformed to several cookies in several lines

I think the best solution is to fail early and hard, if there are several cookies in one header. Maybe some problems should be fixed anyway (trailing comma, different output style).

----------
components: Library (Lib)
messages: 205077
nosy: florianpilz
priority: normal
severity: normal
status: open
title: BaseCookie does not complain if a non RFC compliant cookie header was given
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec  3 08:27:08 2013
From: report at bugs.python.org (Florian Pilz)
Date: Tue, 03 Dec 2013 07:27:08 +0000
Subject: [issue19870] Backport Cookie fix to 2.7 (httponly / secure flag)
Message-ID: <1386055628.27.0.222770059818.issue19870@psf.upfronthosting.co.za>


New submission from Florian Pilz:

Until Python 3.3.3 the Cookie library did not support the httponly and secure flag (see Issue 16611). Therefore the library is not RFC conform until then, so I think there should be a backport into 2.7 and maybe 3.2 as well.

----------
components: Library (Lib)
messages: 205078
nosy: florianpilz
priority: normal
severity: normal
status: open
title: Backport Cookie fix to 2.7 (httponly / secure flag)
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Dec  3 08:55:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 07:55:46 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386057346.17.0.658236816133.issue19717@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch. Only tested on Linux. Later I'll test it on Windows.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file32947/add_non_strict_resolve_pathlib.patch

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

From report at bugs.python.org  Tue Dec  3 09:21:13 2013
From: report at bugs.python.org (picomancer)
Date: Tue, 03 Dec 2013 08:21:13 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
Message-ID: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>


New submission from picomancer:

Try the following in your favorite Python version:

    import json
    json.loads(".5")

On my Python (2.7.4 and 3.3.1 on Ubuntu Saucy Salamander), I get an exception.  However, x = .5 is a valid Python number.

With respect to the parsing of floats by the json module, the docs state:

    By default, this is equivalent to ``float(num_str)``.

This statement does not match the behavior I have observed in every version of Python I have tried, and is still in the bleeding-edge (as of this writing) at http://hg.python.org/cpython/file/9283a9c5d0ce/Doc/library/json.rst

I think it's clear that the following changes should definitely be implemented:

(1) The docs and behavior should match
(2) Whatever the desired behavior is, there is a unit test specifically for this corner case

Of course, to implement (1), there are two routes:

(1a) Leading decimal floats should be accepted by the json module; the behavior should be changed to match the docs.  Supported by Postel's Law -- "be liberal in what [your program] accept[s]"), see http://en.wikipedia.org/wiki/Postel%27s_law and the slightly relaxed attitude toward standards compliance detailed in the json module documentation.

(1b) Leading decimal floats should be rejected by the json module; the docs should be changed to match the behavior.  This fits with a strict standards compliance worldview.

I think (1a) is better.  In my particular use case, I was manually writing a json file with several numerical parameters.  The backtrace given by json.load(open("whatever.json", "r")) is uninformative and merely says "No JSON object could be decoded"; finding the token the parser considered to be malformed was fairly easy since there were only six or seven keys.  It could have been much worse if I was making manual changes to a larger JSON file.

----------
components: Library (Lib)
messages: 205080
nosy: picomancer
priority: normal
severity: normal
status: open
title: json module won't parse a float that starts with a decimal point
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Dec  3 09:22:26 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 08:22:26 +0000
Subject: [issue19872] Remove unused imports in pathlib
Message-ID: <1386058946.1.0.228185932917.issue19872@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Attached the patch to remove unused imports in pathlib.

----------
components: Library (Lib)
files: remove_unused_import_in_pathlib.patch
keywords: patch
messages: 205081
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: Remove unused imports in pathlib
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32948/remove_unused_import_in_pathlib.patch

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

From report at bugs.python.org  Tue Dec  3 09:30:49 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 08:30:49 +0000
Subject: [issue19873] There is a duplicate function in Lib/test/test_pathlib.py
Message-ID: <1386059449.85.0.979457911898.issue19873@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Here it is (Lib/test/test_pathlib.py, line 1240):

    def _check_resolve_relative(self, p, expected):
        q = p.resolve()
        self.assertEqual(q, expected)

    def _check_resolve_absolute(self, p, expected):
        q = p.resolve()
        self.assertEqual(q, expected)

----------
components: Tests
messages: 205082
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: There is a duplicate function in Lib/test/test_pathlib.py
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  3 09:34:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 08:34:41 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386059681.09.0.513321627301.issue19871@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think it would be better to adhere to the JSON spec, which doesn't allow numbers to start with a decimal point:
http://json.org/

If we go this way, the documentation should at least be fixed; and, as you say, we could also add a unit test for it.

----------
assignee:  -> docs at python
components: +Documentation, Tests -Library (Lib)
nosy: +docs at python, pitrou
stage:  -> needs patch
versions:  -Python 3.5

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

From report at bugs.python.org  Tue Dec  3 09:34:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 08:34:53 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386059693.71.0.257330455368.issue19871@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Dec  3 09:35:26 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 Dec 2013 08:35:26 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386059726.94.0.442514282548.issue19871@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/issue19871>
_______________________________________

From report at bugs.python.org  Tue Dec  3 09:36:41 2013
From: report at bugs.python.org (Anthony Baire)
Date: Tue, 03 Dec 2013 08:36:41 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1386059801.4.0.872118194562.issue19850@psf.upfronthosting.co.za>


Anthony Baire added the comment:

The patch is fine, but it is hard to rely on it to prevent bugs from happening because that requires cooperation from all modules registering signal handlers.

Anyway it facilitates reusing code that was not written for an event-driven context (and many will do that through .run_in_executor()). If the patch is accepted, it would be wise to write a note in .run_in_executor()'s doc saying that asyncio uses SA_RESTART by default in all its handler and that EINTR is prevented *as long as* no other handlers are registered elsewhere.

----------
nosy: +aba

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

From report at bugs.python.org  Tue Dec  3 09:41:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 08:41:42 +0000
Subject: [issue19872] Remove unused imports in pathlib
In-Reply-To: <1386058946.1.0.228185932917.issue19872@psf.upfronthosting.co.za>
Message-ID: <3dYc9x3p6Fz7Ljn@mail.python.org>


Roundup Robot added the comment:

New changeset a6245b10e8b6 by Antoine Pitrou in branch 'default':
Issue #19872: remove unused imports in pathlib.  Patch by Vajrasky Kok.
http://hg.python.org/cpython/rev/a6245b10e8b6

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

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

From report at bugs.python.org  Tue Dec  3 09:41:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 08:41:58 +0000
Subject: [issue19872] Remove unused imports in pathlib
In-Reply-To: <1386058946.1.0.228185932917.issue19872@psf.upfronthosting.co.za>
Message-ID: <1386060118.65.0.90561010501.issue19872@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you :)

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

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

From report at bugs.python.org  Tue Dec  3 09:59:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 08:59:34 +0000
Subject: [issue19800] Write more detailed framing tests
In-Reply-To: <1385478625.17.0.0337296712121.issue19800@psf.upfronthosting.co.za>
Message-ID: <3dYcZY5xqPz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 1c04427fff07 by Antoine Pitrou in branch 'default':
Issue #19800: make the pickle framing tests more precise.
http://hg.python.org/cpython/rev/1c04427fff07

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

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

From report at bugs.python.org  Tue Dec  3 10:00:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 09:00:06 +0000
Subject: [issue19800] Write more detailed framing tests
In-Reply-To: <1385478625.17.0.0337296712121.issue19800@psf.upfronthosting.co.za>
Message-ID: <1386061206.25.0.660152141811.issue19800@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Committed with "offset" replaced with "pos".

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

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

From report at bugs.python.org  Tue Dec  3 10:02:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 09:02:26 +0000
Subject: [issue19873] There is a duplicate function in Lib/test/test_pathlib.py
In-Reply-To: <1386059449.85.0.979457911898.issue19873@psf.upfronthosting.co.za>
Message-ID: <1386061346.18.0.0342125677462.issue19873@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, it's not really a duplicate function (the code is the same, but the intent is different). I'm not sure it's worth deduplicating.

----------

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

From report at bugs.python.org  Tue Dec  3 10:16:39 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 03 Dec 2013 09:16:39 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1386062199.88.0.458852419304.issue7105@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Strictly speaking b) is not a semantic change.  Depending on your semantic definition of semantics.  At any rate it is even less so than a) since the temporary list is hidden from view and the only side effect is additional memory usage.

----------

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

From report at bugs.python.org  Tue Dec  3 10:18:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 09:18:23 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386062303.67.0.616083392312.issue19871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree with Antoine.

----------

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

From report at bugs.python.org  Tue Dec  3 10:19:21 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 03 Dec 2013 09:19:21 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1386062361.07.0.529466594171.issue7105@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

d), We could also simply issue a (documentation) warning, that the "iterator" methods of these dictionares are known to be fragile, and recommend that people use the keys(), values() and items() instead.

----------

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

From report at bugs.python.org  Tue Dec  3 10:20:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 09:20:18 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1386062418.5.0.391123551196.issue7105@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

d) sounds like a good enough resolution at this point.

----------

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

From report at bugs.python.org  Tue Dec  3 10:21:18 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 09:21:18 +0000
Subject: [issue19873] There is a duplicate function in Lib/test/test_pathlib.py
In-Reply-To: <1386059449.85.0.979457911898.issue19873@psf.upfronthosting.co.za>
Message-ID: <1386062478.02.0.114869809572.issue19873@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

These functions are only being used in test_resolve_common.

    def test_resolve_common(self):
        P = self.cls
        p = P(BASE, 'foo')
        with self.assertRaises(OSError) as cm:
            p.resolve()
        self.assertEqual(cm.exception.errno, errno.ENOENT)
        # These are all relative symlinks
        p = P(BASE, 'dirB', 'fileB')
        self._check_resolve_relative(p, p)
        p = P(BASE, 'linkA')
        self._check_resolve_relative(p, P(BASE, 'fileA'))
        p = P(BASE, 'dirA', 'linkC', 'fileB')
        self._check_resolve_relative(p, P(BASE, 'dirB', 'fileB'))
        p = P(BASE, 'dirB', 'linkD', 'fileB')
        self._check_resolve_relative(p, P(BASE, 'dirB', 'fileB'))
        # Now create absolute symlinks
        d = tempfile.mkdtemp(suffix='-dirD')
        self.addCleanup(shutil.rmtree, d)
        os.symlink(os.path.join(d), join('dirA', 'linkX'))
        os.symlink(join('dirB'), os.path.join(d, 'linkY'))
        p = P(BASE, 'dirA', 'linkX', 'linkY', 'fileB')
        self._check_resolve_absolute(p, P(BASE, 'dirB', 'fileB'))

Why not just combine them to _check_resolve to avoid confusion? It did confuse me. I was not sure whether I had to check the absolute link differently than the relative link.

----------

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

From report at bugs.python.org  Tue Dec  3 10:27:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 09:27:52 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386062872.79.0.161861659568.issue19717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The readlink utility has different modes for canonization:

       -f, --canonicalize
              canonicalize by following every symlink in every component of the given name recursively; all but the last component must exist

       -e, --canonicalize-existing
              canonicalize by following every symlink in every component of the given name recursively, all components must exist

       -m, --canonicalize-missing
              canonicalize by following every symlink in every component of the given name recursively, without requirements on components existence

I think every mode has use cases.

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

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

From report at bugs.python.org  Tue Dec  3 10:31:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 09:31:01 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1386059801.4.0.872118194562.issue19850@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa5mq=80acimF62Ua9PMFi7u3FoUg7Jv6FCHvOWTZZiAg@mail.gmail.com>


STINNER Victor added the comment:

SA_RESTART doesn't need to be enforced. It's better to use it, but
selectors and asyncio modules already handle EINTR error.

----------

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

From report at bugs.python.org  Tue Dec  3 10:53:40 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Dec 2013 09:53:40 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1386064420.32.0.640338881189.issue9998@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Since 3.4 entered beta last week, it is now in feature freeze, so only bug fixes are allowed, unfortunately.

Since I did the ld patch I didn't want to commit it before getting another developer to review it, and it looks as if it just dropped under everyone's radar.

----------

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

From report at bugs.python.org  Tue Dec  3 11:04:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 10:04:56 +0000
Subject: [issue19874] test_logging failures on Snow Leopard
Message-ID: <1386065096.95.0.643671353968.issue19874@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

"test_race" in test_logging fails intermittently on the Snow Leopard buildbot:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/741

======================================================================
ERROR: test_race (test.test_logging.HandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_logging.py", line 613, in test_race
    h.handle(r)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 835, in handle
    self.emit(record)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/handlers.py", line 468, in emit
    self.stream = self._open()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 1005, in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding)
PermissionError: [Errno 1] Operation not permitted: '/tmp/test_logging-3-0my8mx_f.log'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_logging.py", line 616, in test_race
    h.close()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 990, in close
    self.flush()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 937, in flush
    self.stream.flush()
ValueError: I/O operation on closed file.

----------
components: Library (Lib), Tests
messages: 205098
nosy: pitrou, r.david.murray, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: test_logging failures on Snow Leopard
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 11:17:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 10:17:39 +0000
Subject: [issue19875] test_getsockaddrarg occasional failure
Message-ID: <1386065859.81.0.4295023541.issue19875@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It's on the FreeBSD 10.0 buildbot:
http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/1169

======================================================================
ERROR: test_getsockaddrarg (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/3.x.koobs-freebsd10/build/Lib/test/test_socket.py", line 1159, in test_getsockaddrarg
    sock.bind((host, port))
OSError: [Errno 48] Address already in use

----------
components: Library (Lib), Tests
messages: 205099
nosy: koobs, neologix, pitrou
priority: normal
severity: normal
status: open
title: test_getsockaddrarg occasional failure
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 12:19:28 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Dec 2013 11:19:28 +0000
Subject: [issue19665] test_logging fails with SMTPHandler timeout
In-Reply-To: <1384970566.07.0.397875675827.issue19665@psf.upfronthosting.co.za>
Message-ID: <1386069568.57.0.401668709847.issue19665@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I think the test is fragile, but I'll bump the timeout as suggested.

----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Tue Dec  3 12:21:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 11:21:38 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1386062872.79.0.161861659568.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386069696.2296.14.camel@fsol>


Antoine Pitrou added the comment:

> I think every mode has use cases.

Probably, but which ones are the most likely? A ternary flag leads to a
clumsier API than a simple binary flag.

----------

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

From report at bugs.python.org  Tue Dec  3 12:30:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 11:30:06 +0000
Subject: [issue19665] test_logging fails with SMTPHandler timeout
In-Reply-To: <1384970566.07.0.397875675827.issue19665@psf.upfronthosting.co.za>
Message-ID: <3dYgwG01lSz7Lk4@mail.python.org>


Roundup Robot added the comment:

New changeset 4c5fc9f08b4d by Vinay Sajip in branch '3.3':
Issue #19665: Increased timeout for SMTPHandler test.
http://hg.python.org/cpython/rev/4c5fc9f08b4d

New changeset bfd45dc46569 by Vinay Sajip in branch 'default':
Closes #19665: Merged fi from 3.3.
http://hg.python.org/cpython/rev/bfd45dc46569

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Dec  3 12:41:51 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Dec 2013 11:41:51 +0000
Subject: [issue19874] test_logging failures on Snow Leopard
In-Reply-To: <1386065096.95.0.643671353968.issue19874@psf.upfronthosting.co.za>
Message-ID: <1386070911.08.0.701391055913.issue19874@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I think this is the same as #19690.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_logging test_race failed with PermissionError

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

From report at bugs.python.org  Tue Dec  3 13:00:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Dec 2013 12:00:59 +0000
Subject: [issue19869] BaseCookie does not complain if a non RFC compliant
 cookie header was given
In-Reply-To: <1386055381.8.0.960410220021.issue19869@psf.upfronthosting.co.za>
Message-ID: <1386072059.95.0.860769718004.issue19869@psf.upfronthosting.co.za>


R. David Murray added the comment:

RFCs and cookies don't have much to do with each other in real life.

The 'httponly' flag bug was fixed in issue 16611.

For backward compatibility reasons we can't start raising errors where we didn't raise them before, so if anything is going to be done it will have to be a bit more complicated, and a be a new feature.

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

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

From report at bugs.python.org  Tue Dec  3 13:07:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Dec 2013 12:07:01 +0000
Subject: [issue19870] Backport Cookie fix to 2.7 (httponly / secure flag)
In-Reply-To: <1386055628.27.0.222770059818.issue19870@psf.upfronthosting.co.za>
Message-ID: <1386072421.9.0.124817990792.issue19870@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not sure why that fix was not backported, so I think it should be OK to do so.

3.2 is in security fix only mode.  No one argued that it was a securty issue when it was fixed in 3.3.

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

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

From report at bugs.python.org  Tue Dec  3 13:17:50 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:17:50 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1386073070.44.0.23178005239.issue19734@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue for the lack of attention paid to sys.flags.ignore_environment: https://github.com/pypa/pip/issues/1359

----------

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

From report at bugs.python.org  Tue Dec  3 13:18:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:18:14 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1386073094.91.0.467313319368.issue19734@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue for the failure to detect a native venv: https://github.com/pypa/pip/issues/1358

----------

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

From report at bugs.python.org  Tue Dec  3 13:18:23 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:18:23 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1386073103.33.0.53667989268.issue19734@psf.upfronthosting.co.za>


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


----------
priority: deferred blocker -> release blocker

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

From report at bugs.python.org  Tue Dec  3 13:20:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:20:02 +0000
Subject: [issue19744] ensurepip should refuse to install pip if SSL/TLS is not
 available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <1386073202.29.0.622799423981.issue19744@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Relevant pip issue: https://github.com/pypa/pip/issues/1165

----------
nosy: +larry
priority: high -> release blocker

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

From report at bugs.python.org  Tue Dec  3 13:22:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:22:40 +0000
Subject: [issue19347] PEP 453 implementation tracking issue
In-Reply-To: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za>
Message-ID: <1386073360.59.0.908246237307.issue19347@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 19766 covers the fact that the vendored urllib3 needs to be updated in order to handle the case where Python is built without threading support.

----------

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

From report at bugs.python.org  Tue Dec  3 13:23:15 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:23:15 +0000
Subject: [issue19347] PEP 453 implementation tracking issue
In-Reply-To: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za>
Message-ID: <1386073395.34.0.768144983558.issue19347@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Upgrading to release blocker status, since we'd prefer to have everything we can sorted before beta 2

----------
nosy: +larry
priority: normal -> release blocker

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

From report at bugs.python.org  Tue Dec  3 13:24:34 2013
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 03 Dec 2013 12:24:34 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386073474.6.0.0679670446893.issue19766@psf.upfronthosting.co.za>


Donald Stufft added the comment:

The urllib3 in requests VCS was updated, I just need to bother Kenneth to make a new release of requests or update pip to an unreleased requests.

----------

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

From report at bugs.python.org  Tue Dec  3 13:29:58 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Dec 2013 12:29:58 +0000
Subject: [issue19690] test_logging test_race failed with PermissionError
In-Reply-To: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za>
Message-ID: <1386073798.9.0.577478658986.issue19690@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Unfortunately, the race condition can't be removed completely - it was reduced by the patch in #14632 but could not be eliminated altogether. So this test can fail sporadically - tweaking the timeouts might give some temporary respite, but doesn't guarantee the issue won't return when e.g. machines are unusually heavily loaded.

I'll add some diagnostics for now and see what they show.

----------

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

From report at bugs.python.org  Tue Dec  3 13:30:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 12:30:00 +0000
Subject: [issue19744] test_venv fails if SSL/TLS is not available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <1386073800.65.0.470126926612.issue19744@psf.upfronthosting.co.za>


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


----------
title: ensurepip should refuse to install pip if SSL/TLS is not available -> test_venv fails if SSL/TLS is not available

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

From report at bugs.python.org  Tue Dec  3 13:31:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 12:31:36 +0000
Subject: [issue19690] test_logging test_race failed with PermissionError
In-Reply-To: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za>
Message-ID: <3dYjHD20XKz7Ljs@mail.python.org>


Roundup Robot added the comment:

New changeset 8fe3022af4b3 by Vinay Sajip in branch 'default':
Added some diagnostics to help with #19690.
http://hg.python.org/cpython/rev/8fe3022af4b3

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

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

From report at bugs.python.org  Tue Dec  3 13:32:59 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 03 Dec 2013 12:32:59 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386073979.52.0.652186486538.issue19871@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

In context, the doc is correct:

"""
parse_float, if specified, will be called with the string of every JSON float to be decoded. By default, this is equivalent to float(num_str).
"""

IIUC, parse_float only comes into play once the JSON source has already been tokenized, and the tokenization stage has already rejected things like '.5' by that point.  (The point of parse_float is that you can choose to turn numeric strings into decimal.Decimal instances instead of floats if you so wish.)

I agree it could use clarification.

----------

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

From report at bugs.python.org  Tue Dec  3 13:55:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 12:55:54 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <3dYjqG0lB3z7Ll5@mail.python.org>


Roundup Robot added the comment:

New changeset 97fb852c5c26 by Stefan Krah in branch 'default':
Issue #9709: Stop adding PyInit_" + module_name' to export_symbols.  This is
http://hg.python.org/cpython/rev/97fb852c5c26

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

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

From report at bugs.python.org  Tue Dec  3 14:14:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Dec 2013 13:14:48 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1386076488.71.0.523912125204.issue19734@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

1358 (failing to detect native virtual environments) will be resolved upstream, but for 1359 (telling pip to ignore the environment variables), I've decided I agree with Paul's suggestion on the pip issue that it makes sense for venv to just strip all environment variables starting with "PIP_" from the environment passed to the subprocess.

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

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

From report at bugs.python.org  Tue Dec  3 14:16:19 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 03 Dec 2013 13:16:19 +0000
Subject: [issue9709] test_distutils warning: initfunc exported twice on Windows
In-Reply-To: <1283101838.76.0.73949668593.issue9709@psf.upfronthosting.co.za>
Message-ID: <1386076579.67.0.344485583438.issue9709@psf.upfronthosting.co.za>


Stefan Krah added the comment:

?ric, thanks for taking a look.

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

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

From report at bugs.python.org  Tue Dec  3 15:11:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 14:11:19 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
Message-ID: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I remember a discussion about EBADF, but I don't remember the conclusion. The documentation of the asyncio doesn't explain the behaviour of selectors when a file/socket is closed, without unregistering it from the selector.

I should be explicitly documented. I would accept an "undefined behaviour" if it's documented :-)

----------
assignee: docs at python
components: Documentation
messages: 205118
nosy: docs at python, gvanrossum, haypo, neologix
priority: normal
severity: normal
status: open
title: selectors (and asyncio?): document behaviour on closed files/sockets
versions: Python 3.4

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

From report at bugs.python.org  Tue Dec  3 15:19:07 2013
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 03 Dec 2013 14:19:07 +0000
Subject: [issue19744] test_venv fails if SSL/TLS is not available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <1386080347.55.0.618647821449.issue19744@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Tue Dec  3 15:41:19 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 03 Dec 2013 14:41:19 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386081679.64.0.372281000811.issue19871@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

There are other forms of numbers allowed by Python that are not allowed by JSON: "001.1"

Oddly, with all of the strictness in JSON, the exponent-marker "e" can be upper- or lower-case:  1e1 and 1E1 are both valid JSON.

----------
nosy: +nedbat

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

From report at bugs.python.org  Tue Dec  3 16:29:15 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Tue, 03 Dec 2013 15:29:15 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386084555.56.0.837447333165.issue19859@psf.upfronthosting.co.za>


Radomir Dopieralski added the comment:

I prepared a proof of concept solution at:

https://bitbucket.org/thesheep/cpython-lru_cache-weakref/commits/66c1c9f3256785552224ca177ed77a8312de6bb8

----------
hgrepos: +215

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

From report at bugs.python.org  Tue Dec  3 16:39:38 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 15:39:38 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1386085178.16.0.897437622809.issue19850@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Please answer this question. Under what circumstances can a signal handler interrupt a blocking system call in a thread that is not the main thread?

----------

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

From report at bugs.python.org  Tue Dec  3 16:42:44 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 03 Dec 2013 15:42:44 +0000
Subject: [issue19864] multiprocessing Proxy docs need locking semantics
 explained
In-Reply-To: <1386010854.42.0.669130689835.issue19864@psf.upfronthosting.co.za>
Message-ID: <1386085364.77.0.484218607817.issue19864@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

>From what I remember a proxy method will be thread/process-safe if the referent's corresponding method is thread safe.

It should certainly be documented that the exposed methods of a proxied object should be thread-safe.

----------

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

From report at bugs.python.org  Tue Dec  3 16:45:37 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 15:45:37 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386085537.2.0.87673586993.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yeah, the behavior is at least different for each type of polling system calls, and possibly also for different platforms.  It would be good to describe at least all the different possible behaviors.

----------

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

From report at bugs.python.org  Tue Dec  3 16:53:12 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 15:53:12 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1386085992.34.0.178151283594.issue7105@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm not sure I understand the hesitation about backporting the Python 3 solution. We're acknowledging it's a bug, so the fix is not a feature. The Python 3 solution is the future. So why not fix it?

----------

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

From report at bugs.python.org  Tue Dec  3 16:54:13 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 15:54:13 +0000
Subject: [issue16594] SocketServer should set SO_REUSEPORT along with
 SO_REUSEADDR when present
In-Reply-To: <1354439249.45.0.0324812571604.issue16594@psf.upfronthosting.co.za>
Message-ID: <1386086053.51.0.468795778216.issue16594@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Note: it is possible that SO_REUSEPORT is defined yet not implemented (and you'll get an OSError when using it).

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Tue Dec  3 17:06:57 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 03 Dec 2013 16:06:57 +0000
Subject: [issue19877] test_resolve_dot of test_pathlib.py fails on Windows
 Vista
Message-ID: <1386086817.69.0.41545302565.issue19877@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

You must run this test as administrator.

C:\Users\vajrasky\Code\cpython>PCbuild\python.exe Lib\test\test_pathlib.py
..........s..s..s..s.........s.....E............ssssssssssssssssssssssssssssssss
ssssssssssssssssssssssssssssssssssssssssssssssss................................
................................................................................
...............................................s..s..s..s.........s.....E.......
..
======================================================================
ERROR: test_resolve_dot (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1281, in test_resolve_dot
    self.assertEqual(q.resolve(), p)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 1017, in resolve
    s = self._flavour.resolve(self)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 179, in resolve
    return self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 123] The filename, directory name, or volume label syntax is
incorrect: 'C:\\Users\\vajrasky\\Code\\cpython\\@test_5860_tmp\\2'

======================================================================
ERROR: test_resolve_dot (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1281, in test_resolve_dot
    self.assertEqual(q.resolve(), p)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 1017, in resolve
    s = self._flavour.resolve(self)
  File "C:\Users\vajrasky\Code\cpython\lib\pathlib.py", line 179, in resolve
    return self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 123] The filename, directory name, or volume label syntax is
incorrect: 'C:\\Users\\vajrasky\\Code\\cpython\\@test_5860_tmp\\2'

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

Windows does not like "/" in its name for the file.

Attached the patch to fix the test.

----------
components: Tests
files: fix_test_resolve_dot_on_windows.patch
keywords: patch
messages: 205126
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: test_resolve_dot of test_pathlib.py fails on Windows Vista
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32949/fix_test_resolve_dot_on_windows.patch

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

From report at bugs.python.org  Tue Dec  3 17:07:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 16:07:17 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1386085178.16.0.897437622809.issue19850@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ_Hm-=z0C+fsLNANfwtey+v_hG9EJNtpkC5pMRYxk2YQ@mail.gmail.com>


STINNER Victor added the comment:

2013/12/3 Guido van Rossum <report at bugs.python.org>:
> Please answer this question. Under what circumstances can a signal handler interrupt a blocking system call in a thread that is not the main thread?

There is no guarantee that the signal handler is called in the main
thread. On FreeBSD, if I remember correctly, it is called in a random
thread.

You can control which thread gets the signal using
signal.pthread_sigmask() (block signals in other threads) and
signal.pthread_kill() (send a signal a specific thread).

----------

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

From report at bugs.python.org  Tue Dec  3 17:11:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 16:11:42 +0000
Subject: [issue19877] test_resolve_dot of test_pathlib.py fails on Windows
 Vista
In-Reply-To: <1386086817.69.0.41545302565.issue19877@psf.upfronthosting.co.za>
Message-ID: <1386087102.83.0.00831316188497.issue19877@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Wow, thank you. It's a pity none of the Windows buildbots runs in administrator mode.

----------

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

From report at bugs.python.org  Tue Dec  3 17:13:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 16:13:20 +0000
Subject: [issue19877] test_resolve_dot of test_pathlib.py fails on Windows
 Vista
In-Reply-To: <1386086817.69.0.41545302565.issue19877@psf.upfronthosting.co.za>
Message-ID: <3dYpC367chz7LnD@mail.python.org>


Roundup Robot added the comment:

New changeset 076824de7650 by Antoine Pitrou in branch 'default':
Issue #19877: fix regression in test_pathlib when Windows has symlink support available (i.e. in administrator mode).
http://hg.python.org/cpython/rev/076824de7650

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

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

From report at bugs.python.org  Tue Dec  3 17:14:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Dec 2013 16:14:16 +0000
Subject: [issue19877] test_resolve_dot of test_pathlib.py fails on Windows
 Vista
In-Reply-To: <1386086817.69.0.41545302565.issue19877@psf.upfronthosting.co.za>
Message-ID: <1386087256.54.0.228069192686.issue19877@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Now committed.

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

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

From report at bugs.python.org  Tue Dec  3 18:37:27 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 03 Dec 2013 17:37:27 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386092247.34.0.140237625216.issue19871@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/issue19871>
_______________________________________

From report at bugs.python.org  Tue Dec  3 18:46:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 17:46:18 +0000
Subject: [issue19833] asyncio: patches to document EventLoop and add more
 examples
In-Reply-To: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>
Message-ID: <1386092778.77.0.2400559502.issue19833@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


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

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

From report at bugs.python.org  Tue Dec  3 19:03:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 18:03:55 +0000
Subject: [issue18699] What is Future.running() for in PEP 3148 /
 concurrent.futures.Future?
In-Reply-To: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>
Message-ID: <1386093835.15.0.699411021849.issue18699@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/issue18699>
_______________________________________

From report at bugs.python.org  Tue Dec  3 19:09:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 18:09:55 +0000
Subject: [issue19875] test_getsockaddrarg occasional failure
In-Reply-To: <1386065859.81.0.4295023541.issue19875@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1g-faD4DqKi23F61M5PqFg7EdN+Bx3AcfuKM_onxvuHA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

This test is inherently subject to a race condition:
"""
        port = support.find_unused_port()
        [...]
        try:
            self.assertRaises(OverflowError, sock.bind, (host, big_port))
            self.assertRaises(OverflowError, sock.bind, (host, neg_port))
            sock.bind((host, port))
        finally:
            sock.close()
"""

The buildbot being set up ton run the test suite with "-j4" is
probably the most important factor.

A possibility would be to try the find_unused_port() + bind() in a
loop a couple times.

----------

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

From report at bugs.python.org  Tue Dec  3 19:21:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Dec 2013 18:21:28 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
In-Reply-To: <1386023008.24.0.870175921634.issue19866@psf.upfronthosting.co.za>
Message-ID: <1386094888.36.0.514185485927.issue19866@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Francis, would you like to work on a patch for this?  The change should go in Tools/msi/msi.py, if I'm not mistaken.

----------

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

From report at bugs.python.org  Tue Dec  3 19:23:12 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 18:23:12 +0000
Subject: [issue18699] What is Future.running() for in PEP 3148 /
 concurrent.futures.Future?
In-Reply-To: <1376092118.24.0.585945689562.issue18699@psf.upfronthosting.co.za>
Message-ID: <1386094992.88.0.0108581604428.issue18699@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I see no point in keeping this open.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed
type: enhancement -> behavior

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

From report at bugs.python.org  Tue Dec  3 19:30:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 18:30:04 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386085537.2.0.87673586993.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM31iCe+iX2LKp8u0x59=Uc5jGdzsmdDcgX72YVaOP5D=w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Well, unregister() documentation currently contains this:
"""
   .. method:: unregister(fileobj)

      Unregister a file object from selection, removing it from monitoring. A
      file object shall be unregistered prior to being closed.
"""

I'm not sure what else to say (I don' like the idea of documenting
possible behaviors, because it's non-portable, and really might change
in a future version).

----------

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

From report at bugs.python.org  Tue Dec  3 19:35:20 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 18:35:20 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386095720.42.0.0308162053189.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think we should give the reader some kind of hint, since a bug in this area may cause a lot of pain when it has to be debugged on porting from a system where the issue is silent to one where it causes a crash.  These docs (unlike a PEP) are not a formal standard but documentation for users.  Maybe we can add a separate section of caveats?

----------

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

From report at bugs.python.org  Tue Dec  3 19:41:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 18:41:34 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386096094.41.0.681450874589.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"(I don' like the idea of documenting
possible behaviors, because it's non-portable, and really might change
in a future version)."

The description doesn't need to be precise, you can just say "depending on the platform, closing a file descriptor while selector.select() is polling may be ignored or raise an exception". Which can of exception is raised? It is possible to catch it and find the closed file descriptor?

----------

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

From report at bugs.python.org  Tue Dec  3 19:51:08 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 18:51:08 +0000
Subject: [issue19878] PyFile_DecUseCount() SIGSEGV
Message-ID: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>


New submission from Matthew Bergin:

[level@<removed> fuzz]# cat pyfile.py
import bz2
obj = bz2.BZ2File('/tmp/fileName')
obj.__init__("fileName")
obj.__reduce__
[level@<removed> fuzz]# gdb --args python pyfile.py
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.6.6-37.el6_4.i686 python-2.6.6-37.el6_4.x86_64
(gdb) r
Starting program: /usr/bin/python pyfile.py
[Thread debugging using libthread_db enabled]
Traceback (most recent call last):
  File "pyfile.py", line 3, in <module>
    obj.__init__("fileName")
IOError: [Errno 2] No such file or directory: 'fileName'

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a98170 in PyFile_DecUseCount () from /usr/lib64/libpython2.6.so.1.0
(gdb)

----------
components: Interpreter Core
messages: 205137
nosy: Level
priority: normal
severity: normal
status: open
title: PyFile_DecUseCount() SIGSEGV
versions: Python 2.6

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

From report at bugs.python.org  Tue Dec  3 19:54:52 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 18:54:52 +0000
Subject: [issue19879] PyCFunction_NewEx() SIGABRT
Message-ID: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>


New submission from Matthew Bergin:

[level@<removed> fuzz]# cat PyCFunction.py
#
# PyCFunction_NewEx crach poc (sigabrt)
#
import imageop
imageop.rgb82rgb(u"%J8CBej >uFBi-",True,8.36)
imageop.grey2grey(None,5,u"CRi")
[level@<removed> fuzz]# gdb --args python PyCFunction.py
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
Missing separate debuginfos, use: debuginfo-install python-2.6.6-37.el6_4.i686 python-2.6.6-37.el6_4.x86_64
(gdb) r
Starting program: /usr/bin/python PyCFunction.py
[Thread debugging using libthread_db enabled]
PyCFunction.py:5: DeprecationWarning: integer argument expected, got float
  imageop.rgb82rgb(u"%J8CBej >uFBi-",True,8.36)
Fatal Python error: GC object already tracked

Program received signal SIGABRT, Aborted.
0x00007ffff6e2e8e5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6e2e8e5 in raise () from /lib64/libc.so.6
#1  0x00007ffff6e300c5 in abort () from /lib64/libc.so.6
#2  0x00007ffff7b2823e in Py_FatalError () from /usr/lib64/libpython2.6.so.1.0
#3  0x00007ffff7ab3175 in PyCFunction_NewEx () from /usr/lib64/libpython2.6.so.1.0
#4  0x00007ffff7b24b18 in Py_InitModule4_64 () from /usr/lib64/libpython2.6.so.1.0
#5  0x00007ffff0b66abe in initsyslog () from /usr/lib64/python2.6/lib-dynload/syslog.so
#6  0x00007ffff7b21865 in _PyImport_LoadDynamicModule () from /usr/lib64/libpython2.6.so.1.0
#7  0x00007ffff7b1f8a5 in ?? () from /usr/lib64/libpython2.6.so.1.0
#8  0x00007ffff7b1fb24 in ?? () from /usr/lib64/libpython2.6.so.1.0
#9  0x00007ffff7b2017d in ?? () from /usr/lib64/libpython2.6.so.1.0
#10 0x00007ffff7b20ee4 in PyImport_ImportModuleLevel () from /usr/lib64/libpython2.6.so.1.0
#11 0x00007ffff7b0671f in ?? () from /usr/lib64/libpython2.6.so.1.0
#12 0x00007ffff7a7ac63 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#13 0x00007ffff7b06c93 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#14 0x00007ffff7b0a33f in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#15 0x00007ffff7b0db8f in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#16 0x00007ffff7b0e657 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#17 0x00007ffff7aa1cb0 in ?? () from /usr/lib64/libpython2.6.so.1.0
#18 0x00007ffff7a7ac63 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#19 0x00007ffff7b06c93 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#20 0x00007ffff7b29cc2 in PyErr_PrintEx () from /usr/lib64/libpython2.6.so.1.0
#21 0x00007ffff7b2a287 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.6.so.1.0
#22 0x00007ffff7b368a2 in Py_Main () from /usr/lib64/libpython2.6.so.1.0
#23 0x00007ffff6e1acdd in __libc_start_main () from /lib64/libc.so.6
#24 0x0000000000400649 in _start ()
(gdb) q

----------
components: Interpreter Core
messages: 205138
nosy: Level
priority: normal
severity: normal
status: open
title: PyCFunction_NewEx() SIGABRT
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Tue Dec  3 19:55:03 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 18:55:03 +0000
Subject: [issue19878] PyFile_DecUseCount() SIGSEGV
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <1386096903.24.0.30082540387.issue19878@psf.upfronthosting.co.za>


Changes by Matthew Bergin <mbergin at coresecurity.com>:


----------
type:  -> crash

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

From report at bugs.python.org  Tue Dec  3 20:42:11 2013
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 03 Dec 2013 19:42:11 +0000
Subject: [issue19877] test_resolve_dot of test_pathlib.py fails on Windows
 Vista
In-Reply-To: <1386086817.69.0.41545302565.issue19877@psf.upfronthosting.co.za>
Message-ID: <1386099730.99.0.498803888238.issue19877@psf.upfronthosting.co.za>


Brian Curtin added the comment:

My build slave ran as admin in order to make sure symlinks were covered, but I don't have the hardware anymore. I'll see if I can get another machine up and running.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Dec  3 20:43:04 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 19:43:04 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1386059801.4.0.872118194562.issue19850@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM23Y0hR_QsK4FftWmtA7uK23Sh837rva5S=+sqH+Eb3BA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> The patch is fine, but it is hard to rely on it to prevent bugs from happening because that requires cooperation from all modules registering signal handlers.

Once again, that's why the bug report says "*limit* EINTR occurrences".
We all know this won't prevent all occurrences.

> Anyway it facilitates reusing code that was not written for an event-driven context (and many will do that through .run_in_executor()). If the patch is accepted, it would be wise to write a note in .run_in_executor()'s doc saying that asyncio uses SA_RESTART by default in all its handler and that EINTR is prevented *as long as* no other handlers are registered elsewhere.

The single most common cause of signals is SIGCHLD (in a "normal"
code). Since asyncio setups up the SIGCHLD handler, this should cover
most of the cases (BTW, just set up a SIGCHLD handler in any Python
process spawning subprocesses, and it becomes unusable since EINTR
isn't handled in the stdlib).

> Please answer this question. Under what circumstances can a signal handler interrupt a blocking system call in a thread that is not the main thread?

I answered in my prevous message: POSIX makes no guarantee whatsoever
as to which thread will receive the signal (except of course in case
of synchronous signales like SIGSEGV/SIGFPE). The Linux kernel makes
it best to deliver it to the main thread when possible, but in
certains cases it can't, and other OS just don't bother. See e.g.
issue #19857 for an occurrence on FreeBSD. Also, even the main thread
can sometimes make blocking calls subject to EINTR (e.g. acquiring a
lock).

So the possibility of breakage are real, but if people prefer to wait
& see, that's fine :-)

----------

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

From report at bugs.python.org  Tue Dec  3 20:46:15 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 19:46:15 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1386099975.04.0.528070277149.issue19850@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I've harassed you enough. Sorry. Go ahead and commit this.

----------

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

From report at bugs.python.org  Tue Dec  3 20:51:45 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 19:51:45 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386100305.96.0.51037800725.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think you're looking for the discussion in issue 19017.

IIRC the conclusion is that not only do you not get the same error everywhere, but you get it at different points -- sometimes register() of a bad FD passes and then [Selector.]select() fails, other times register() of a bad FD fails; when the FD is initially good and then gets closed, sometimes select() may fail, sometimes select() will silently ignore the FD. Sometimes unregister() of a closed FD will return False, sometimes True.

Another consequence is that registering an FD, then closing it, then calling select(), then reopening it may keep reporting events for the FD or not.

I think these are all things to call out in a section on caveats or common bugs.

----------

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

From report at bugs.python.org  Tue Dec  3 20:56:19 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Dec 2013 19:56:19 +0000
Subject: [issue19878] PyFile_DecUseCount() SIGSEGV
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <1386100579.05.0.920360169201.issue19878@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry, the Python 2.6 series is now officially retired.  As of 2.6.9, "All official maintenance for Python 2.6, including security patches, has ended."  If you can reproduce the problem with a currently supported version of Python, such as Python 2.7.6 or 3.3.3, please reopen with similar documentation.

http://www.python.org/download/releases/2.6.9/

----------
nosy: +ned.deily
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Dec  3 21:05:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 20:05:14 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386101114.28.0.83173995025.issue19859@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file32950/66c1c9f32567.diff

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

From report at bugs.python.org  Tue Dec  3 21:06:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 20:06:24 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386101184.69.0.0188379986966.issue19859@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan, rhettinger

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

From report at bugs.python.org  Tue Dec  3 21:15:20 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 03 Dec 2013 20:15:20 +0000
Subject: [issue19138] doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no
 detail exists
In-Reply-To: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>
Message-ID: <1386101720.01.0.77308859745.issue19138@psf.upfronthosting.co.za>


Tim Peters added the comment:

I agree this is a bug, and at a first scan your fix looks good.  I'll make it a priority to pay more attention to it now ;-)

----------
assignee:  -> tim.peters

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

From report at bugs.python.org  Tue Dec  3 21:28:49 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Dec 2013 20:28:49 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386102529.86.0.740039134421.issue19859@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/issue19859>
_______________________________________

From report at bugs.python.org  Tue Dec  3 21:28:58 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 03 Dec 2013 20:28:58 +0000
Subject: [issue19862] Unclear xpath caching for custom  namespaces
In-Reply-To: <1385997526.09.0.197144583843.issue19862@psf.upfronthosting.co.za>
Message-ID: <1386102538.68.0.993179452298.issue19862@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

This is a duplicate of issue17011.

----------

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

From report at bugs.python.org  Tue Dec  3 21:30:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 20:30:04 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386102604.95.0.629645382385.issue19859@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Weak references make no sense in most cases when arguments disappear just after function call. For the self argument of a method it makes more sense. Perhaps lru_cache can return not a function, but a descriptor. This will allow implement special processing of first argument.

Or new decorator lru_cache_method should be added.

----------

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

From report at bugs.python.org  Tue Dec  3 21:38:52 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Dec 2013 20:38:52 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386103132.52.0.93617839272.issue19859@psf.upfronthosting.co.za>


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


----------
type: resource usage -> enhancement
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Dec  3 21:47:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Dec 2013 20:47:08 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386103628.17.0.285120539478.issue19859@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps following technique can be used to prevent object's life prolongation:

def spam(self, *args, **kwargs):
    @lru_cache(maxsize=20)
    def spam(foo, bar=1, *, baz=None):
        ...
    self.spam = spam
    return self.spam(*args, **kwargs)

----------

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

From report at bugs.python.org  Tue Dec  3 21:50:13 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Dec 2013 20:50:13 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386103813.56.0.760349818017.issue19859@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think this is an appropriate use of an LRU cache.  There are other ways to "freeze" a method return value (typically by storing the result in an instance).

Here's one way of doing it (taken from the source code for Itty https://pypi.python.org/pypi/itty/0.8.2 ):

class lazyproperty(object):
    """A property whose value is computed only once. """
    def __init__(self, function):
        self._function = function

    def __get__(self, obj, _=None):
        if obj is None:
            return self
        value = self._function(obj)
        setattr(obj, self._function.func_name, value)
        return value

Here is how it is used:

class Request(object):
    """An object to wrap the environ bits in a friendlier way."""

    ...

    @lazyproperty
    def POST(self):
        return self.build_complex_dict()

    ...

----------

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

From report at bugs.python.org  Tue Dec  3 22:01:56 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 21:01:56 +0000
Subject: [issue19878] bz2.BZ2File.__init__() cannot be called twice
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <1386104516.79.0.679265265186.issue19878@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I can reproduce the issue with Python 2.7. The problem is that BZ2File.__init__() doesn't reset the object when __init__() is called twice.

For example, the following script fails with "too many open files" error, before the previous file is not called:
---
import bz2
obj = bz2.BZ2File('bla.bz2')
for loop in range(1024*10):
    obj.__init__('bla.bz2')
---

By the way, why do you call __init__() twice? Why not creating a new object?

BZ2File was rewritten in pure Python in Python 3.3. Python 3.3+ is not affected by this issue.

----------
nosy: +haypo, serhiy.storchaka
resolution: rejected -> 
stage: committed/rejected -> 
status: closed -> open
title: PyFile_DecUseCount() SIGSEGV -> bz2.BZ2File.__init__() cannot be called twice
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Tue Dec  3 22:04:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 21:04:38 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>
Message-ID: <1386104678.21.0.940198705377.issue19879@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I cannot test the issue, imageop cannot be compiled on 64-bit system and is not present in Python 3. (I don't have access to 32-bit system right now.)

Can you reproduce the issue with Python 2.7?

I'm interested by your fuzzer, is it public?

----------
nosy: +haypo, serhiy.storchaka
title: PyCFunction_NewEx() SIGABRT -> imageop: bug in error handler

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

From report at bugs.python.org  Tue Dec  3 22:04:58 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 21:04:58 +0000
Subject: [issue19878] bz2.BZ2File.__init__() cannot be called twice
In-Reply-To: <1386104516.79.0.679265265186.issue19878@psf.upfronthosting.co.za>
Message-ID: <282C92D5BD4B3F49A671ACF096BCE65C0AC121@BUE1EX001.CORE.SEC>


Matthew Bergin added the comment:

I was fuzzing the interpreter otherwise it would init itself

----------

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

From report at bugs.python.org  Tue Dec  3 22:07:12 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 21:07:12 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386104678.21.0.940198705377.issue19879@psf.upfronthosting.co.za>
Message-ID: <282C92D5BD4B3F49A671ACF096BCE65C0AC13A@BUE1EX001.CORE.SEC>


Matthew Bergin added the comment:

I am going to test it against 2.7 a little later on this afternoon.

I typically host all of the code I write at https://github.com/levle but atm the github repo I use to host the project is private. Once I work out some of the kinks I will set it to Public.

----------

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

From report at bugs.python.org  Tue Dec  3 22:09:29 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Dec 2013 21:09:29 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>
Message-ID: <1386104969.93.0.298063421183.issue19879@psf.upfronthosting.co.za>


Ned Deily added the comment:

On 2.7 tip, it fails up front with a TypeError:

  File "/home/nad/PyCFunction.py", line 5, in <module>
    imageop.rgb82rgb(u"%J8CBej >uFBi-",True,8.36)
TypeError: integer argument expected, got float
[18330 refs]

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

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

From report at bugs.python.org  Tue Dec  3 22:13:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 21:13:12 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>
Message-ID: <1386105192.39.0.0906907411058.issue19879@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"I typically host all of the code I write at https://github.com/levle but atm the github repo I use to host the project is private. Once I work out some of the kinks I will set it to Public."

I worked on a Python fuzzer some years ago and fixed a lot of similar crashes in Python. See my fuzzer:
https://bitbucket.org/haypo/fusil/src/tip/fuzzers/fusil-python

It uses the Fusil library:
https://bitbucket.org/haypo/fusil/

@Ned: Did you run the script more than once? It looks like a random bug (Heisenbug).

----------

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

From report at bugs.python.org  Tue Dec  3 22:15:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 21:15:00 +0000
Subject: [issue19817] tracemalloc add a memory limit feature
In-Reply-To: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za>
Message-ID: <1386105300.31.0.676975890583.issue19817@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This feature cannot be used without a reliable PyErr_NoMemory(): I add issue #19835 as a dependency.

----------
dependencies: +Add a MemoryError singleton to fix an unlimited loop when the memory is exhausted

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

From report at bugs.python.org  Tue Dec  3 22:15:32 2013
From: report at bugs.python.org (Matthew Bergin)
Date: Tue, 03 Dec 2013 21:15:32 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386105192.39.0.0906907411058.issue19879@psf.upfronthosting.co.za>
Message-ID: <282C92D5BD4B3F49A671ACF096BCE65C0AC158@BUE1EX001.CORE.SEC>


Matthew Bergin added the comment:

Sweet, I will check it out

----------

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

From report at bugs.python.org  Tue Dec  3 22:16:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 21:16:42 +0000
Subject: [issue19827] Optimize socket.settimeout() and socket.setblocking():
 avoid syscall
In-Reply-To: <1385673009.77.0.328160102824.issue19827@psf.upfronthosting.co.za>
Message-ID: <1386105402.02.0.183983990787.issue19827@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +gvanrossum, neologix, pitrou

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

From report at bugs.python.org  Tue Dec  3 22:16:56 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Dec 2013 21:16:56 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>
Message-ID: <1386105416.48.0.661620873985.issue19879@psf.upfronthosting.co.za>


Ned Deily added the comment:

@Victor: On 2.6, it gets a DeprecationWarning.  On 2.7, that is now a TypeError.

----------

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

From report at bugs.python.org  Tue Dec  3 22:30:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 21:30:23 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386106223.83.0.856117010943.issue19787@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Kristj?n> Only that issue #10517 mentions reasons to keep the old behavior, specifically http://bugs.python.org/issue10517#msg134573 (...)

@Kristj?n: The behaviour of PyThread_set_key() discussed in this issue is unrelated to the pthread bug related to fork() fixed in #10517.

When it comes to threads and fork, I trust neologix because he knows them better than me and he wrote "AFAICT, there's no link".

----------

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

From report at bugs.python.org  Tue Dec  3 22:31:05 2013
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 03 Dec 2013 21:31:05 +0000
Subject: [issue19878] bz2.BZ2File.__init__() cannot be called twice
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <1386106265.54.0.468649941248.issue19878@psf.upfronthosting.co.za>


Nadeem Vawda added the comment:

It appears that this *does* affect 2.7 (though not 3.2, 3.3 or 3.4, fortunately):

    ~/src/cpython/2.7? gdb --ex run --args ./python -c 'import bz2; obj = bz2.BZ2File("/dev/null"); obj.__init__("")'
    ?... snip banner ...?
    Starting program: /home.u/nadeem/src/cpython/2.7/./python -c import\ bz2\;\ obj\ =\ bz2.BZ2File\(\"/dev/null\"\)\;\ obj.__init__\(\"\"\)
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    IOError: [Errno 2] No such file or directory: ''

    Program received signal SIGSEGV, Segmentation fault.
    0x0000000000431d3e in PyFile_DecUseCount (fobj=0x0) at Objects/fileobject.c:89
    89          fobj->unlocked_count--;

----------
assignee:  -> nadeem.vawda
nosy: +nadeem.vawda
stage:  -> needs patch

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

From report at bugs.python.org  Tue Dec  3 22:48:50 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 21:48:50 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386100305.96.0.51037800725.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2oRDroHKZk7-Bitna1ie6w2NtX3X4ypwhR=KAVCThtjA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
>
> I think you're looking for the discussion in issue 19017.
>
> IIRC the conclusion is that not only do you not get the same error everywhere, but you get it at different points -- sometimes register() of a bad FD passes and then [Selector.]select() fails, other times register() of a bad FD fails; when the FD is initially good and then gets closed, sometimes select() may fail, sometimes select() will silently ignore the FD. Sometimes unregister() of a closed FD will return False, sometimes True.
>
> Another consequence is that registering an FD, then closing it, then calling select(), then reopening it may keep reporting events for the FD or not.

Exactly, it's a mess.

> I think these are all things to call out in a section on caveats or common bugs.

What I don't remember was the conclusion: do we want to keep the
current OS-specific behavior, or do we want to try to be tolerant with
misuse?
For example, one possibility would be to ignore errors when
unregistering a file descriptor from epoll: for example, the
selectmodule currently ignore EBADF when unregistering a FD:
"""
        case EPOLL_CTL_DEL:
        /* In kernel versions before 2.6.9, the EPOLL_CTL_DEL
         * operation required a non-NULL pointer in event, even
         * though this argument is ignored. */
        Py_BEGIN_ALLOW_THREADS
        result = epoll_ctl(epfd, op, fd, &ev);
        if (errno == EBADF) {
            /* fd already closed */
            result = 0;
            errno = 0;
        }
"""

IIRC libev and libevent both ignore those errors.

We have to settle on a solution before documenting it.

----------

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

From report at bugs.python.org  Tue Dec  3 22:52:17 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Dec 2013 21:52:17 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1386106223.83.0.856117010943.issue19787@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM027V4vkV33YVUDo4VWrgmREOxSKLMf3cb5=cbbG=te-g@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> STINNER Victor added the comment:
>
> Kristj?n> Only that issue #10517 mentions reasons to keep the old behavior, specifically http://bugs.python.org/issue10517#msg134573 (...)
>
> @Kristj?n: The behaviour of PyThread_set_key() discussed in this issue is unrelated to the pthread bug related to fork() fixed in #10517.
>
> When it comes to threads and fork, I trust neologix because he knows them better than me and he wrote "AFAICT, there's no link".

It's unrelated, but I don't know if changing the current semantics
could break some code, especially involving subinterpreters: that's
why i'd like to have it tested.

But the current behavior is *really* a pain: not having
PyThread_set_key(key, value)
assert(PyThread_get_key(key) == value)

sounds really wrong.

----------

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

From report at bugs.python.org  Tue Dec  3 23:24:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 22:24:36 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386109476.76.0.81750681113.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>>> import selectors, os
>>> r,w=os.pipe()
>>> s=selectors.SelectSelector()
>>> s.register(r, selectors.EVENT_READ)
SelectorKey(fileobj=3, fd=3, events=1, data=None)
>>> os.close(r)
>>> os.close(w)
>>> s.unregister(r)
SelectorKey(fileobj=3, fd=3, events=1, data=None)

SelectSelector.unregister(<closed fd>) doesn't raise any error, so it makes sense to ignore EBADF in EpollSelector.unregister(). What's the point of raising an error here?

If you want a portable behaviour, the file descriptor should be tested (ex: call os.fstat or os.dup). For the "normal" use case, I would not expect a syscall on unregister(), because unregister() may be called just before closing the file descriptor.

Maybe you can explain that in the "caveats" section? Suggestion: "unregister(fd) does not check if fd is closed or not (to get a portable behaviour), os.fstat() or os.dup() can be used to check if the fd is closed or not". Or "unregister(fd) ignores error if the file descriptor is closed".

----------

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

From report at bugs.python.org  Tue Dec  3 23:36:39 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Dec 2013 22:36:39 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1386110199.1.0.197689592902.issue8075@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Just tried installing 2.6.6 on Windows 7 with compile checked and make default unchecked and did not observe any problems (although it did scroll by at high speed, and the windows didn't stay open for me to peruse).

However, since we are no longer releasing binary installers for the 2.6 branch, can this be closed?

----------
nosy: +ethan.furman

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

From report at bugs.python.org  Tue Dec  3 23:41:48 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 03 Dec 2013 22:41:48 +0000
Subject: [issue19138] doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no
 detail exists
In-Reply-To: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>
Message-ID: <1386110508.81.0.468803806686.issue19138@psf.upfronthosting.co.za>


Tim Peters added the comment:

On second thought, I don't want to use a regexp for this.  The mandatory colon _was_ a kind of absolute wall, and the various instances of "[^:]" exploited that to avoid unintended matches.

But "possibly dotted name followed possibly by a colon" is straightforward to get right with a pair of simple string searches, so I'll introduce a new `_strip_exception_details()` function instead.

----------

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

From report at bugs.python.org  Tue Dec  3 23:45:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 22:45:32 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386110732.13.0.93557427052.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Heh, I'd forgotten the behavior of unregister().  It seems that there are two layers to the behavior -- if this FD was never register()ed it will raise; if it was register()ed but has since been close()d it may raise.

For the higher-level APIs in asyncio I chose not to raise from the remove_{reader,writer}() methods -- they return True if something was removed, False if not.  This currently has to be implemented by explicitly asking the selector for the key first.  I.e.:

    def remove_reader(self, fd):
        """Remove a reader callback."""
        try:
            key = self._selector.get_key(fd)
        except KeyError:
            return False
        else:
            mask, (reader, writer) = key.events, key.data
            mask &= ~selectors.EVENT_READ
            if not mask:
                self._selector.unregister(fd)
            else:
                self._selector.modify(fd, mask, (None, writer))

            if reader is not None:
                reader.cancel()
                return True
            else:
                return False

----------

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

From report at bugs.python.org  Tue Dec  3 23:46:04 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 22:46:04 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386110764.16.0.324061357909.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

(What I meant to add was, I'd be happy if unregister() also just used a true/false return.)

----------

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

From report at bugs.python.org  Tue Dec  3 23:46:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 22:46:41 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
Message-ID: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Test attached unittest_leak.py script: you will see MyException.ninstance counter increased up to 10, whereas I expect that MyException is destroyed at TestCase.run() exit.

It looks like a tricky reference cycle between:

- frames
- exc_info local variable of _Outcome.testPartExecutor() context manager
- _Outcome.errors list
- _Outclass instance

Attached unittest_workaround.patch patch works around the issue.

----------
files: unittest_leak.py
messages: 205167
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: unittest: on failure, TestCase.run() keeps a reference to the exception
versions: Python 3.4
Added file: http://bugs.python.org/file32951/unittest_leak.py

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

From report at bugs.python.org  Tue Dec  3 23:46:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 22:46:48 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386110808.38.0.557274300156.issue19880@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file32952/unittest_workaround.patch

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

From report at bugs.python.org  Tue Dec  3 23:48:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 22:48:47 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386110927.04.0.145486554164.issue19880@psf.upfronthosting.co.za>


STINNER Victor added the comment:

contextmanager_leak.py: shorter script to demonstrate the issue.

Replacing "exc_info = sys.exc_info()" with "sys.exc_info()" works around the issue.

----------
Added file: http://bugs.python.org/file32953/contextmanager_leak.py

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

From report at bugs.python.org  Tue Dec  3 23:49:28 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 03 Dec 2013 22:49:28 +0000
Subject: [issue19827] Optimize socket.settimeout() and socket.setblocking():
 avoid syscall
In-Reply-To: <1385673009.77.0.328160102824.issue19827@psf.upfronthosting.co.za>
Message-ID: <1386110968.82.0.995948214832.issue19827@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LGTM.  I know I've written similar code in Python. :-)

----------

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

From report at bugs.python.org  Tue Dec  3 23:58:55 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 03 Dec 2013 22:58:55 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1386111535.21.0.970158446953.issue8075@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As a Windows user myself I'd say close it as it's been the better part of four years since there was a comment here.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Wed Dec  4 00:01:31 2013
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 03 Dec 2013 23:01:31 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1386111691.83.0.140162506513.issue8075@psf.upfronthosting.co.za>


Brian Curtin added the comment:

Time between comments will never be a factor in closing bugs.

If this isn't an issue with 2.7, then we can close it. I'm not near a Windows machine this week as I'm traveling, so I can't check it out for a while.

----------

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

From report at bugs.python.org  Wed Dec  4 00:11:07 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Dec 2013 23:11:07 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1386112267.63.0.504397743716.issue10203@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Patch looks good!  Are documentation changes needed?

----------
keywords: +needs review
stage:  -> patch review

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

From report at bugs.python.org  Wed Dec  4 00:11:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 23:11:16 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386112276.47.0.0214056129322.issue19880@psf.upfronthosting.co.za>


STINNER Victor added the comment:

contextmanager_leak2.py: even simpler example, storing a current frame in a local variable of the frame is enough.

generator_workaround.patch is another workaround: call frame.clear() when at generator exit to explicitly break the reference cycle.

----------
Added file: http://bugs.python.org/file32954/contextmanager_leak2.py

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

From report at bugs.python.org  Wed Dec  4 00:11:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 23:11:22 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386112282.62.0.922411046996.issue19880@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file32955/generator_workaround.patch

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

From report at bugs.python.org  Wed Dec  4 00:34:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 23:34:27 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386113667.06.0.894530784772.issue19880@psf.upfronthosting.co.za>


STINNER Victor added the comment:

frame_ref_cycle.py: if I understood correctly, unittest_leak.py can be simplified to this script. A frame contains a local variable which contains the frame: reference cycle.

----------
Added file: http://bugs.python.org/file32956/frame_ref_cycle.py

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

From report at bugs.python.org  Wed Dec  4 00:43:02 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Tue, 03 Dec 2013 23:43:02 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386114182.74.0.17581807865.issue19859@psf.upfronthosting.co.za>


Radomir Dopieralski added the comment:

The method example is just the most common case where this problem can be easily seen, but not the only one. We indeed use the @cached_property decorator on properties (similar to https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/utils.py#L35), and I've actually written a @memoized_method decorator for methods, that do pretty much what Serhiy suggests (except it's not repeated all over the place, a la copy-pasta, but kept in one decorator). That is fine, and the @cached_property is actually superior, as it avoids a lookup and a check once the value has been calculated.

However, this still doesn't solve the problems that are encountered in practice in actual code, like here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/neutron.py#L735

Here we have a normal function, not a method, that calls a remote API through HTTP (the call is relatively slow, so we definitely want to cache it for multiple invocations). The function takes a ``request`` parameter, because it needs it for authentication with the remote service. The problem we had is that this will keep every single request in memory, because it's referenced by the cache.

Somehow it feels wrong to store the cache on an arbitrary attribute of the function, like the request in this case, and it's easy to imagine a function that takes two such critical arguments.

This is the code that actually made me write the weakref version of the @memoized decorator that I linked initially, and I thought that it could also be useful to have that in Python's caching decorator as an option.

I can understand if you think that this is too much, and that in such tricky situations the programmer should either write their own caching, or rewrite the code to avoid a memory leak. But I am sure that most programmers will not even think about this caveat. I think that we should at least add a note to lru_cache's documentation warning about this scenario and advising them to write their own caching decorators.

----------

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

From report at bugs.python.org  Wed Dec  4 00:45:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Dec 2013 23:45:18 +0000
Subject: [issue19827] Optimize socket.settimeout() and socket.setblocking():
 avoid syscall
In-Reply-To: <1385673009.77.0.328160102824.issue19827@psf.upfronthosting.co.za>
Message-ID: <3dZ0DZ2L99z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 5f0d1aad7322 by Victor Stinner in branch 'default':
Close #19827: On UNIX, setblocking() and settimeout() methods of socket.socket
http://hg.python.org/cpython/rev/5f0d1aad7322

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 00:51:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Dec 2013 23:51:45 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386114705.37.0.215408225149.issue19880@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I found this issue while working the memory limit feature of tracemalloc module (issue #19817). I opened #19835 to workaround an unlimited loop on PyErr_NoMemory() when Python is out of memory.

See also the issue #17807 and the PEP 442 for a similar reference cycle with generators.

----------

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

From report at bugs.python.org  Wed Dec  4 00:57:43 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Tue, 03 Dec 2013 23:57:43 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386115063.48.0.729631692461.issue19859@psf.upfronthosting.co.za>


Radomir Dopieralski added the comment:

Actually, after looking closer, my @memoize_method decorator does something completely different than Serhiy suggested. Still it only solves the common case of methods, and does nothing if you pass your short-lived objects as other parameters than self.

Limiting the cache size is also not a solution in the practical example with request that I linked to in the previous comment, because we can't know in advance how many times per request the function is going to be called, picking an arbitrary number feels wrong and may lead to unexpected behaviors when other fragments of code change (like a sudden slowdown every N calls).

----------

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

From report at bugs.python.org  Wed Dec  4 01:15:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 00:15:10 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <1386116110.89.0.468431746187.issue19880@psf.upfronthosting.co.za>


STINNER Victor added the comment:

unittest_leak.patch: Fix the the initial bug, unittest_leak.py.

I don't think that it's possible to write a generic fix for frame_ref_cycle.py. Storing sys.exc_info() to format it as a traceback later is a common pattern. Clearing a frame at function exit breaks this use case.

----------
nosy: +ezio.melotti
Added file: http://bugs.python.org/file32957/unittest_leak.patch

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

From report at bugs.python.org  Wed Dec  4 01:29:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 00:29:48 +0000
Subject: [issue19757] _tracemalloc.c: compiler warning with gil_state
In-Reply-To: <1385317617.76.0.570657043672.issue19757@psf.upfronthosting.co.za>
Message-ID: <3dZ1Cw1BjYz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 194f74044537 by Victor Stinner in branch 'default':
Close #19757: Cleanup tracemalloc, move
http://hg.python.org/cpython/rev/194f74044537

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 01:48:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 00:48:03 +0000
Subject: [issue19741] tracemalloc: tracemalloc_log_alloc() doesn't check
 _Py_HASHTABLE_SET() return value
In-Reply-To: <1385250424.67.0.149405281139.issue19741@psf.upfronthosting.co.za>
Message-ID: <3dZ1cy4SSJz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 3c34ab550358 by Victor Stinner in branch 'default':
Close #19741: tracemalloc_realloc() does not release the table lock anymore
http://hg.python.org/cpython/rev/3c34ab550358

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

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

From report at bugs.python.org  Wed Dec  4 02:01:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 01:01:00 +0000
Subject: [issue19817] tracemalloc add a memory limit feature
In-Reply-To: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za>
Message-ID: <1386118860.48.0.943514295487.issue19817@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file32958/tracemalloc_memory_limit-2.patch

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

From report at bugs.python.org  Wed Dec  4 02:04:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 01:04:46 +0000
Subject: [issue19817] tracemalloc add a memory limit feature
In-Reply-To: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za>
Message-ID: <1386119086.55.0.0795369219126.issue19817@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_limit.patch: Patch to test the memory_limit on the Python test suite. tracemalloc_memory_limit-2.patch and unittest_leak.patch (of issue #19880) are required to test it.

----------
Added file: http://bugs.python.org/file32959/test_limit.patch

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

From report at bugs.python.org  Wed Dec  4 02:14:44 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 01:14:44 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1386119684.67.0.615587645616.issue11410@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/issue11410>
_______________________________________

From report at bugs.python.org  Wed Dec  4 02:23:06 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 01:23:06 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386120186.79.0.220224983281.issue15518@psf.upfronthosting.co.za>


Changes by Chris Calloway <cbc at chriscalloway.org>:


Removed file: http://bugs.python.org/file30040/issue-15518-1.patch

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

From report at bugs.python.org  Wed Dec  4 02:28:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 01:28:22 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1386120502.51.0.987923336963.issue3208@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been addressed by the PEP 436 (Argument Clinic) which supports annotation per parameter and annotation on the return type. This PEP has been implemented in Python 3.4.

I suggest to close the issue, but I would prefer that Larry closes the issue instead of me, he wrote the PEP.

----------
nosy: +haypo, larry
versions: +Python 3.4 -Python 3.5

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

From report at bugs.python.org  Wed Dec  4 02:42:07 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 01:42:07 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386121327.0.0.928267911848.issue15518@psf.upfronthosting.co.za>


Chris Calloway added the comment:

The promised comments have been added to the patch. The refactoring of the pre-existing tests is not part of this patch. But I'm uploading this now as the patch does fix the issue.

----------
Added file: http://bugs.python.org/file32960/issue-15518-1.patch

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

From report at bugs.python.org  Wed Dec  4 02:45:05 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 04 Dec 2013 01:45:05 +0000
Subject: [issue3208] function annotation for builtin and C function
In-Reply-To: <1214486185.01.0.390328488498.issue3208@psf.upfronthosting.co.za>
Message-ID: <1386121505.23.0.976931110416.issue3208@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Argument Clinic theoretically could support annotations for builtins, though it's never been tested.  I don't know if it makes sense to close this bug yet.

----------

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

From report at bugs.python.org  Wed Dec  4 02:59:59 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 01:59:59 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386122399.31.0.0818802404208.issue15518@psf.upfronthosting.co.za>


Changes by Chris Calloway <cbc at chriscalloway.org>:


Removed file: http://bugs.python.org/file29745/test_filecmp_layouts.rst

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

From report at bugs.python.org  Wed Dec  4 03:00:55 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 02:00:55 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386122455.24.0.555177692978.issue15518@psf.upfronthosting.co.za>


Chris Calloway added the comment:

Reformat the filecmpdata directory layouts diagram.

----------
Added file: http://bugs.python.org/file32961/test_filecmp_layouts.rst

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

From report at bugs.python.org  Wed Dec  4 03:01:59 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 02:01:59 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386122519.81.0.744600669379.issue15518@psf.upfronthosting.co.za>


Changes by Chris Calloway <cbc at chriscalloway.org>:


Removed file: http://bugs.python.org/file29746/test_filecmp_reports.rst

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

From report at bugs.python.org  Wed Dec  4 03:02:55 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 02:02:55 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386122575.93.0.192323091427.issue15518@psf.upfronthosting.co.za>


Chris Calloway added the comment:

Reformat the filecmp test report matrix.

----------
Added file: http://bugs.python.org/file32962/test_filecmp_reports.rst

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

From report at bugs.python.org  Wed Dec  4 03:04:24 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 02:04:24 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386122664.18.0.549848217203.issue15518@psf.upfronthosting.co.za>


Chris Calloway added the comment:

Formatted test directory layout.

----------
Added file: http://bugs.python.org/file32963/layouts.html

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

From report at bugs.python.org  Wed Dec  4 03:05:49 2013
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 04 Dec 2013 02:05:49 +0000
Subject: [issue15518] Provide test coverage for filecmp.dircmp.report methods.
In-Reply-To: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>
Message-ID: <1386122749.26.0.721791746554.issue15518@psf.upfronthosting.co.za>


Chris Calloway added the comment:

Format the martix of test reports.

----------
Added file: http://bugs.python.org/file32964/reports.html

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

From report at bugs.python.org  Wed Dec  4 04:02:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 03:02:19 +0000
Subject: [issue19138] doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no
 detail exists
In-Reply-To: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>
Message-ID: <3dZ4bs6H1gz7LlZ@mail.python.org>


Roundup Robot added the comment:

New changeset c80083ad142d by Tim Peters in branch 'default':
Issue #19138: doctest's IGNORE_EXCEPTION_DETAIL now allows no detail at all.
http://hg.python.org/cpython/rev/c80083ad142d

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

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

From report at bugs.python.org  Wed Dec  4 04:21:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 03:21:39 +0000
Subject: [issue19138] doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no
 detail exists
In-Reply-To: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>
Message-ID: <3dZ52B4jNRz7Ljw@mail.python.org>


Roundup Robot added the comment:

New changeset 5e14a3435f52 by Tim Peters in branch '2.7':
Issue #19138: doctest's IGNORE_EXCEPTION_DETAIL now allows no detail at all.
http://hg.python.org/cpython/rev/5e14a3435f52

----------

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

From report at bugs.python.org  Wed Dec  4 04:24:21 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Dec 2013 03:24:21 +0000
Subject: [issue19138] doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no
 detail exists
In-Reply-To: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>
Message-ID: <1386127461.86.0.564539724649.issue19138@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


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

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

From report at bugs.python.org  Wed Dec  4 04:30:52 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 03:30:52 +0000
Subject: [issue19138] doctest.IGNORE_EXCEPTION_DETAIL doesn't match when no
 detail exists
In-Reply-To: <1380642891.76.0.189533758192.issue19138@psf.upfronthosting.co.za>
Message-ID: <3dZ5Dq49Q0z7Ljw@mail.python.org>


Roundup Robot added the comment:

New changeset 017d7c27a4f6 by Tim Peters in branch '3.3':
Issue #19138: doctest's IGNORE_EXCEPTION_DETAIL now allows no detail at all.
http://hg.python.org/cpython/rev/017d7c27a4f6

----------

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

From report at bugs.python.org  Wed Dec  4 05:18:53 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 04:18:53 +0000
Subject: [issue19878] bz2.BZ2File.__init__() cannot be called twice with
 non-existent file
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <1386130733.93.0.51845262677.issue19878@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch.

----------
keywords: +patch
nosy: +vajrasky
title: bz2.BZ2File.__init__() cannot be called twice -> bz2.BZ2File.__init__() cannot be called twice with non-existent file
Added file: http://bugs.python.org/file32965/fix_segfault_in_bz2_init_non_existent_file.patch

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

From report at bugs.python.org  Wed Dec  4 07:35:05 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 04 Dec 2013 06:35:05 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1386138905.23.0.426454844076.issue10203@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

I guess not, the documentation already states that Row tries to mimic a tuple in most of its features. Probably a MISC/News entry is required.

----------

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

From report at bugs.python.org  Wed Dec  4 07:38:54 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Wed, 04 Dec 2013 06:38:54 +0000
Subject: [issue19881] Fix bigmem pickle tests
Message-ID: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

The bigmem tests for pickle are currently failing for protocol 4. The tests are broken because of an assumption rendered invalid by the frame header. Fixing the tests caught a legitimate bug in the save_bytes function of cpickle.

----------
assignee: alexandre.vassalotti
components: Library (Lib)
files: fix_bigmem_pickle.patch
keywords: patch
messages: 205196
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix bigmem pickle tests
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32966/fix_bigmem_pickle.patch

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

From report at bugs.python.org  Wed Dec  4 08:12:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 07:12:33 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1386141153.65.0.259933053179.issue10203@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I got warning in compiling your patch:

gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -g -O0 -Wall -Wstrict-prototypes -DMODULE_NAME="sqlite3" -DSQLITE_OMIT_LOAD_EXTENSION=1 -IModules/_sqlite -I/usr/include -I./Include -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/usr/local/include -I/home/ethan/Documents/code/python/cpython3.4/Include -I/home/ethan/Documents/code/python/cpython3.4 -c /home/ethan/Documents/code/python/cpython3.4/Modules/_sqlite/row.c -o build/temp.linux-x86_64-3.4-pydebug/home/ethan/Documents/code/python/cpython3.4/Modules/_sqlite/row.o
/home/ethan/Documents/code/python/cpython3.4/Modules/_sqlite/row.c:212:28: warning: initialization from incompatible pointer type [enabled by default]
/home/ethan/Documents/code/python/cpython3.4/Modules/_sqlite/row.c:212:28: warning: (near initialization for ?pysqlite_row_as_sequence.sq_item?) [enabled by default]

$ gcc --version
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2

----------
nosy: +vajrasky

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

From report at bugs.python.org  Wed Dec  4 08:14:17 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 07:14:17 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386141257.58.0.942467543151.issue19509@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'd rather have integration test with a real SSL connection in order to check the entire stack. asyncio doesn't have a test for CERT_REQUIRED yet. The attached patch tests three common cases: missing CA, missing server_hostname and a successful connection with full verification.

----------
Added file: http://bugs.python.org/file32967/asyncio_ssl_verify.patch

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

From report at bugs.python.org  Wed Dec  4 08:15:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 07:15:20 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386141320.71.0.843002717668.issue19509@psf.upfronthosting.co.za>


Christian Heimes added the comment:

PS: The test uses keycert3.pem and pycacert.pem from the 3.4 test directory. keycert3.pem contains privat + public key and is signed by the CA in pycacert.pem.

----------

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

From report at bugs.python.org  Wed Dec  4 08:21:06 2013
From: report at bugs.python.org (Martin Panter)
Date: Wed, 04 Dec 2013 07:21:06 +0000
Subject: [issue19882] Closing a socket when makefile() is used
Message-ID: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>


New submission from Martin Panter:

I think the documentation is rather vague about closing the underlying OS socket. Can someone verify if the following is true (*asterisked* bits are my additions), and maybe update the documentation?

socket.close(): Close the socket *object*. *The underlying file descriptor is also closed, unless there are file objects from makefile() still open.*

socket.makefile(): Closing the file object won?t close the *file descriptor* unless *the original socket object and any other file objects have already been closed*.

----------
assignee: docs at python
components: Documentation
messages: 205200
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Closing a socket when makefile() is used
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec  4 08:21:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 07:21:12 +0000
Subject: [issue15883] Add Py_errno to work around multiple CRT issue
In-Reply-To: <1347111302.92.0.306708953598.issue15883@psf.upfronthosting.co.za>
Message-ID: <1386141672.93.0.218120179562.issue15883@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
status: open -> pending
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Wed Dec  4 08:21:57 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 04 Dec 2013 07:21:57 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1386141717.67.0.582966005345.issue10203@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Thanks, Vajrasky! Here's an updated patch.

----------
Added file: http://bugs.python.org/file32968/sqlite2.patch

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

From report at bugs.python.org  Wed Dec  4 08:24:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 07:24:30 +0000
Subject: [issue17134] Use Windows' certificate store for CA certs
In-Reply-To: <1360078143.8.0.938168290854.issue17134@psf.upfronthosting.co.za>
Message-ID: <1386141870.96.0.3951946578.issue17134@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The tests are passing again. Thanks!

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

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

From report at bugs.python.org  Wed Dec  4 08:30:57 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 07:30:57 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386142257.56.0.314611787296.issue19509@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I left my comment on the review. I forgot to mail the review.

----------
nosy: +vajrasky

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

From report at bugs.python.org  Wed Dec  4 08:43:46 2013
From: report at bugs.python.org (Martin Panter)
Date: Wed, 04 Dec 2013 07:43:46 +0000
Subject: [issue11563] test_urllibnet is triggering a ResourceWarning
In-Reply-To: <1300229857.13.0.482456727872.issue11563@psf.upfronthosting.co.za>
Message-ID: <1386143026.57.0.584577732118.issue11563@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the fix for this bug only works if it gets the server to respond with a ?Connection: close? header itself. I opened Issue 19524 because I was seeing keep-alive responses using chunked encoding that still trigger a socket leak.

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

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

From report at bugs.python.org  Wed Dec  4 09:09:07 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 08:09:07 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386144547.33.0.679668157106.issue12837@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'd like to see the warning silenced before 3.4 gets released, too. How about a check like

   (Py_ssize_t)msg->msg_controllen > 0xffffffffL

instead? I'd also be fine with pragmas.

----------
nosy: +christian.heimes
versions: +Python 3.4

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

From report at bugs.python.org  Wed Dec  4 09:26:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 08:26:03 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386145563.52.0.635722045171.issue19881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Alexandre, if you have enough memory, could you please check that memory requirements for bigmem tests are correct?

----------

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

From report at bugs.python.org  Wed Dec  4 09:35:53 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Dec 2013 08:35:53 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386146153.5.0.324093891158.issue18840@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage: needs patch -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Wed Dec  4 09:53:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 08:53:18 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386147198.45.0.83995142665.issue19881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with new bigmem limits. Currently bigmem tests consumes much more memory than they declare. This can cause memory swapping and too long time of test's running.

----------
Added file: http://bugs.python.org/file32969/pickle_bigmem_limits.patch

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

From report at bugs.python.org  Wed Dec  4 10:32:47 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Dec 2013 09:32:47 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386149567.55.0.184984400702.issue19859@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Limiting the cache size is also not a solution in the 
> practical example with request that I linked to in the
> previous comment, because we can't know in advance how
> many times per request the function is going to be called, 
> picking an arbitrary number feels wrong and may lead to 
> unexpected behaviors

This suggests that you don't really want an LRU cache which is specifically designed to limit the cache size by expelling the
least recently used entry.

At its heart, the cache decorator is all about mapping a fixed inputs to fixed outputs.  The memory conservation comes from the replacement strategy and an option to clear the cache entirely.

The reason that my answer and Serhiy's answer don't fit your needs is that it isn't clear what you really want to do.  I think you should move this discussion to StackOverflow so others can help you tease-out your actual needs and suggest appropriate solutions.  Ideally, you should start with real use cases rather than focusing on hacking-up the LRU cache implementation.

----------

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

From report at bugs.python.org  Wed Dec  4 10:34:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 09:34:05 +0000
Subject: [issue19883] overflow in zipexport.c
Message-ID: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>


New submission from Christian Heimes:

MSVC complains about "conversion from 'Py_ssize_t' to 'long', possible loss of data" in zipimport.c. header_offset is a Py_ssize_t but fseek() only takes a long. On 64bit Windows Py_ssize_t is a 64bit data type but long is still a 32bit data type.

It's safe to assume that the header will be smaller than 2 GB for the next couple of years. :)

----------
assignee: brett.cannon
files: zipimport_header_offset.patch
keywords: patch
messages: 205209
nosy: brett.cannon, christian.heimes
priority: low
severity: normal
stage: patch review
status: open
title: overflow in zipexport.c
type: compile error
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32970/zipimport_header_offset.patch

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

From report at bugs.python.org  Wed Dec  4 10:57:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 09:57:49 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386151069.82.0.541926480726.issue19883@psf.upfronthosting.co.za>


STINNER Victor added the comment:

read_directory() uses fseek() and ftell() which don't support offset larger than LONG_MAX (2 GB on 32-bit system).  I don't know if it's an issue. What happens if the file is longer?

"header_offset += arc_offset;" can overflow or not? This instuction looks weird.

    header_position = ftell(fp);
    ...
    header_offset = get_long((unsigned char *)endof_central_dir + 16);
    arc_offset = header_position - header_offset - header_size;
    header_offset += arc_offset;

If I computed correctly, the final line can be replaced with:

    arc_offset = header_position - header_offset - header_size;
    header_offset = header_position - header_size;

(It is weird to reuse header_position for two different values, a new variable may be added.)

Instead of checking that "header_offset > LONG_MAX", it may be safer to check that:

 - header_size >= 0
 - header_offset >= 0
 - header_offset + header_size <= LONG_MAX ---> header_offset <= LONG_MAX - header_size
 - arc_offset >= 0 ---> header_position >= header_offset + header_size
 - header_offset > 0 ---> header_position >= header_size

If all these values must be positive according to ZIP format, get_long() may be replaced with get_ulong() to simplify these checks.

----------
nosy: +haypo
title: overflow in zipexport.c -> Integer overflow in zipimport.c

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

From report at bugs.python.org  Wed Dec  4 11:00:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 10:00:20 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386151220.22.0.118582847036.issue19883@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also zipfile.py which is probably more correct than zipimport.c: zipfile uses for example "L" format for struct.unpack (*unsigned* long) to decode header fields.

----------

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

From report at bugs.python.org  Wed Dec  4 11:05:10 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 04 Dec 2013 10:05:10 +0000
Subject: [issue19687] Fixes for elementtree integer overflow
In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za>
Message-ID: <1386151510.82.0.0761406464442.issue19687@psf.upfronthosting.co.za>


Christian Heimes added the comment:

New patch with fixes for element_ass_subscr().

----------
Added file: http://bugs.python.org/file32971/elementtree_overflow2.patch

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

From report at bugs.python.org  Wed Dec  4 11:15:20 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Wed, 04 Dec 2013 10:15:20 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386152120.21.0.486045339018.issue19859@psf.upfronthosting.co.za>


Radomir Dopieralski added the comment:

Thank you for your attention. I'm actually quite happy with the solution we have, it works well. That's actually I thought that it may be worthwhile to try and push it upstream to Python. I can totally understand why you don't want to add too much to the standard library, after all, everything you add there has to stay forever. So please consider this patch abandoned.

But I think it's would be still worthwhile to add a note to the lru_cache's documentation, saying something like:

"""
Warning! lru_cache will keep references to all the arguments for which it keeps cached values, which prevents them from being freed from memory when there are no other references. This can lead to memory leaks when you call a function with lru_cache on a lot of short-lived objects.
"""

I suppose you can come up with a nicer phrasing.

----------

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

From report at bugs.python.org  Wed Dec  4 11:21:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 10:21:05 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386152465.08.0.919395250783.issue19883@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/issue19883>
_______________________________________

From report at bugs.python.org  Wed Dec  4 11:35:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 10:35:11 +0000
Subject: [issue19687] Fixes for elementtree integer overflow
In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za>
Message-ID: <1386153311.54.0.795300084052.issue19687@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also *first* patch in issue16986.

----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

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

From report at bugs.python.org  Wed Dec  4 11:57:27 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 04 Dec 2013 10:57:27 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1386154647.93.0.833822004818.issue7105@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

That's the spirit, Guido :)
I just think people are being extra careful after the "regression" introduced in 2.7.5.
However, IMHO we must never let the odd mistake scare us from making necessary moves.
Unless Antoine explicitly objects, I think I'll submit my patch from november and we'll just watch what happens.

----------

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

From report at bugs.python.org  Wed Dec  4 11:58:28 2013
From: report at bugs.python.org (Martin Panter)
Date: Wed, 04 Dec 2013 10:58:28 +0000
Subject: [issue13797] Allow objects implemented in pure Python to export PEP
 3118 buffers
In-Reply-To: <1326709751.32.0.965094376059.issue13797@psf.upfronthosting.co.za>
Message-ID: <1386154708.69.0.192970689066.issue13797@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/issue13797>
_______________________________________

From report at bugs.python.org  Wed Dec  4 12:27:38 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 04 Dec 2013 11:27:38 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386156458.48.0.0615683717953.issue19787@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

+1
Why don't we just fix this and see where the chips fall?

----------

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

From report at bugs.python.org  Wed Dec  4 13:06:16 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 04 Dec 2013 12:06:16 +0000
Subject: [issue19884] Importing readline produces erroneous output
Message-ID: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

A simple reproducer:

python -c 'import readline' | xxd
0000000: 1b5b 3f31 3033 3468                      .[?1034h

This was reported at [1] and originally at [2]. The readline maintainer suggests [3] using:

rl_variable_bind ("enable-meta-key", "off");

which was introduced in readline 6.1. Do you think it'd be safe to add the above line?

Thanks.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=880393
[2] https://bugzilla.redhat.com/show_bug.cgi?id=593799
[3] http://lists.gnu.org/archive/html/bug-readline/2011-04/msg00009.html

----------
components: Extension Modules
messages: 205217
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Importing readline produces erroneous output
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Dec  4 13:15:28 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 Dec 2013 12:15:28 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1386152120.21.0.486045339018.issue19859@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f4728tAAOz-t2HDFu3dRA=STXbB_cKXawnCThophokXQ@mail.gmail.com>


Nick Coghlan added the comment:

On 4 December 2013 20:15, Radomir Dopieralski <report at bugs.python.org> wrote:
> But I think it's would be still worthwhile to add a note to the lru_cache's documentation, saying something like:
>
> """
> Warning! lru_cache will keep references to all the arguments for which it keeps cached values, which prevents them from being freed from memory when there are no other references. This can lead to memory leaks when you call a function with lru_cache on a lot of short-lived objects.
> """

Umm, that's part of the operational definition of a value based cache
- it needs to keep things alive, so that if a different instance shows
up with the same value, it will still get a cache hit.

We're willing to put warnings in the docs for cases where it's easy to
inadvertently introduce a security vulnerability, but not for
situations like this where using a container inappropriately may cause
it to keep objects alive that you didn't intend to keep alive.

----------

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

From report at bugs.python.org  Wed Dec  4 13:40:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 Dec 2013 12:40:38 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386160838.54.0.583691501221.issue18840@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Since this particular tutorial section was written long before the json module was part of the standard library, I think it makes sense to switch now we have the option.

pickle is definitely a useful tool, but now that JSON is available by default, it's now one to escalate to if JSON doesn't meet your needs, rather than the one to use by default.

Chris's patch looks generally good to me, although I think it could use a second paragraph in the pickle section. Perhaps something like:

"""JSON is much simpler to use safely than pickle, and offers broader interoperability with programs written in other languages. However, pickle has the advantage of supporting a much wider range of Python object types, including executable code, which means it can handle use cases that JSON can't (like sending code to another process for execution)"


This simpler/safer/less powerful API/technique vs more powerful/more dangerous API/technique trade-off is a fairly common one, so I think it's a good thing to have a concrete example of it in the tutorial rather than just dropping the reference to pickle entirely.

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

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

From report at bugs.python.org  Wed Dec  4 14:49:00 2013
From: report at bugs.python.org (Radomir Dopieralski)
Date: Wed, 04 Dec 2013 13:49:00 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386164940.42.0.656235217756.issue19859@psf.upfronthosting.co.za>


Radomir Dopieralski added the comment:

> Umm, that's part of the operational definition of a value based cache
> - it needs to keep things alive, so that if a different instance shows
> up with the same value, it will still get a cache hit.

If it only kept the return value alive, that wouldn't be a problem, it's indeed intuitively obvious that it has to do that in order to work. But what many people miss to notice is that it also keeps any arguments that were passed to the function alive. This is not intuitive, and as I demonstrated with my patch, not even necessary, so I think it might be worthwhile to at least mention this little implementation quirk.

----------

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

From report at bugs.python.org  Wed Dec  4 15:12:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 14:12:05 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386166325.56.0.00770534827561.issue19881@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file32969/pickle_bigmem_limits.patch

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

From report at bugs.python.org  Wed Dec  4 15:14:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 14:14:25 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386166465.76.0.339677917561.issue19881@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file32972/pickle_bigmem_limits.patch

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

From report at bugs.python.org  Wed Dec  4 16:00:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 15:00:53 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1386169253.42.0.711104876465.issue19884@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I can't reproduce under Ubuntu 13.10. Is this Red Hat-specific?

(according to Dave, """This is a readline bug; it looks like it should not emit those characters when stdout is not a tty""")

----------
nosy: +dmalcolm, pitrou
versions: +Python 3.4

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

From report at bugs.python.org  Wed Dec  4 16:03:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 15:03:57 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386169437.36.0.332546003783.issue19881@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(we did have a bigmem buildbot but the bigmem tests tended to crash it, as some memory estimates are widely inaccurate)

----------

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

From report at bugs.python.org  Wed Dec  4 16:05:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 15:05:11 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386169511.45.0.402384861433.issue19859@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Just adding a note in the documentation sounds enough.

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

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

From report at bugs.python.org  Wed Dec  4 16:07:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 15:07:27 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <1386169647.14.0.70233105325.issue7105@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm ok with the backport.

----------

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

From report at bugs.python.org  Wed Dec  4 16:09:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 15:09:49 +0000
Subject: [issue7060] test_multiprocessing dictionary changed size errors and
 hang
In-Reply-To: <1254706857.52.0.165302672738.issue7060@psf.upfronthosting.co.za>
Message-ID: <1386169789.36.0.0612890131746.issue7060@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Okay, let's say it is fixed. Adding Richard to nosy so that he can review the issue if he's interested.

----------
resolution:  -> out of date
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Wed Dec  4 16:25:12 2013
From: report at bugs.python.org (John W. O'Brien)
Date: Wed, 04 Dec 2013 15:25:12 +0000
Subject: [issue19875] test_getsockaddrarg occasional failure
In-Reply-To: <1386065859.81.0.4295023541.issue19875@psf.upfronthosting.co.za>
Message-ID: <1386170712.25.0.820876390784.issue19875@psf.upfronthosting.co.za>


John W. O'Brien added the comment:

For reference:

CPython code comments showing that this may be an anticipated problem:

http://hg.python.org/cpython/file/0830670a9d9d/Lib/test/support/__init__.py#l562

An example of another project that seems to have tackled this problem in the way neologix suggests:

http://openvswitch.org/pipermail/dev/2013-April/026430.html

I am inclined to frame this issue as a choice between LBYL (try to predict, subject to the race, whether a port will be available) and EAFP (blindly try a few random high ports before inferring failure).

----------
nosy: +neirbowj

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

From report at bugs.python.org  Wed Dec  4 16:51:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 15:51:24 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1386172284.46.0.946869149164.issue19884@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Reproducible under Fedora 18.

$ ./python -c "import readline" | hexdump -C
00000000  1b 5b 3f 31 30 33 34 68                           |.[?1034h|
00000008

$ TERM=dumb ./python -c "import readline" | hexdump -C

----------
nosy: +vajrasky

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

From report at bugs.python.org  Wed Dec  4 17:33:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 16:33:46 +0000
Subject: [issue19885] lzma.LZMAFile.__init__() segfault when __init__ with
 non-existent file after executing the constructor
Message-ID: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

[sky at localhost cutecat]$ cat /tmp/lzma_segfault.py 
import lzma
file = lzma.LZMAFile("/tmp/file.lzma", "w")
file.write(b"xxxx")
file.close()
with lzma.LZMAFile("/tmp/file.lzma", "w") as f:
    f.__init__("non-existent")
[sky at localhost cutecat]$ python /tmp/lzma_segfault.py 
Segmentation fault (core dumped)

See also issue19878.

I'll provide the patch tomorrow.

----------
components: Extension Modules
messages: 205229
nosy: nadeem.vawda, vajrasky
priority: normal
severity: normal
status: open
title: lzma.LZMAFile.__init__() segfault when __init__ with non-existent file after executing the constructor
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Dec  4 17:48:37 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 04 Dec 2013 16:48:37 +0000
Subject: [issue19885] lzma segfault when __init__ with non-existent file after
 executing the constructor (Python 2.7)
In-Reply-To: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za>
Message-ID: <1386175717.17.0.866072369059.issue19885@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
title: lzma.LZMAFile.__init__() segfault when __init__ with non-existent file after executing the constructor -> lzma segfault when __init__ with non-existent file after executing the constructor (Python 2.7)

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

From report at bugs.python.org  Wed Dec  4 18:05:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Dec 2013 17:05:43 +0000
Subject: [issue19885] lzma segfault when __init__ with non-existent file after
 executing the constructor (Python 2.7)
In-Reply-To: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za>
Message-ID: <1386176743.91.0.692491885465.issue19885@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/issue19885>
_______________________________________

From report at bugs.python.org  Wed Dec  4 19:23:26 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Dec 2013 18:23:26 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386181406.73.0.331177759645.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I just ran into a live case of the platform differences here.  Check out http://bugs.python.org/review/19509/ (issue 19509).  Christian uploaded a patch for asyncio, and when I tested it I got a double traceback and a hang.  This could have been avoided if the unregister() call for the closed FD had been silent instead of raising.

I think that the proper fix might have been not to close the socket, but nevertheless this failure confused everyone -- the author of the patch thought it had to do with the SSL version, I was initially confused by the first half of the traceback (which turned out to be expected, this was in an assertRaises() call), and I spent half an hour in pdb to track down the real cause.

----------

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

From report at bugs.python.org  Wed Dec  4 19:24:43 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Dec 2013 18:24:43 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386181483.21.0.893720850422.issue19509@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

See my messages on the review.  Is it absolutely necessary to close the socket when the hostname verification fails?

----------

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

From report at bugs.python.org  Wed Dec  4 19:42:51 2013
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 04 Dec 2013 18:42:51 +0000
Subject: [issue19885] lzma segfault when __init__ with non-existent file after
 executing the constructor (Python 2.7)
In-Reply-To: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za>
Message-ID: <1386182571.87.0.956221038393.issue19885@psf.upfronthosting.co.za>


Nadeem Vawda added the comment:

To clarify, which version(s) does this affect? I have not been able to
reproduce against 3.4, and 2.7 does not included the lzma module in the
first place.

----------

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

From report at bugs.python.org  Wed Dec  4 20:09:06 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Dec 2013 19:09:06 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386184146.18.0.588608097024.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The more I think about this the more I believe unregister() should catch the OSError (but not the KeyError).

Every unregister() implementation starts by calling super().unregister(key), which has a side effect (it removes the key from the _fd_to_key dict).

I believe that once this side effect has happened the unregister() call should return with success even if the kqueue syscall fails with OSError.

A further refinement could be to skip the kqueue syscall *if* the registered object is in fact an object with a fileno() method and not a bare FD, and the object is closed -- we should be able to tell that by calling its fileno() method, which should return -1 or None if it is closed.  (But this would be mostly an optimization -- and a safety guard in case the FD has been reused for a different object.)

I don't know how poll and epoll behave under these circumstances, but given that only the Kqueue-based asyncio test failed I think those don't raise when the FD has been closed.

If you are not amenable to this fix I will have to catch the OSError in Tulip's remove_reader(), e.g. like this:

            try:
                if not mask:
                    self._selector.unregister(fd)
                else:
                    self._selector.modify(fd, mask, (None, writer))
            except OSError:
                # unregister()/modify() may or may not raise this if
                # the FD is closed -- it depends on what type of
                # selector is used.
                pass

(and repeated in remove_writer()).

----------

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

From report at bugs.python.org  Wed Dec  4 20:14:09 2013
From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=)
Date: Wed, 04 Dec 2013 19:14:09 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386184449.8.0.927985090954.issue18840@psf.upfronthosting.co.za>


Westley Mart?nez added the comment:

Sounds good to me.

----------

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

From report at bugs.python.org  Wed Dec  4 20:17:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 19:17:00 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386184620.19.0.893102247761.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Correction: you can't pickle executable code, you can pickle references to well-known objects (by name):

>>> def f(): pass
... 
>>> pickle.dumps(f)
b'\x80\x03c__main__\nf\nq\x00.'
>>> pickle.dumps(f.__code__)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <class 'code'>: attribute lookup code on builtins failed

----------

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

From report at bugs.python.org  Wed Dec  4 20:30:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 19:30:13 +0000
Subject: [issue19886] Better estimated memory requirements for bigmem tests
Message-ID: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some bigmem tests actually consume much more memory than declare. This can cause swapping and too long time of test run. Here is a patch which improves estimates.

----------
components: Tests
files: bigmem_tests.patch
keywords: patch
messages: 205236
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Better estimated memory requirements for bigmem tests
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32973/bigmem_tests.patch

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

From report at bugs.python.org  Wed Dec  4 20:30:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 19:30:35 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386185435.5.0.888922110999.issue19881@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file32972/pickle_bigmem_limits.patch

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

From report at bugs.python.org  Wed Dec  4 20:31:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 19:31:21 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386185481.83.0.13552224741.issue19881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patch about bigmem limits was moved to issue19886.

----------

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

From report at bugs.python.org  Wed Dec  4 20:32:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 19:32:16 +0000
Subject: [issue19886] Better estimated memory requirements for bigmem tests
In-Reply-To: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za>
Message-ID: <1386185536.19.0.82193198082.issue19886@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Why did you compute those estimates? When coming up with factors such as 3.3 or 3.57 (!), it would be nice to add a comment to explain the reasoning.

(otherwise, thanks a lot for doing this)

----------

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

From report at bugs.python.org  Wed Dec  4 20:42:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 19:42:21 +0000
Subject: [issue19886] Better estimated memory requirements for bigmem tests
In-Reply-To: <1386185413.56.0.459107954756.issue19886@psf.upfronthosting.co.za>
Message-ID: <1386186141.07.0.348785180047.issue19886@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These are experimental values. I hacked tests and ran them with less sizes (using `ulimit -v` to hard limit memory size). And then I had approximated measured values.

On Windows values can be larger (due different memory management).

----------

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

From report at bugs.python.org  Wed Dec  4 20:46:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 19:46:25 +0000
Subject: [issue19882] Closing a socket when makefile() is used
In-Reply-To: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>
Message-ID: <1386186385.08.0.147564979002.issue19882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your observations are right, indeed. I'll make the doc changes.

----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 2.7

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

From report at bugs.python.org  Wed Dec  4 20:46:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 19:46:29 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <3dZVtX2TVTz7LkS@mail.python.org>


Roundup Robot added the comment:

New changeset b6fce698e467 by Christian Heimes in branch 'default':
Issue #19509: Don't close the socket in do_handshake() when hostname verification fails.
http://hg.python.org/cpython/rev/b6fce698e467

----------

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

From report at bugs.python.org  Wed Dec  4 21:12:02 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 Dec 2013 20:12:02 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386187922.12.0.643284009006.issue19871@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Oddly, with all of the strictness in JSON, the exponent-marker "e"
> can be upper- or lower-case

I'd guess that the aim is that common floating-point output formats from a variety of languages are valid JSON.  That would also explain why both '+' and '-' are allowed on the exponent, but only '-' on the significand, and why leading zeros are permitted on the exponent but not the significand.

----------

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

From report at bugs.python.org  Wed Dec  4 21:15:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 20:15:59 +0000
Subject: [issue19882] Closing a socket when makefile() is used
In-Reply-To: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>
Message-ID: <3dZWXZ1Z3gz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset e10bb7c1b8f8 by Antoine Pitrou in branch '3.3':
Issue #19882: tweak docs for socket.close()
http://hg.python.org/cpython/rev/e10bb7c1b8f8

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

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

From report at bugs.python.org  Wed Dec  4 21:16:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 20:16:23 +0000
Subject: [issue19882] Closing a socket when makefile() is used
In-Reply-To: <1386141666.2.0.800726480915.issue19882@psf.upfronthosting.co.za>
Message-ID: <1386188183.96.0.0966615545052.issue19882@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed, thanks!

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

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

From report at bugs.python.org  Wed Dec  4 21:20:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Dec 2013 20:20:56 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386188456.27.0.195373213735.issue19871@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/issue19871>
_______________________________________

From report at bugs.python.org  Wed Dec  4 21:46:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 20:46:45 +0000
Subject: [issue19887] Path.resolve() fails on deep symlinks
Message-ID: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a script which success with os.path.realpath(), but fails with pathlib.Path.resolve(). The `readlink -f` also success with these examples.

----------
components: Library (Lib)
files: pathlib_resolve_test.py
messages: 205245
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Path.resolve() fails on deep symlinks
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32974/pathlib_resolve_test.py

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

From report at bugs.python.org  Wed Dec  4 22:00:35 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 04 Dec 2013 21:00:35 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386190835.83.0.0342667169752.issue19871@psf.upfronthosting.co.za>


Tim Peters added the comment:

We should adhere to the json spec, but there's no harm (and some real good!) in the docs pointing out notable cases where json and Python syntax differ.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Wed Dec  4 22:09:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Dec 2013 21:09:27 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1386191367.67.0.560927268868.issue19871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are too many cases where json and Python syntax differ. Final comma("[1, 2,]"), non-string keys ({1: 2}), tuples ("(1, 2)"), leading zeros ("0001"), hexadecimal integers ("0xaf"), escapes of astral characters('"\U0001d504"'), single quotes ("'spam'"), octal escape codes ("\015"), etc, etc...

----------

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

From report at bugs.python.org  Wed Dec  4 22:24:57 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Dec 2013 21:24:57 +0000
Subject: [issue19859] functools.lru_cache keeps objects alive forever
In-Reply-To: <1385980067.33.0.547233710394.issue19859@psf.upfronthosting.co.za>
Message-ID: <1386192297.05.0.592197052182.issue19859@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm not in favor of filling the docs with warnings like this.  It tends to make everything sound dangerous even when the tools are doing exactly what they are supposed to do.

Every container (except for the weakref containers) keeps their references alive.  That is how Python works.  The LRU cache is no more special in this regard than a dictionary, list, or set.   In addition, the older entries get flushed-out and freed as the LRU cache gets newer entries.

[Radomir Dopieralski]
> So please consider this patch abandoned.

Marking this as closed.

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

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

From report at bugs.python.org  Wed Dec  4 22:41:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 Dec 2013 21:41:32 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386193292.51.0.273630506982.issue16669@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't know if it's worth reopening this, but I had a need for generating docs including attribute docstrings for a namedtuple class using Sphinx, and I noticed a few things...

(1) Regarding there not being demand: There's a StackOverflow question for this with 17 "ups" on the question and 22 on the best answer: http://stackoverflow.com/questions/1606436/adding-docstrings-to-namedtuples-in-python

(2) The default autodocs produced by sphinx look dreadful (e.g. https://www.dropbox.com/s/nakxsslhb588tu1/Screenshot%202013-12-04%2013.29.13.png) -- note the duplication of the class name, the line break before the signature, and the listing of attributes in alphabetical order with useless boilerplate.  Here's what I would *like* to produce: (though there's probably too much whitespace :-): https://www.dropbox.com/s/j11uismbeo6rrzx/Screenshot%202013-12-04%2013.31.44.png

(3) In Python 2.7 you can't assign to the __doc__ class attribute.

I would really appreciate some way to set the docstring for the class as a whole as well as for each property, so they come out correct in Sphinx (and help()), preferably without having to manually assign doc strings or write the class by hand without using namedtuple at all.  (The latter will become very verbose, each property has to look like this:

    @property
    def handle(self):
        """The datastore handle (a string)."""
        return self[1]
)

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Wed Dec  4 23:06:07 2013
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Dec 2013 22:06:07 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
Message-ID: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

It seems that a particular code sequence causes memory corruption (but not a crash so far) in the interpreter. I've attached a test case that fails assertion on python3.2 (tested on current amd64 12.04 builds) and works on python3.3 (tested on current amd64 14.04 builds and i386 fedora 19 builds).

The attached test program shows how the bug is actually triggered by using a for loop to iterate over key, value in namespace.items() inside a metaclass __new__() method that does nothing else apart from that.

----------
components: Interpreter Core
files: bug.py
messages: 205250
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__
type: security
versions: Python 3.2
Added file: http://bugs.python.org/file32975/bug.py

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

From report at bugs.python.org  Wed Dec  4 23:06:52 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 22:06:52 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386194812.92.0.141791919971.issue19888@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/issue19888>
_______________________________________

From report at bugs.python.org  Wed Dec  4 23:08:22 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 22:08:22 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386194902.46.0.58895556582.issue19888@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Note that just iterating over namespace doesn't trigger the problem, e.g. instead of 

    for name, value in namespace.items(): pass

using

    list(namespace.items())

seems to work.

----------

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

From report at bugs.python.org  Wed Dec  4 23:10:17 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 22:10:17 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386195017.97.0.94623781337.issue19888@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Also seems to be triggered on 2.7 (with appropriate syntax adjustments in bug.py)

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

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

From report at bugs.python.org  Wed Dec  4 23:10:55 2013
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Dec 2013 22:10:55 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386195055.18.0.841722537623.issue19888@psf.upfronthosting.co.za>


Zygmunt Krynicki added the comment:

2.7 test program

----------
Added file: http://bugs.python.org/file32976/issue-19888.py27.py

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

From report at bugs.python.org  Wed Dec  4 23:20:26 2013
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Dec 2013 22:20:26 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386195626.68.0.552702769368.issue19888@psf.upfronthosting.co.za>


Zygmunt Krynicki added the comment:

Experimenting with a few modifications lead to the following observations:

1) objects with short names (defined inside the Obj class) tend to be ignored and don't trigger the bug
2) Longer names tend to trigger the bug, ordering is not deterministic
3) Calling __new__ before iterating over namespace makes the problem go away, it seems to be related to the for loop more than to anything else

----------

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

From report at bugs.python.org  Wed Dec  4 23:22:25 2013
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Dec 2013 22:22:25 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386195745.11.0.584848096583.issue19888@psf.upfronthosting.co.za>


Zygmunt Krynicki added the comment:

This is not a bug, name spills out of for ... loop and then gets passed to __new__

----------

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

From report at bugs.python.org  Wed Dec  4 23:24:04 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 04 Dec 2013 22:24:04 +0000
Subject: [issue19889] Revision information missing in Python 2.6.9
Message-ID: <1386195844.48.0.422896325461.issue19889@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

Not sure whether this can be considered a bug, but Python 2.6.7 for example showed the build revision in the sys.version:

>>> sys.version
'2.6.7 (r267:88850, Feb  9 2012, 18:56:05) \n[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]]'

whereas Python 2.6.9 does not:

>>> sys.version
'2.6.9 (unknown, Dec  4 2013, 18:39:21) \n[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]]'

----------
components: Build
messages: 205256
nosy: lemburg
priority: normal
severity: normal
status: open
title: Revision information missing in Python 2.6.9
versions: Python 2.6

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

From report at bugs.python.org  Wed Dec  4 23:24:06 2013
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Dec 2013 22:24:06 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386195846.06.0.00690928224756.issue19888@psf.upfronthosting.co.za>


Changes by Zygmunt Krynicki <zygmunt.krynicki at canonical.com>:


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

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

From report at bugs.python.org  Wed Dec  4 23:28:13 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 22:28:13 +0000
Subject: [issue19888] possible memory corruption caused by for-loop iteration
 over namespace.items() in a metaclass defining __new__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386196093.64.0.731055264932.issue19888@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

D'oh! Should have looked closer. ;)

----------

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

From report at bugs.python.org  Wed Dec  4 23:30:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Dec 2013 22:30:13 +0000
Subject: [issue19839] bz2: regression wrt supporting files with trailing
 garbage after EOF
In-Reply-To: <1385806619.04.0.329117891617.issue19839@psf.upfronthosting.co.za>
Message-ID: <3dZZWS07crz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset c5349a560703 by Nadeem Vawda in branch '3.3':
#19839: Fix regression in bz2 module's handling of non-bzip2 data at EOF.
http://hg.python.org/cpython/rev/c5349a560703

New changeset bec2033ee2ec by Nadeem Vawda in branch '3.3':
#19839: Fix lzma module's handling of non-lzma data at EOF.
http://hg.python.org/cpython/rev/bec2033ee2ec

New changeset 1f1498fe50e5 by Nadeem Vawda in branch 'default':
Closes #19839: Fix regression in bz2 module's handling of non-bzip2 data at EOF.
http://hg.python.org/cpython/rev/1f1498fe50e5

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Dec  4 23:31:42 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 04 Dec 2013 22:31:42 +0000
Subject: [issue19866] tests aifc,
 sunau and wave failures on a fresh Win64 installation
In-Reply-To: <1386094888.36.0.514185485927.issue19866@psf.upfronthosting.co.za>
Message-ID: <529FAD83.6080501@email.de>


Francisco Mart?n Brugu? added the comment:

On 12/03/2013 07:21 PM, Zachary Ware wrote:
>
> Zachary Ware added the comment:
>
> Francis, would you like to work on a patch for this?  The change should go in Tools/msi/msi.py, if I'm not mistaken.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue19866>
> _______________________________________
>
please go ahead

----------

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

From report at bugs.python.org  Wed Dec  4 23:35:34 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 04 Dec 2013 22:35:34 +0000
Subject: [issue19889] Revision information missing in Python 2.6.9
In-Reply-To: <1386195844.48.0.422896325461.issue19889@psf.upfronthosting.co.za>
Message-ID: <1386196534.88.0.952052853689.issue19889@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  4 23:58:05 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 22:58:05 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386197885.89.0.187651990808.issue19888@psf.upfronthosting.co.za>


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


----------
title: possible memory corruption caused by for-loop iteration over namespace.items() in a metaclass defining __new__ -> type.__new__() name argument is ignored

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

From report at bugs.python.org  Wed Dec  4 23:58:15 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 22:58:15 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386197895.94.0.0769574916019.issue19888@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  5 00:01:11 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 23:01:11 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386198071.94.0.277892770274.issue19888@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

At best, this is an undocumented (afaict) change in behavior in 3.3.  Let's boil it down:

-----snip snip-----
class Type(type):
    def __new__(mcls, name, bases, namespace):
        return super().__new__(mcls, 'foo', bases, namespace)

class Obj(metaclass=Type):
    def __init__(self, **kwargs):
        pass

print(repr(Obj))
-----snip snip-----

In <= 3.2, this prints <class '__main__.foo'>

In >= 3.3 this prints <class '__main__.Obj'>

So, clearly this is a change in behavior.  Was it intended?  If so, it's undocumented - I can find no mention of it in Misc/NEWS or What's New in 3.3.  I suspect it is unintended.

----------

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

From report at bugs.python.org  Thu Dec  5 00:01:17 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 04 Dec 2013 23:01:17 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386198077.25.0.335233686789.issue19888@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  5 00:04:12 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 04 Dec 2013 23:04:12 +0000
Subject: [issue19890] Typo in multiprocessing docs
Message-ID: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>


New submission from Antony Lee:

The docs for multiprocessing refer to BaseProxy._callMethod() while it should be _callmethod.

----------
assignee: docs at python
components: Documentation
messages: 205261
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Typo in multiprocessing docs
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Dec  5 00:17:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 23:17:37 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386199057.1.0.531491491058.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is https://bitbucket.org/pitrou/pathlib/issue/9/pathresolve-fails-on-complex-symlinks

As noted there:

"""It's a ENAMETOOLONG error when calling readlink(), because there are many "." components. This is really an edge case caused by the specific test setup, I don't think you'd have that many "." components in real-world use."""

----------
priority: normal -> low
title: Path.resolve() fails on deep symlinks -> Path.resolve() ENAMETOOLONG on pathologic symlinks

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

From report at bugs.python.org  Thu Dec  5 00:30:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Dec 2013 23:30:27 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1386199827.46.0.542214076478.issue19775@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for the patch! Some comments:

1. It should path objects as well as str objects.
2. I don't think you have to call resolve() here.
3. you should probably test what happens when one of the files doesn't exist
4. you need to update the documentation too

----------

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

From report at bugs.python.org  Thu Dec  5 01:17:13 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 05 Dec 2013 00:17:13 +0000
Subject: [issue19889] Revision information missing in Python 2.6.9
In-Reply-To: <1386195844.48.0.422896325461.issue19889@psf.upfronthosting.co.za>
Message-ID: <1386202633.3.0.41556155256.issue19889@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I think this is due to the switch from Subversion to Mercurial, which if I'm reading PEP 385 and remembering correctly, happened about the time of Python 2.6.7.  IIRC, we released that source tarball from Subversion so you're seeing svn build number.  When we switched to Mercurial, it was decided not to fix sys.version to understand hg version numbers, since we were in source-only security-only mode.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Dec  5 01:24:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 00:24:34 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386203074.57.0.848074738492.issue19888@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  5 01:28:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 00:28:33 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386203312.99.0.744742145609.issue19888@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Barry: that's because __name__ is 'foo' while __qualname__ is 'Obj'.

I'm gonna close the bug, since it's invalid.

----------
nosy: +pitrou
resolution:  -> invalid

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

From report at bugs.python.org  Thu Dec  5 01:29:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 00:29:15 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386203355.79.0.857458642062.issue19888@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(you can open a new issue for the __name__ / __qualname__ discrepancy, though)

----------

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

From report at bugs.python.org  Thu Dec  5 01:31:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 00:31:23 +0000
Subject: [issue19885] lzma segfault when __init__ with non-existent file after
 executing the constructor (Python 2.7)
In-Reply-To: <1386174826.17.0.707477231335.issue19885@psf.upfronthosting.co.za>
Message-ID: <1386203483.84.0.649032760136.issue19885@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Wait, you're right. I have not been able to reproduce this under Python downloaded from Python.org.

[sky at localhost cpython2.7]$ ./python
Python 2.7.6+ (2.7:ae9fb85ab4e0, Dec  5 2013, 08:24:11) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lzma
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named lzma
[40709 refs]

The python is from Fedora itself. Maybe I did some funky stuff in my Fedora installation. Let me check this first and report to you later.

[sky at localhost cpython2.7]$ python
Python 2.7.3 (default, Aug  9 2012, 17:23:57) 
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lzma
>>> lzma
<module 'lzma' from '/usr/lib64/python2.7/site-packages/lzma.so'>

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

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

From report at bugs.python.org  Thu Dec  5 01:34:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 00:34:28 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386203668.55.0.301811688511.issue12837@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is there any point in littering the source code to avoid platform-specific warnings? The difference is probably that some fields are defined unsigned on OS X while they're signed on other platforms.

(also, your patch has lots of unrelated changes)

----------

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

From report at bugs.python.org  Thu Dec  5 02:40:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Dec 2013 01:40:20 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386207620.89.0.520050652004.issue16669@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy: I am not familiar with C PyStructSequence and how an instance of one appears in Python code. I agree that more methods should have docstrings.

Guido:
1. I posted on SO the simple Py 3 solution that replaces the previously posted wrapper solutions needed for Py 2.

2. Much of what you do not like is standard Sphinx/help behavior that would be unchanged by Serhiy's patch. The first line for a class is always "class <classname>(<base_classes>)". The first line is followed by the docstring, so the class name is repeated if and only if it is repeated in the docstring (as for list, see below). The __new__/__init__ signature is given here if and only it is in the docstring. Otherwise, one has to look down for the method. The method signatures are never on the first line. Examples:

>>> help(list)
Help on class list in module builtins:

class list(object)
 |  list() -> new empty list
 |  list(iterable) -> new list initialized from iterable's items
...
>>> class C:
        "doc string"
	def __init__(self, a, b): pass

>>> help(C)
Help on class C in module __main__:

class C(builtins.object)
 |  doc string
 |
 |  Methods defined here:
 |  
 |  __init__(self, a, b)
...

3. ?? Python 3 has many improvements and we will add more.
---

I am still of the opinion that property usage should be a mostly transparent implementation detail. Point classes could have 4 instance attributes: x, y, r, and theta, with a particular implementation using 0 to 4 properties.  All attributes should be documented regardless of the number of properties, which currently means listing them in the class docstring. A library could have more than one than one implementation.

As for named tuples, I believe (without trying) that the name to index mapping could be done with __gettattr__ and a separate dict. If so, there would be no property docstrings and hence no field docstrings to worry about ;-).
---

There have been requests for data attribute docstrings (without the bother and inefficiency of replacing a simple attribute with a property). Since such a docstring would have to be attached to the fixed attribute name, rather than the variable attribute value, I believe a string subclass would suffice, to be used as needed. The main problem is a decent syntax to add a docstring to a simple (assignment) statement.  

If the general problem were solved, I would choose Serhiy's option B for namedtuple.

----------

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

From report at bugs.python.org  Thu Dec  5 02:59:52 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 05 Dec 2013 01:59:52 +0000
Subject: [issue19888] type.__new__() name argument is ignored
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386208792.9.0.709353221793.issue19888@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/issue19888>
_______________________________________

From report at bugs.python.org  Thu Dec  5 04:03:17 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 03:03:17 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1386212597.93.0.276037259685.issue19775@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Thanks for the review!

Attached the patch addressing the request by Antoine.

----------
Added file: http://bugs.python.org/file32977/pathlib_samefile_v3.patch

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

From report at bugs.python.org  Thu Dec  5 04:05:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 03:05:23 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1386212723.88.0.451467304554.issue19775@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file32977/pathlib_samefile_v3.patch

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

From report at bugs.python.org  Thu Dec  5 04:05:43 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 03:05:43 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1386212743.51.0.182932868424.issue19775@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file32978/pathlib_samefile_v3.patch

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

From report at bugs.python.org  Thu Dec  5 04:07:28 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 03:07:28 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1386212848.53.0.600552089806.issue19775@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file32978/pathlib_samefile_v3.patch

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

From report at bugs.python.org  Thu Dec  5 04:07:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 03:07:34 +0000
Subject: [issue19775] Provide samefile() on Path objects
In-Reply-To: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>
Message-ID: <1386212854.72.0.639443865533.issue19775@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file32979/pathlib_samefile_v3.patch

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

From report at bugs.python.org  Thu Dec  5 05:05:52 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 04:05:52 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1386207620.89.0.520050652004.issue16669@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLVeJdy_6p+56rvzaXX0eAAVmHDdso_YeCYPtVSjyuXYA@mail.gmail.com>


Guido van Rossum added the comment:

On Wed, Dec 4, 2013 at 5:40 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> 1. I posted on SO the simple Py 3 solution that replaces the previously posted wrapper solutions needed for Py 2.

Thanks, that will give people some pointers for Python 3. We need
folks to upvote it. :-)

> 2. Much of what you do not like is standard Sphinx/help behavior that would be unchanged by Serhiy's patch. The first line for a class is always "class <classname>(<base_classes>)".

Maybe for help(), but the Sphinx docs look better for most classes.
Compare my screen capture with the first class on this page:
https://www.dropbox.com/static/developers/dropbox-python-sdk-1.6-docs/index.html
The screen capture looks roughly like this (note this is two lines and
the word DatastoreInfo is repeated -- that wasn't line folding):

class dropbox.datastore.DatastoreInfo
    DatastoreInfo(id, handle, rev, title, mtime)

whereas for non-namedtuple classes it looks like this:

class dropbox.client.DropboxClient(oauth2_access_token, locale=None,
rest_client=None)?

I understand that part of this is due to the latter class having an
__init__ with a reasonable docstring, but the fact remains that
namedtuple's default docstring produces poorly-looking documentation.

> The first line is followed by the docstring, so the class name is repeated if and only if it is repeated in the docstring (as for list, see below). The __new__/__init__ signature is given here if and only it is in the docstring. Otherwise, one has to look down for the method. The method signatures are never on the first line. Examples:
>
>>>> help(list)
> Help on class list in module builtins:
>
> class list(object)
>  |  list() -> new empty list
>  |  list(iterable) -> new list initialized from iterable's items
> ...
>>>> class C:
>         "doc string"
>         def __init__(self, a, b): pass
>
>>>> help(C)
> Help on class C in module __main__:
>
> class C(builtins.object)
>  |  doc string
>  |
>  |  Methods defined here:
>  |
>  |  __init__(self, a, b)
> ...

Yeah, help() is different than Sphinx. (As a general remark I find the
help() output way too verbose with its endless listing of all the
built-in behaviors.)

> 3. ?? Python 3 has many improvements and we will add more.
> ---
>
> I am still of the opinion that property usage should be a mostly transparent implementation detail.

What does that mean?

> Point classes could have 4 instance attributes: x, y, r, and theta, with a particular implementation using 0 to 4 properties.  All attributes should be documented regardless of the number of properties, which currently means listing them in the class docstring. A library could have more than one than one implementation.

For various reasons (like consistency with other classes) I *really*
want the property docstrings on the individual properties, not in the
class docstring. Here's a screenshot of what I want:

https://www.dropbox.com/s/70zfapz8pcz9476/Screenshot%202013-12-04%2019.57.36.png

I obtained this by abandoning the namedtuple and hand-coding
properties -- the resulting class uses 4 lines (+ 1 blank) of
boilerplate per property instead of just one line of docstring per
property.

>
> As for named tuples, I believe (without trying) that the name to index mapping could be done with __gettattr__ and a separate dict. If so, there would be no property docstrings and hence no field docstrings to worry about ;-).

I'm not sure what you are proposing here -- a patch to namedtuple or a
work-around? I think namedtuple is too valuable to abandon. It not
only saves a lot of code, it captures the regularity of the code. (If
I have a class with 5 similar-looking methods it's easy to overlook a
subtle difference in one of them.)

> ---
>
> There have been requests for data attribute docstrings (without the bother and inefficiency of replacing a simple attribute with a property). Since such a docstring would have to be attached to the fixed attribute name, rather than the variable attribute value, I believe a string subclass would suffice, to be used as needed. The main problem is a decent syntax to add a docstring to a simple (assignment) statement.

Sphinx actually has a syntax for this already. In fact, it has three:
it allwos a comment before or on the class variable starting with
"#:", or a docstring immediately following. Check out this
documentation for the autodoc extension:
http://sphinx-doc.org/ext/autodoc.html#directive-autoattribute

> If the general problem were solved, I would choose Serhiy's option B for namedtuple.

If you're referring to this:

    Point = namedtuple('Point', [('x', 'absciss'), ('y', 'ordinate')],
                       doc='Point: 2-dimensional coordinate')

I'd love it!

----------

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

From report at bugs.python.org  Thu Dec  5 05:11:35 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 04:11:35 +0000
Subject: [issue19776] Provide expanduser() on Path objects
In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za>
Message-ID: <1386216695.22.0.721882459181.issue19776@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Documentation, please (Doc/library/pathlib.rst)!

This is the docstring of Path.cwd.

"""Return a new path pointing to the current working directory
(as returned by os.getcwd()).
"""

This is the docstring of Path.expanduser.
""" Return a new path with expanded ~ and ~user constructs.
"""

Perhaps we need to add "(as returned by os.path.expanduser)"?

----------
nosy: +vajrasky

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

From report at bugs.python.org  Thu Dec  5 05:22:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 04:22:10 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
Message-ID: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ sudo adduser --no-create-home cutecat
Adding user `cutecat' ...
Adding new group `cutecat' (1007) ...
Adding new user `cutecat' (1005) with group `cutecat' ...
Not creating home directory `/home/cutecat'.
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
Changing the user information for cutecat
Enter the new value, or press ENTER for the default
	Full Name []: 
	Room Number []: 
	Work Phone []: 
	Home Phone []: 
	Other []: 
Is the information correct? [Y/n] Y

$ su cutecat
Password: 

$ ./python
Python 3.4.0b1 (default:1f1498fe50e5, Dec  5 2013, 09:48:25) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
Error in atexit._run_exitfuncs:
FileNotFoundError: [Errno 2] No such file or directory
$

Python 2.7 and 3.3 do not throw error.

$ ./python
Python 3.3.3+ (3.3:07425df887b5+, Dec  2 2013, 12:27:06) 
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
[60778 refs]
[41580 refs]
$

$ ./python
Python 2.7.6+ (2.7:181ced5bf0be, Dec  4 2013, 11:23:42) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
$

----------
components: Extension Modules
messages: 205273
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Exiting Python REPL prompt with user without home directory throws error in atexit._run_exitfuncs
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  5 06:26:55 2013
From: report at bugs.python.org (Julian Gindi)
Date: Thu, 05 Dec 2013 05:26:55 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1386221214.99.0.982320557337.issue19683@psf.upfronthosting.co.za>


Julian Gindi added the comment:

I agree that they should be implemented. I'll fill them in and submit a patch in a day or so.

----------
nosy: +Julian.Gindi

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

From report at bugs.python.org  Thu Dec  5 06:39:22 2013
From: report at bugs.python.org (Jean Jordaan)
Date: Thu, 05 Dec 2013 05:39:22 +0000
Subject: [issue19892] register.send_metadata fails with EOFError: EOF when
 reading a line
Message-ID: <1386221962.86.0.663845329774.issue19892@psf.upfronthosting.co.za>


New submission from Jean Jordaan:

On Ubuntu 12.04, using https://pypi.python.org/pypi/zest.releaser

./bin/release
[...]
INFO: Running: /.../bin/python setup.py register sdist --formats=zip upload
Showing first few lines...
running register
running egg_info
writing requirements to Products.CMFPlomino.egg-info/requires.txt
writing Products.CMFPlomino.egg-info/PKG-INFO
writing namespace_packages to Products.CMFPlomino.egg-info/namespace_packages.txt
...
Showing last few lines...
    self.send_metadata()
  File "/home/jean/zope/plomino/Python-2.7/lib/python2.7/distutils/command/register.py", line 149, in send_metadata
    choice = raw_input()
EOFError: EOF when reading a line

----------
components: Distutils
messages: 205275
nosy: neaj
priority: normal
severity: normal
status: open
title: register.send_metadata fails with EOFError: EOF when reading a line
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec  5 06:45:41 2013
From: report at bugs.python.org (Jean Jordaan)
Date: Thu, 05 Dec 2013 05:45:41 +0000
Subject: [issue19892] register.send_metadata fails with EOFError: EOF when
 reading a line
In-Reply-To: <1386221962.86.0.663845329774.issue19892@psf.upfronthosting.co.za>
Message-ID: <1386222341.09.0.575004208097.issue19892@psf.upfronthosting.co.za>


Jean Jordaan added the comment:

A closer look suggests this is an issue in zest.releaser

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

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

From report at bugs.python.org  Thu Dec  5 07:25:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Dec 2013 06:25:10 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386224710.39.0.826486583806.issue16669@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> I find the help() output way too verbose with its endless listing of all the built-in behaviors.)

Then you might agree to a patch, on a separate issue. Let's set help aside for the moment.

I am familiar with running Sphinx on .rst files, but not on docstrings.
It looks like the docstrings use .rst markup. (Is this allowed in the  stdlib?)  (The output looks good enough for a first draft of a tkinter class/method reference, which I would like to work on.)

> I understand that part of this [signature after class name] is due to the latter class having an __init__ with a reasonable docstring

If dropbox.client is written in Python, as I presume, then I strongly suspect that the signature part of
  class dropbox.client.DropboxClient(
    oauth2_access_token, locale=None, rest_client=None)
comes from an inspect module method that examines the function attributes other than .__doc__. If so, DropboxClient.__init__ docstring is irrelevant to the above. You could test by commenting it out and rerunning the doc build.

The inspect methods do not work on C-coded functions (unless Argument Clinic has fixed this for 3.4), which is why signatures are put in the docstrings for C-coded objects. For C-coded classes, it is put in the class docstring rather than the class.__init__ docstring.

> but the fact remains that namedtuple's default docstring produces poorly-looking documentation.

'x.__init__(...) initializes x; see help(type(x)) for signature'

This is standard boilerplate for C-coded .__init__.__doc__.
Raymond just copied it.

>>> int.__init__.__doc__
'x.__init__(...) initializes x; see help(type(x)) for signature'
>>> list.__init__.__doc__
'x.__init__(...) initializes x; see help(type(x)) for signature'

I will try to explain 'property transparency/equivalence' in another post, when I am fresher, and after reading the autodoc reference, so you can understand enough to agree or not. My reference to a possible alternate implementation of named tuple was part of the failed explanation of 'property transparency'. I am not proposing a change now.

----------

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

From report at bugs.python.org  Thu Dec  5 07:35:49 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 05 Dec 2013 06:35:49 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1386203668.55.0.301811688511.issue12837@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1Pk7Vzho43qeVWiKdaFS5cjt_tTjgtEP4hMNO2EsiHyQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

I agree with Antoine.
Silencing warning is fine, as long as it's not to the detriment of
clarity (see Debian Openssl's vulnerability extreme example).

----------

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

From report at bugs.python.org  Thu Dec  5 07:53:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 06:53:46 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <3dZnhT66yvz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 1a945fb875bf by Christian Heimes in branch 'default':
Issue 19509: Don't call match_hostname() twice in http.client.
http://hg.python.org/cpython/rev/1a945fb875bf

----------

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

From report at bugs.python.org  Thu Dec  5 09:23:09 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 05 Dec 2013 08:23:09 +0000
Subject: [issue19776] Provide expanduser() on Path objects
In-Reply-To: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za>
Message-ID: <1386231789.31.0.984125784777.issue19776@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Thanks, Vajrasky! Here's the new version of the patch.

----------
Added file: http://bugs.python.org/file32980/pathlib1.patch

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

From report at bugs.python.org  Thu Dec  5 09:29:34 2013
From: report at bugs.python.org (Wim)
Date: Thu, 05 Dec 2013 08:29:34 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1386232174.77.0.313949566116.issue17088@psf.upfronthosting.co.za>


Wim added the comment:

I have run into this a few times although it is only recently that I've convinced myself I understood the XML namespace spec well enough to know what the right behavior was. (I came to the same interpretation as silverbacknet.)

I have attached a patch which I believe fixes (and tests) the problem.

----------
keywords: +patch
nosy: +wiml
Added file: http://bugs.python.org/file32981/bug17088_1.patch

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

From report at bugs.python.org  Thu Dec  5 09:37:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 08:37:24 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386232644.14.0.708924493941.issue19891@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


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

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

From report at bugs.python.org  Thu Dec  5 09:48:34 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Thu, 05 Dec 2013 08:48:34 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386233314.8.0.452991722427.issue19881@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file32982/fix_bigmem_pickle_2.patch

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

From report at bugs.python.org  Thu Dec  5 09:49:36 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 05 Dec 2013 08:49:36 +0000
Subject: [issue19343] Expose FreeBSD-specific APIs in resource module
In-Reply-To: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>
Message-ID: <1386233376.83.0.981454152502.issue19343@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Should this be tagged for Python 3.5?

----------

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

From report at bugs.python.org  Thu Dec  5 09:50:23 2013
From: report at bugs.python.org (Roman)
Date: Thu, 05 Dec 2013 08:50:23 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
Message-ID: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>


New submission from Roman:

I wrote small test program using Python cApi, and found some memory issues while working on it. I checked it with valgrind. (test code and valgrind output appended)
Maybe I'm doing something wrong, but most of the problem occurs durring Py_Initialize. I've checked python3.2.5 and 3.3.3 version. The latest version is much less confusing, but I can still see there something nasty. 
I would be grateful if you could look at this, and tell me If I'm doing something wrong, or if I can do something to prevent this memory issues.

----------
files: pytest.tgz
messages: 205283
nosy: rstarostecki
priority: normal
severity: normal
status: open
title: Python cApi memory problem. Py_Initialize memory leak
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file32983/pytest.tgz

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

From report at bugs.python.org  Thu Dec  5 10:26:49 2013
From: report at bugs.python.org (Richard Milne)
Date: Thu, 05 Dec 2013 09:26:49 +0000
Subject: [issue19894] zipfile ignores deflate level settings in zipinfo object
Message-ID: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>


New submission from Richard Milne:

Reading the pkzip APPNOTE and the documentation for the zipfile module, I was under the impression that I could set the DEFLATE compression level, on a per-file basis, for each file added to an archive, by setting the appropriate bits in zipinfo.flag_bits.

You can't. Hence the attached patch, which updates the docs, tests and module source to enables this ability and makes the user aware of it.

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
files: zipfileinfo.diff
keywords: patch
messages: 205284
nosy: docs at python, rmilne
priority: normal
severity: normal
status: open
title: zipfile ignores deflate level settings in zipinfo object
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32984/zipfileinfo.diff

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

From report at bugs.python.org  Thu Dec  5 11:05:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 10:05:11 +0000
Subject: [issue7105] weak dict iterators are fragile because of unpredictable
 GC runs
In-Reply-To: <1255282166.4.0.13882602695.issue7105@psf.upfronthosting.co.za>
Message-ID: <3dZsxL3FGsz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 03fcc12282fc by Kristj?n Valur J?nsson in branch '2.7':
Issue #7105:  weak dict iterators are fragile because of unpredictable GC runs
http://hg.python.org/cpython/rev/03fcc12282fc

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

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

From report at bugs.python.org  Thu Dec  5 11:35:46 2013
From: report at bugs.python.org (Antony Lee)
Date: Thu, 05 Dec 2013 10:35:46 +0000
Subject: [issue19895] Cryptic error when subclassing multiprocessing classes
Message-ID: <1386239746.14.0.69431016666.issue19895@psf.upfronthosting.co.za>


New submission from Antony Lee:

Classes defined in the multiprocessing module are in fact functions that call the internally defined class constructor with the "ctx" argument properly set; because of that, trying to subclass them yields a (very?) cryptic error message:

>>> import multiprocessing as m, multiprocessing.queues as q
>>> class Q(m.Queue): pass # normal attempt fails
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function() argument 1 must be code, not str
>>> class Q(q.Queue): pass # that one works fine
... 

I guess the error message here could be improved, and the limitation and the workaround should be mentioned in the docs.  Even better would be to  have real classes directly in the multiprocessing module rather than wrappers, although I believe that would require sorting out some circular import issues.

----------
components: Library (Lib)
messages: 205286
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Cryptic error when subclassing multiprocessing classes
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  5 12:13:04 2013
From: report at bugs.python.org (Antony Lee)
Date: Thu, 05 Dec 2013 11:13:04 +0000
Subject: [issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes
Message-ID: <1386241984.18.0.408310965726.issue19896@psf.upfronthosting.co.za>


New submission from Antony Lee:

multiprocessing.sharedctypes was not updated after the "q" (c_longlong) and "Q" (c_ulonglong) typecodes were added to the array module (the docs claim that the typecode can be "one character typecode of the kind used by the array module").  The attached patch (just adding an entry to the typecode-to-type dict, as well as some more tests) fixes the issue.

----------
components: Library (Lib)
files: multiprocessing-longlong.patch
keywords: patch
messages: 205287
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Exposing "q" and "Q" to multiprocessing.sharedctypes
versions: Python 3.4
Added file: http://bugs.python.org/file32985/multiprocessing-longlong.patch

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

From report at bugs.python.org  Thu Dec  5 12:40:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 11:40:42 +0000
Subject: [issue19896] Exposing "q" and "Q" to multiprocessing.sharedctypes
In-Reply-To: <1386241984.18.0.408310965726.issue19896@psf.upfronthosting.co.za>
Message-ID: <1386243642.17.0.345267127248.issue19896@psf.upfronthosting.co.za>


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


----------
nosy: +sbt
stage:  -> patch review

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

From report at bugs.python.org  Thu Dec  5 12:41:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 11:41:06 +0000
Subject: [issue19895] Cryptic error when subclassing multiprocessing classes
In-Reply-To: <1386239746.14.0.69431016666.issue19895@psf.upfronthosting.co.za>
Message-ID: <1386243666.96.0.756408210741.issue19895@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  5 12:41:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 11:41:56 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386243716.67.0.710640192169.issue19893@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, skrah

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

From report at bugs.python.org  Thu Dec  5 12:56:57 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 05 Dec 2013 11:56:57 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386244617.27.0.851721307656.issue19893@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Did you use --suppressions=Misc/valgrind-python.supp?

----------

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

From report at bugs.python.org  Thu Dec  5 13:00:28 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 05 Dec 2013 12:00:28 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386244828.61.0.019495848654.issue19893@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Also, you have zero "definitely lost". "possibly lost" is not
particularly informative in the context of running Python:
These are almost certainly false positives.

----------

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

From report at bugs.python.org  Thu Dec  5 13:32:54 2013
From: report at bugs.python.org (Roman)
Date: Thu, 05 Dec 2013 12:32:54 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386246774.49.0.00925753251383.issue19893@psf.upfronthosting.co.za>


Roman added the comment:

I didn't use --suppressions=Misc/valgrind-python.supp before . (But I've done it now). Nothing important has changed.
I understand that "possibly lost is not particularly informative". I'm  rather worried about "Invalid read of size 4" etc. Isn't it potentially dangerous? I thought it is some kind of memory corruption, isn't it?

----------

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

From report at bugs.python.org  Thu Dec  5 13:35:58 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 05 Dec 2013 12:35:58 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386246774.49.0.00925753251383.issue19893@psf.upfronthosting.co.za>
Message-ID: <20131205123558.GA28388@sleipnir.bytereef.org>


Stefan Krah added the comment:

Did you compile Python --with-valgrind?

----------

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

From report at bugs.python.org  Thu Dec  5 13:48:49 2013
From: report at bugs.python.org (Roman)
Date: Thu, 05 Dec 2013 12:48:49 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386247729.03.0.881534381852.issue19893@psf.upfronthosting.co.za>


Roman added the comment:

I've just done it. Python 3.3.3 --with-valgrind. I can't see the difference. Output appended.

----------
Added file: http://bugs.python.org/file32986/vgrind3.3.3vc.out

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

From report at bugs.python.org  Thu Dec  5 13:59:32 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 05 Dec 2013 12:59:32 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1386248372.58.0.141018602307.issue19884@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

I can also reproduce it on Arch Linux. It seems that the bad characters are only output if env variable TERM starts with "xterm".

----------

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

From report at bugs.python.org  Thu Dec  5 14:05:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2013 13:05:41 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386248741.26.0.839977735328.issue19887@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Path.resolve() also fails when last link is absolute.

mkdir testdir
ln -s 0/0 testdir/1
ln -s 1/1 testdir/2
ln -s "$(readlink -f testdir)" testdir/0

Path('testdir/2').resolve() fails:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pathlib.py", line 1017, in resolve
    s = self._flavour.resolve(self)
  File "/home/serhiy/py/cpython/Lib/pathlib.py", line 273, in resolve
    raise RuntimeError("Symlink loop from %r" % cur)
RuntimeError: Symlink loop from '/home/serhiy/py/cpython/testdir/0'

Here is a patch which implements an algorithm similar to the algorithm used in posixpath.realpath().

----------
keywords: +patch
priority: low -> high
stage:  -> patch review
Added file: http://bugs.python.org/file32987/pathlib_resolve.patch

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

From report at bugs.python.org  Thu Dec  5 14:08:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2013 13:08:31 +0000
Subject: [issue19894] zipfile ignores deflate level settings in zipinfo object
In-Reply-To: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>
Message-ID: <1386248911.87.0.929612185081.issue19894@psf.upfronthosting.co.za>


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


----------
nosy: +alanmcintyre, serhiy.storchaka
stage:  -> patch review

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

From report at bugs.python.org  Thu Dec  5 14:20:04 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 Dec 2013 13:20:04 +0000
Subject: [issue19897] Use python as executable instead of python3 in Python 2
 docs
Message-ID: <1386249604.0.0.838114607356.issue19897@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: fix-example-site.diff
keywords: patch
nosy: berker.peksag, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Use python as executable instead of python3 in Python 2 docs
versions: Python 2.7
Added file: http://bugs.python.org/file32988/fix-example-site.diff

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

From report at bugs.python.org  Thu Dec  5 14:36:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Dec 2013 13:36:05 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386250565.94.0.00387423164745.issue19891@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is presumably due to the new default enabling of readline, where it is trying to save the history file when it exits.

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

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

From report at bugs.python.org  Thu Dec  5 14:47:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 05 Dec 2013 13:47:50 +0000
Subject: [issue19687] Fixes for elementtree integer overflow
In-Reply-To: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za>
Message-ID: <1386251270.17.0.969488691637.issue19687@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks. I left some comments in the code review tool

----------

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

From report at bugs.python.org  Thu Dec  5 14:51:27 2013
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 05 Dec 2013 13:51:27 +0000
Subject: [issue18235] _sysconfigdata.py wrong on AIX installations
In-Reply-To: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za>
Message-ID: <1386251487.07.0.516662840549.issue18235@psf.upfronthosting.co.za>


Michael Haubenwallner added the comment:

Kindly ping. Do you prefer another report for the aix-absbuilddir patch as this one is already closed?

----------

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

From report at bugs.python.org  Thu Dec  5 14:55:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 13:55:16 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386251716.73.0.57969512906.issue19891@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For the record, why did you close as invalid?

----------

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

From report at bugs.python.org  Thu Dec  5 14:58:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Dec 2013 13:58:02 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386247729.03.0.881534381852.issue19893@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZhWN=ovT1N5d0r2nLHQUHp21mCCBzQpYJqA3KAnQvOJA@mail.gmail.com>


STINNER Victor added the comment:

You shoud configure --with-valgrind *and* use the suppression list, or
disable pymalloc using configure.

Victor

----------

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

From report at bugs.python.org  Thu Dec  5 14:58:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Dec 2013 13:58:56 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386251936.32.0.148006484583.issue19891@psf.upfronthosting.co.za>


R. David Murray added the comment:

Not sure who you meant by 'you', but just in case you meant me, Vajrasky was the one who closed it.

----------

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

From report at bugs.python.org  Thu Dec  5 15:14:27 2013
From: report at bugs.python.org (Roman)
Date: Thu, 05 Dec 2013 14:14:27 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386252867.73.0.168422360765.issue19893@psf.upfronthosting.co.za>


Roman added the comment:

I compiled python --with-valgrind --without-pymalloc, and used valgrind with suppressions. 

valgrind --suppressions=../Misc/valgrind-python.supp --leak-check=full --show-reachable=no --show-possibly-lost=no --track-origins=yes --log-file=vgrindNext.out ./test

----------
Added file: http://bugs.python.org/file32989/vgrindNext.out

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

From report at bugs.python.org  Thu Dec  5 15:40:03 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 05 Dec 2013 14:40:03 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386254403.03.0.698113162638.issue12837@psf.upfronthosting.co.za>


Brett Cannon added the comment:

First, sorry about the noise in the patch.

Second, the patch should contain just three pragma lines:

  #pragma clang diagnostic push
  #pragma clang diagnostic ignored "-Wtautological-compare"
  ...
  #pragma clang diagnostic pop

Now I don't think that's unreadable at all, nor runs any risk of breaking anything. And since the majority of Clang users are probably on OS X that would suggest that the suppression of the warning will only affect those where the warning is superfluous and won't lead to unneeded suppressions (if people are really worried about unneeded suppressions I can try to break the 'if' guard up to only suppress on the one part).

I just don't want to perpetually be ignoring a single warning in the code. That leads to me ignoring any warnings that come during compilation, which is unfortunate as some warnings are actually useful and should be rectified.

----------

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

From report at bugs.python.org  Thu Dec  5 15:49:26 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 14:49:26 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386254966.39.0.479433021897.issue19887@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Whoa, Serhiy, your patch won't fly on Windows Vista.

For starter, the patch does not use target_is_directory=True option in os.symlink. It needs that option when creating symlink to the directory on Windows Vista.

The maximum depth that pathlib can do on Windows Vista is 4 (Remember, this line: "for depth in 0, 1, 2, 3, 10, 100"?).

More than that:
OSError: [WinError 1921] The name of the file cannot be resolved by the system:
'C:\\Users\\vajrasky\\Code\\cpython\\@test_4220_tmp\\testdir\\link5'

Not sure whether the bug is in pathlib.py or _getfinalpathname (from nt module).

----------
nosy: +vajrasky

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

From report at bugs.python.org  Thu Dec  5 16:04:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 15:04:33 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386255873.59.0.710286553878.issue19891@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I closed it because I could not reproduce it anymore.

I think, it worked again after

$ ./python -S

I will open it again if I can consistently reproduce this bug.

----------

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

From report at bugs.python.org  Thu Dec  5 16:16:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 15:16:53 +0000
Subject: [issue19898] No tests for dequereviter_new
Message-ID: <1386256613.14.0.807664608281.issue19898@psf.upfronthosting.co.za>


New submission from Christian Heimes:

According to LCOV the dequereviter_new is never called by any test.

http://tiran.bitbucket.org/python-lcov/Modules/_collectionsmodule.c.gcov.html#1408

----------
components: Library (Lib), Tests
messages: 205305
nosy: christian.heimes, rhettinger
priority: low
severity: normal
stage: needs patch
status: open
title: No tests for dequereviter_new
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  5 16:20:32 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 15:20:32 +0000
Subject: [issue19899] No test for thread.interrupt_main()
Message-ID: <1386256832.82.0.17906161504.issue19899@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Accoring to LCOV thread_PyThread_interrupt_main() is never called by any test. It's only referenced by some idle code.

http://tiran.bitbucket.org/python-lcov/Modules/_threadmodule.c.gcov.html#1110

----------
messages: 205306
nosy: christian.heimes
priority: low
severity: normal
stage: needs patch
status: open
title: No test for thread.interrupt_main()
type: behavior

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

From report at bugs.python.org  Thu Dec  5 16:37:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Dec 2013 15:37:56 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386257876.26.0.143508011753.issue19887@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Vajrasky. Here is a patch with fixed tests.

----------
Added file: http://bugs.python.org/file32990/pathlib_resolve_2.patch

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

From report at bugs.python.org  Thu Dec  5 16:43:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 15:43:28 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1386254403.03.0.698113162638.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386258206.2304.1.camel@fsol>


Antoine Pitrou added the comment:

On jeu., 2013-12-05 at 14:40 +0000, Brett Cannon wrote:
> 
> I just don't want to perpetually be ignoring a single warning in the
> code. That leads to me ignoring any warnings that come during
> compilation, which is unfortunate as some warnings are actually useful
> and should be rectified.

I guess my annoyance is that people reading the code will think "what is
this here for?". Perhaps you could add a comment.

----------

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

From report at bugs.python.org  Thu Dec  5 17:07:03 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 05 Dec 2013 16:07:03 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386259623.74.0.95772613568.issue12837@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/issue12837>
_______________________________________

From report at bugs.python.org  Thu Dec  5 17:13:37 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 16:13:37 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386260017.39.0.352119936211.issue19509@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The new patch splits the test into three separate test cases.

Guido, Python 3.3 doesn't have the necessary CA and server cert files. The files were added to 3.4 for some other tests. The patch tries to load the files from 3.4's test directory and falls back to local copies. You have to copy/delete these files to test the patch:

$ hg rm Lib/test/test_asyncio/sample.*
$ hg cp Lib/test/ssl_key.pem Lib/test/ssl_cert.pem Lib/test/pycacert.pem Lib/test/keycert3.pem  Lib/test/test_asyncio/

----------
Added file: http://bugs.python.org/file32991/asyncio_ssl_verify2.patch

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

From report at bugs.python.org  Thu Dec  5 17:25:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 16:25:37 +0000
Subject: [issue19343] Expose FreeBSD-specific APIs in resource module
In-Reply-To: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>
Message-ID: <1386260737.09.0.453078564666.issue19343@psf.upfronthosting.co.za>


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


----------
nosy: +larry

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

From report at bugs.python.org  Thu Dec  5 17:26:26 2013
From: report at bugs.python.org (David Edelsohn)
Date: Thu, 05 Dec 2013 16:26:26 +0000
Subject: [issue18235] _sysconfigdata.py wrong on AIX installations
In-Reply-To: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za>
Message-ID: <1386260786.69.0.650590584291.issue18235@psf.upfronthosting.co.za>


David Edelsohn added the comment:

Do you want me to open a new issue or do you want to open a new issue?

----------

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

From report at bugs.python.org  Thu Dec  5 17:39:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 05 Dec 2013 16:39:02 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386261542.81.0.192306909444.issue19887@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

It works. Just a coding nitpick, instead of hardcoding os.symlink(src, dst, target_is_directory=True) in the test, you can use helper function in the test itself, self.dirlink.

----------

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

From report at bugs.python.org  Thu Dec  5 18:22:46 2013
From: report at bugs.python.org (David Watson)
Date: Thu, 05 Dec 2013 17:22:46 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386264166.19.0.0732872756986.issue12837@psf.upfronthosting.co.za>


David Watson added the comment:

Looking again at cmsg_min_space(), I see that it already returns
false when msg_controllen is less than cmsg_len_end, so you could
do a (signed) comparison against that, rather than 0.  Patch
attached.

----------
Added file: http://bugs.python.org/file32992/socket-compare-cmsg_len_end.diff

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

From report at bugs.python.org  Thu Dec  5 18:34:29 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 17:34:29 +0000
Subject: [issue19296] Compiler warning when compiling dbm module
In-Reply-To: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>
Message-ID: <1386264869.41.0.968918095579.issue19296@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a patch that strncpy() the filename to a char[].

----------
nosy: +christian.heimes
stage:  -> needs patch
type:  -> compile error
Added file: http://bugs.python.org/file32993/dbm_const_filename.patch

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

From report at bugs.python.org  Thu Dec  5 18:46:00 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 17:46:00 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386265560.51.0.456385932977.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a modified patch. The changes are:
- pickle is deemphasized a lot more (it's moved into a "seealso")
- I replaced the terms "encoding" and "decoding" with "serializing" and "deserializing" (the former may be confusing for people who are already struggling to understand the bytes / unicode gap)
- I added a glossary entry for "text file" and pointed to it

----------
Added file: http://bugs.python.org/file32994/tutjson.patch

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

From report at bugs.python.org  Thu Dec  5 18:57:07 2013
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 05 Dec 2013 17:57:07 +0000
Subject: [issue18235] _sysconfigdata.py wrong on AIX installations
In-Reply-To: <1371429201.94.0.372851990361.issue18235@psf.upfronthosting.co.za>
Message-ID: <1386266227.76.0.479615427917.issue18235@psf.upfronthosting.co.za>


Michael Haubenwallner added the comment:

Erm, question target was the python committers. And I'd create the new issue if they prefer.

----------

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

From report at bugs.python.org  Thu Dec  5 19:06:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 18:06:48 +0000
Subject: [issue19900] improve pickle intro
Message-ID: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This patch improved the generalities at the top of the pickle module docs.

----------
assignee: docs at python
components: Documentation
files: pickintro.patch
keywords: patch
messages: 205316
nosy: alexandre.vassalotti, docs at python, ncoghlan, pitrou, tim.peters
priority: normal
severity: normal
stage: patch review
status: open
title: improve pickle intro
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32995/pickintro.patch

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

From report at bugs.python.org  Thu Dec  5 19:36:59 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 18:36:59 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1386224710.39.0.826486583806.issue16669@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+UnT=6FUZc4usg-Sh1bYU=aWma=hkwa3dDUkofOoDN0w@mail.gmail.com>


Guido van Rossum added the comment:

On Wed, Dec 4, 2013 at 10:25 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> I am familiar with running Sphinx on .rst files, but not on docstrings.
> It looks like the docstrings use .rst markup. (Is this allowed in the  stdlib?)

I'm not sure if it is allowed, but it is certainly used plenty in some
modules (perhaps those that started life as 3rd party packages).

> (The output looks good enough for a first draft of a tkinter class/method reference, which I would like to work on.)

I won't stop you -- having *any* kind of docs for Tkinter sounds good to me!

>> I understand that part of this [signature after class name] is due to the latter class having an __init__ with a reasonable docstring
>
> If dropbox.client is written in Python, as I presume,

It is.

> then I strongly suspect that the signature part of
>   class dropbox.client.DropboxClient(
>     oauth2_access_token, locale=None, rest_client=None)
> comes from an inspect module method that examines the function attributes other than .__doc__.

Indeed.

> If so, DropboxClient.__init__ docstring is irrelevant to the above. You could test by commenting it out and rerunning the doc build.

Yes.

> The inspect methods do not work on C-coded functions (unless Argument Clinic has fixed this for 3.4), which is why signatures are put in the docstrings for C-coded objects. For C-coded classes, it is put in the class docstring rather than the class.__init__ docstring.

Perhaps it doesn't understand __new__? namedtuple actually generates
Python code for a class definition using a template and then uses
exec() on the filled-in template; the template defines only __new__
though.

>> but the fact remains that namedtuple's default docstring produces poorly-looking documentation.
>
> 'x.__init__(...) initializes x; see help(type(x)) for signature'
>
> This is standard boilerplate for C-coded .__init__.__doc__.
> Raymond just copied it.

He didn't (it's not in the template). It is the dummy __init__ that
tuple inherits from object (the docstring is in the __init__ wrapper
in typeobject.c).

>>>> int.__init__.__doc__
> 'x.__init__(...) initializes x; see help(type(x)) for signature'
>>>> list.__init__.__doc__
> 'x.__init__(...) initializes x; see help(type(x)) for signature'

----------

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

From report at bugs.python.org  Thu Dec  5 21:19:00 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 05 Dec 2013 20:19:00 +0000
Subject: [issue19296] Compiler warning when compiling dbm module
In-Reply-To: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>
Message-ID: <1386274740.91.0.146699236893.issue19296@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Why wouldn't "dbm_open((char *)file, flags, mode)" work?

----------

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

From report at bugs.python.org  Thu Dec  5 21:47:39 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 20:47:39 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386276459.91.0.593698471108.issue19509@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks Christian, this is almost right.  I'm uploading a patch that covers all bases:

- Works on Python 3.3 (TEST_HOME_DIR isn't defined there)
- Works on older Python 3.4 versions (check_hostname may not exist)
- Works on latest Python 3.4 version

----------
Added file: http://bugs.python.org/file32996/asyncio_ssl_verify3.patch

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

From report at bugs.python.org  Thu Dec  5 21:59:46 2013
From: report at bugs.python.org (Reuben Garrett)
Date: Thu, 05 Dec 2013 20:59:46 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
Message-ID: <1386277185.98.0.181450665143.issue19901@psf.upfronthosting.co.za>


New submission from Reuben Garrett:

When building Python 3.3.2-r2 from Gentoo's Portage tree [1], I encountered two failed tests which probably should not have been attempted on my OS (Gentoo 3.7.10): test_bind_port and test_find_unused_port both use the SO_REUSEPORT socket option which, to the best of my knowledge is only available since kernel version 3.9. I was able to build by skipping the tests ? but I believe the tests are there for a reason, and it would be best if a test that is known to fail should be skipped (or replaced with a fallback that is likely to succeed). Issue # 16594 [3] may be related (not sure).

Is it possible to detect the kernel version and skip (or modify) these tests if SO_REUSEPORT is not available? Better yet (since even a 3.9 kernel could have it disabled) ? try the test with SO_REUSEPORT, but trap the exception for lack of OS support, print a warning, and try again without SO_REUSEPORT. 

+=== excerpt of portage build log:
======================================================================
ERROR: test_bind_port (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py", line 87, in test_bind_port
    support.bind_port(s)
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_find_unused_port (test.test_support.TestSupport)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/test_support.py", line 80, in test_find_unused_port
    port = support.find_unused_port()
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 522, in find_unused_port
    port = bind_port(tempsock)
  File "/var/tmp/portage/dev-lang/python-3.3.2-r2/work/Python-3.3.2/Lib/test/support.py", line 548, in bind_port
    if sock.getsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT) == 1:
OSError: [Errno 92] Protocol not available
===+

[1]: https://packages.gentoo.org/package/dev-lang/python
[2]: https://lwn.net/Articles/542629/
[3]: http://bugs.python.org/issue16594

----------
components: Build
messages: 205320
nosy: RubyTuesdayDONO
priority: normal
severity: normal
status: open
title: tests fail due to unsupported SO_REUSEPORT when building Python 3.3.2-r2
versions: Python 3.3

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

From report at bugs.python.org  Thu Dec  5 22:09:58 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 21:09:58 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1386277185.98.0.181450665143.issue19901@psf.upfronthosting.co.za>
Message-ID: <1386277798.14.0.315742201114.issue19901@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  5 22:26:46 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 21:26:46 +0000
Subject: [issue19296] Compiler warning when compiling dbm module
In-Reply-To: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>
Message-ID: <1386278806.34.0.702800967238.issue19296@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Yes, a cast to char* silences the error. But it could potentially brea contract because dbm_open() could alter the content of the string. I'm just paranoid (again). *g*

----------

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

From report at bugs.python.org  Thu Dec  5 22:54:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 21:54:05 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <3db9gJ2yMfz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 546cad3627e2 by Charles-Fran?ois Natali in branch 'default':
Issue #19850: asyncio: Set SA_RESTART when registering a signal handler to
http://hg.python.org/cpython/rev/546cad3627e2

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

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

From report at bugs.python.org  Thu Dec  5 23:06:50 2013
From: report at bugs.python.org (Phil Connell)
Date: Thu, 05 Dec 2013 22:06:50 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386281210.69.0.276862556022.issue16669@psf.upfronthosting.co.za>


Changes by Phil Connell <pconnell at gmail.com>:


----------
nosy: +pconnell

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

From report at bugs.python.org  Thu Dec  5 23:17:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Dec 2013 22:17:34 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1386265560.51.0.456385932977.issue18840@psf.upfronthosting.co.za>
Message-ID: <CADiSq7es=C+5VdkZNCpMcptAy7dmi1YSMmz04=vj_68UpYU-rw@mail.gmail.com>


Nick Coghlan added the comment:

Antoine's latest draft looks good to me.

----------

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

From report at bugs.python.org  Thu Dec  5 23:27:10 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Dec 2013 22:27:10 +0000
Subject: [issue19419] Use abc.ABC in the collections ABC
In-Reply-To: <1382907896.33.0.659909240184.issue19419@psf.upfronthosting.co.za>
Message-ID: <1386282430.31.0.299265897136.issue19419@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Agreed.

----------
nosy: +eric.araujo
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Thu Dec  5 23:32:49 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Dec 2013 22:32:49 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1386282769.9.0.0527747051777.issue19842@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Do I understand right that BaseSelector.register means something else entirely than ABC.register?  Is it a concern?

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

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

From report at bugs.python.org  Thu Dec  5 23:35:50 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 05 Dec 2013 22:35:50 +0000
Subject: [issue15968] Incorporate Tcl/Tk/Tix into the Windows build process
In-Reply-To: <1347996983.92.0.069726969781.issue15968@psf.upfronthosting.co.za>
Message-ID: <1386282950.94.0.426492165746.issue15968@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new patch based on Jeremy's that addresses all of my review comments and includes the update to Tcl/Tk 8.6.1.

Also, I'll be attaching a patch to tix-8.4.3.x which allows it to be built in debug configuration and removes many warnings about unrecognized command line options.

----------
Added file: http://bugs.python.org/file32997/issue15968.v2.diff

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

From report at bugs.python.org  Thu Dec  5 23:36:46 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 05 Dec 2013 22:36:46 +0000
Subject: [issue15968] Incorporate Tcl/Tk/Tix into the Windows build process
In-Reply-To: <1347996983.92.0.069726969781.issue15968@psf.upfronthosting.co.za>
Message-ID: <1386283006.29.0.533638096642.issue15968@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement
Added file: http://bugs.python.org/file32998/issue15968_tix.svndiff

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

From report at bugs.python.org  Thu Dec  5 23:39:36 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 22:39:36 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1386283176.69.0.912616837578.issue19842@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, registration is a very common pattern and you can't really require everyone to use an inferior word just because ABCMeta uses it.

There's a simple work-around:

abc.ABCMeta.register(selectors.BaseSelector, C)

----------

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

From report at bugs.python.org  Thu Dec  5 23:41:55 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 05 Dec 2013 22:41:55 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386283315.03.0.57239213278.issue18840@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I like Antoine's tutjson.patch.  commit it.  Thanks for noticing this Donald!

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

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

From report at bugs.python.org  Thu Dec  5 23:44:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 22:44:52 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386283492.92.0.462787336096.issue18840@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  5 23:48:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 22:48:18 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <3dbBss6vhdz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 90cf299dcf9b by Antoine Pitrou in branch '3.3':
Issue #18840: Introduce the json module in the tutorial, and deemphasize the pickle module.
http://hg.python.org/cpython/rev/90cf299dcf9b

New changeset 1009b77f59fd by Antoine Pitrou in branch 'default':
Issue #18840: Introduce the json module in the tutorial, and deemphasize the pickle module.
http://hg.python.org/cpython/rev/1009b77f59fd

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

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

From report at bugs.python.org  Thu Dec  5 23:52:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 22:52:07 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <3dbByH1kFqz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 481b30bfe496 by Antoine Pitrou in branch '2.7':
Issue #18840: Introduce the json module in the tutorial, and deemphasize the pickle module.
http://hg.python.org/cpython/rev/481b30bfe496

----------

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

From report at bugs.python.org  Thu Dec  5 23:52:28 2013
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 05 Dec 2013 22:52:28 +0000
Subject: [issue19296] Compiler warning when compiling dbm module
In-Reply-To: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>
Message-ID: <1386283948.23.0.664557786221.issue19296@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I suspect dbm_open predates the common availability of "const".  I assert we can safely assume it won't overwrite the contents of the buffer.  (Barring spectacular memory corruption bugs that "const" would be powerless to prevent.)

----------

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

From report at bugs.python.org  Thu Dec  5 23:52:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Dec 2013 22:52:45 +0000
Subject: [issue18840] Tutorial recommends pickle module without any warning of
 insecurity
In-Reply-To: <1377520678.97.0.369666733509.issue18840@psf.upfronthosting.co.za>
Message-ID: <1386283965.45.0.0147190506319.issue18840@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I've committed it. Thanks!

----------
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/issue18840>
_______________________________________

From report at bugs.python.org  Fri Dec  6 00:14:54 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Dec 2013 23:14:54 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386285294.82.0.827316738734.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a tentative change to selectors.py that ignores the OSError in various unregister() methods (but not in register()).

----------
keywords: +patch
Added file: http://bugs.python.org/file32999/unregister.diff

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

From report at bugs.python.org  Fri Dec  6 00:16:32 2013
From: report at bugs.python.org (follower)
Date: Thu, 05 Dec 2013 23:16:32 +0000
Subject: [issue19902] logging docs don't document integer constants
Message-ID: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>


New submission from follower:

The logging module documentation <http://docs.python.org/3.4/library/logging.html> makes reference to the levels DEBUG, INFO etc (e.g. in <http://docs.python.org/3.4/library/logging.html#logging.Logger.setLevel>) but AFAICT these constants are not documented in the module itself.

e.g I would expect a section like this

Level Constants
logging.DEBUG 10
logging.INFO  20
etc etc

(Although the actual values may not be listed depending on what your policy is for documenting "magic numbers".)

----------
assignee: docs at python
components: Documentation
messages: 205334
nosy: docs at python, follower
priority: normal
severity: normal
status: open
title: logging docs don't document integer constants
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 00:29:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 23:29:08 +0000
Subject: [issue19296] Compiler warning when compiling dbm module
In-Reply-To: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>
Message-ID: <3dbCn00KbTz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 3068ff3d9d1e by Christian Heimes in branch 'default':
Issue #19296: Silence compiler warning in dbm_open.
http://hg.python.org/cpython/rev/3068ff3d9d1e

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

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

From report at bugs.python.org  Fri Dec  6 00:29:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Dec 2013 23:29:09 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <3dbCn05lWYz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 1605eda93392 by Christian Heimes in branch 'default':
Issue #19509: Finish implementation of check_hostname
http://hg.python.org/cpython/rev/1605eda93392

----------

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

From report at bugs.python.org  Fri Dec  6 00:30:35 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Dec 2013 23:30:35 +0000
Subject: [issue19296] Compiler warning when compiling dbm module
In-Reply-To: <1382180566.13.0.638248121089.issue19296@psf.upfronthosting.co.za>
Message-ID: <1386286235.32.0.649480674133.issue19296@psf.upfronthosting.co.za>


Christian Heimes added the comment:

You are probably right. Let's not get too fancy with compiler warnings.

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

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

From report at bugs.python.org  Fri Dec  6 01:04:48 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 00:04:48 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386288288.17.0.266799249041.issue19509@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

With the latest (revision 1605eda93392) I get four failures on OS X.  Three are like this (in all three selector types -- kqueue, select, poll):

======================================================================
ERROR: test_create_ssl_connection (test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_events.py", line 532, in test_create_ssl_connection
    tr, pr = self.loop.run_until_complete(f)
  File "/Users/guido/tulip/asyncio/base_events.py", line 177, in run_until_complete
    return future.result()
  File "/Users/guido/tulip/asyncio/futures.py", line 221, in result
    raise self._exception
  File "/Users/guido/tulip/asyncio/tasks.py", line 276, in _step
    result = coro.throw(exc)
  File "/Users/guido/tulip/asyncio/base_events.py", line 388, in create_connection
    yield from waiter
  File "/Users/guido/tulip/asyncio/futures.py", line 320, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/Users/guido/tulip/asyncio/tasks.py", line 329, in _wakeup
    value = future.result()
  File "/Users/guido/tulip/asyncio/futures.py", line 221, in result
    raise self._exception
  File "/Users/guido/tulip/asyncio/selector_events.py", line 618, in _on_handshake
    self._sock.do_handshake()
  File "/usr/local/lib/python3.4/ssl.py", line 748, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:599)

The last is similar in test_streams.py:

======================================================================
ERROR: test_open_connection_no_loop_ssl (test_streams.StreamReaderTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "tests/test_streams.py", line 58, in test_open_connection_no_loop_ssl
    reader, writer = self.loop.run_until_complete(f)
  File "/Users/guido/tulip/asyncio/base_events.py", line 177, in run_until_complete
    return future.result()
  File "/Users/guido/tulip/asyncio/futures.py", line 221, in result
    raise self._exception
  File "/Users/guido/tulip/asyncio/tasks.py", line 276, in _step
    result = coro.throw(exc)
  File "/Users/guido/tulip/asyncio/streams.py", line 43, in open_connection
    lambda: protocol, host, port, **kwds)
  File "/Users/guido/tulip/asyncio/base_events.py", line 388, in create_connection
    yield from waiter
  File "/Users/guido/tulip/asyncio/futures.py", line 320, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/Users/guido/tulip/asyncio/tasks.py", line 329, in _wakeup
    value = future.result()
  File "/Users/guido/tulip/asyncio/futures.py", line 221, in result
    raise self._exception
  File "/Users/guido/tulip/asyncio/selector_events.py", line 618, in _on_handshake
    self._sock.do_handshake()
  File "/usr/local/lib/python3.4/ssl.py", line 748, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:599)


I get the same failures when I copy the changes to the Tulip repo.

----------

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

From report at bugs.python.org  Fri Dec  6 01:18:13 2013
From: report at bugs.python.org (Alexander Boyd)
Date: Fri, 06 Dec 2013 00:18:13 +0000
Subject: [issue18144] FD leak in urllib2
In-Reply-To: <1370459423.62.0.313188871142.issue18144@psf.upfronthosting.co.za>
Message-ID: <1386289093.2.0.454663068251.issue18144@psf.upfronthosting.co.za>


Changes by Alexander Boyd <alex at opengroove.org>:


----------
nosy: +javawizard

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

From report at bugs.python.org  Fri Dec  6 01:19:02 2013
From: report at bugs.python.org (Alexander Boyd)
Date: Fri, 06 Dec 2013 00:19:02 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1386289142.42.0.139385023147.issue12955@psf.upfronthosting.co.za>


Changes by Alexander Boyd <alex at opengroove.org>:


----------
nosy: +javawizard

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

From report at bugs.python.org  Fri Dec  6 01:21:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2013 00:21:46 +0000
Subject: [issue19903] Idle: Use inspect.signature for calltips
Message-ID: <1386289306.22.0.0855188637089.issue19903@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Change idlelib.CallTips.get_argspec to use inspect.signature, new in 3.3, instead of inspect.getfullargspec and inspect.formatargspec. One thing it handles better is a namedtuple class, which has a C-coded __init__ inherited from object a Python-coded __new__ written by namedtuple. Signature() will also handle C-coded functions if and when Argument Clinic (new in 3.4) adds signature information.

from collections import namedtuple
from inspect import signature

Point = namedtuple('Point', 'x y')
print(signature(Point.__new__))
# '(_cls, x, y)'
print(signature(Point))
# '(x, y)'

Note that str (called by print) is needed to get the desired string form.

There are tests in CallTips.py, but they should be converted to unittest, moved to idle_test/test_calltips.py, changed to match new output detail, and expanded to include new examples.

----------
assignee: terry.reedy
components: IDLE
messages: 205339
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: Use inspect.signature for calltips
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 01:27:32 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Dec 2013 00:27:32 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386289652.97.0.523505500986.issue16669@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think we can now agree that docstrings other than the class docstring (used as a fallback) are not relevant to signature detection. And Raymond gave namedtuple classes the docstring needed as a fallback.

We are off-issue here, but idlelib.CallTips.get_argspec() is also ignorant that it may need to look at  .__new__. An object with a C-coded .__init__ and Python-coded .__new__ is new to new-style classes. The new inspect.signature function handles such properly. Starting with a namedtuple Point (without the default docstring):

>>> from inspect import signature
>>> str(signature(Point.__new__))
'(_cls, x, y)'
>>> str(signature(Point))
'(x, y)'

The second is what autodoc should use. I just opened #19903 to update Idle to use signature.

----------

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

From report at bugs.python.org  Fri Dec  6 01:31:17 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 00:31:17 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386289877.22.0.958994002343.issue16669@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It was never about signature detection for me -- what gave you that idea?  I simply want to have the option to put individual docstrings on the properties generated by namedtuple.

----------

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

From report at bugs.python.org  Fri Dec  6 02:17:57 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 Dec 2013 01:17:57 +0000
Subject: [issue19888] Three argument type() super call sets __name__ but not
 __qualname__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386292677.74.0.0352617369037.issue19888@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I don't see the value in opening a new bug.  Now that we understand what's going on, let's just repurpose and retitle this one.

Run qualname-19888.py with Python 3.3 and you'll get:

Obj.__name__ foo
Obj.__qualname__ Obj
repr(Obj) <class '__main__.Obj'>

And with 3.2:

Obj.__name__ foo
repr(Obj) <class '__main__.foo'>

The primary discrepancy (and relevant visible regression) is in the repr of Obj.

----------
nosy: +ncoghlan
resolution: invalid -> 
status: closed -> open
title: type.__new__() name argument is ignored -> Three argument type() super call sets __name__ but not __qualname__
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Dec  6 02:18:15 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 Dec 2013 01:18:15 +0000
Subject: [issue19888] Three argument type() super call sets __name__ but not
 __qualname__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386292695.85.0.613563669105.issue19888@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file33000/qualname-19888.py

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

From report at bugs.python.org  Fri Dec  6 02:41:51 2013
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 06 Dec 2013 01:41:51 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1386277185.98.0.181450665143.issue19901@psf.upfronthosting.co.za>
Message-ID: <1386294111.36.0.955476966255.issue19901@psf.upfronthosting.co.za>


Dave Malcolm added the comment:

[FWIW, this looks similar to an issue I ran into on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=913732
which was due to a mismatch between the kernel headers on the system vs the actually running kernel.  I patched around it there with a downstream-only patch (our builds are done on chroots on RHEL-5 boxes, so such mismatches tend to occur)]

----------
nosy: +dmalcolm

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

From report at bugs.python.org  Fri Dec  6 03:04:23 2013
From: report at bugs.python.org (Fil Mackay)
Date: Fri, 06 Dec 2013 02:04:23 +0000
Subject: [issue19904] Add 128-bit integer support to struct
Message-ID: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>


New submission from Fil Mackay:

I've been looking at adding 128-bit support to the struct module. Currently only named integer types are supported, which vary in implementation. These include:

short
int
long
long long

Depending on the platform, none may translate to 128-bit integer (the case with all platforms today?).

One approach would be to make a new type that relates specifically to 128-bit integer, side-stepping the naming approaches to integer in C.

The other, would be to make new types for all integer sizes that relate to specific sizes, instead of relying on C namings. Much bigger implications?

I propose creating new types:

"o": __int128_t
"O": __uint128_t
"t": __int256_t (why not?)
"T": __uint256_t
"v": __int512_t (what, too far?)
"V": __int512_t

What implications are there here in killing the connection between a C named type and a specific size?

----------
components: ctypes
messages: 205344
nosy: fil
priority: normal
severity: normal
status: open
title: Add 128-bit integer support to struct
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 03:07:34 2013
From: report at bugs.python.org (Fil Mackay)
Date: Fri, 06 Dec 2013 02:07:34 +0000
Subject: [issue19905] Add 128-bit integer support to ctypes
Message-ID: <1386295654.39.0.271762839295.issue19905@psf.upfronthosting.co.za>


New submission from Fil Mackay:

This depends on struct issue #19904, and involves adding the following types:

c_int128
c_uint128
c_int256 (maybe?)
c_uint256
c_int512 (too much?)
c_uint512

After resolution of the struct issue, this implementation will become clearer.

----------
components: ctypes
messages: 205345
nosy: fil
priority: normal
severity: normal
status: open
title: Add 128-bit integer support to ctypes
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Dec  6 04:10:14 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 03:10:14 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386299414.62.0.821619443152.issue19881@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Added file: http://bugs.python.org/file33001/fix_bigmem_pickle_3.patch

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

From report at bugs.python.org  Fri Dec  6 04:29:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 03:29:43 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <3dbK6Z3DrGz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset 2612ea573ff7 by Alexandre Vassalotti in branch 'default':
Issue #19881: Fix bad pickling of large bytes in cpickle.
http://hg.python.org/cpython/rev/2612ea573ff7

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

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

From report at bugs.python.org  Fri Dec  6 04:32:23 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 03:32:23 +0000
Subject: [issue19881] Fix bigmem pickle tests
In-Reply-To: <1386139134.4.0.507714096088.issue19881@psf.upfronthosting.co.za>
Message-ID: <1386300743.95.0.0669021926997.issue19881@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


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

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

From report at bugs.python.org  Fri Dec  6 04:42:25 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 03:42:25 +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: <1386301345.52.0.753942997072.issue6784@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Could you provide a single patch with the implementation and the tests together? I will try to find some time this week to review this.

----------
assignee: docs at python -> alexandre.vassalotti
priority: normal -> high
stage:  -> patch review
versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec  6 04:48:47 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 03:48:47 +0000
Subject: [issue19858] Make pickletools.optimize aware of the MEMOIZE opcode.
In-Reply-To: <1385946014.54.0.601831543599.issue19858@psf.upfronthosting.co.za>
Message-ID: <1386301727.34.0.431421553424.issue19858@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Ah, I almost forgot! I did implement the verification in pickletools.dis() for MEMOIZE:

http://hg.python.org/cpython/file/2612ea573ff7/Lib/pickletools.py#l2420

----------

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

From report at bugs.python.org  Fri Dec  6 04:54:40 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 03:54:40 +0000
Subject: [issue19900] improve pickle intro
In-Reply-To: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>
Message-ID: <1386302080.77.0.450074090279.issue19900@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Looks good to me!

----------

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

From report at bugs.python.org  Fri Dec  6 05:07:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Dec 2013 04:07:48 +0000
Subject: [issue19900] improve pickle intro
In-Reply-To: <1386302080.77.0.450074090279.issue19900@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dwdM8rysJObA3E=Da_VKOzg978uZFg4AsvVBi4_0oUWA@mail.gmail.com>


Nick Coghlan added the comment:

Looks good to me, although I'm not sure the specific note about the C
accelerator is needed.

----------

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

From report at bugs.python.org  Fri Dec  6 05:10:08 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 04:10:08 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386303008.06.0.721512663765.issue19509@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

That's fixed by revision ec1e7fc9b5a4.

Christian, can this bug be closed now, or is there more?

----------

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

From report at bugs.python.org  Fri Dec  6 06:10:50 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 05:10:50 +0000
Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by
 2.7.3 or 2.7.4
In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za>
Message-ID: <1386306650.62.0.790396713006.issue18015@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


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

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

From report at bugs.python.org  Fri Dec  6 06:13:09 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 05:13:09 +0000
Subject: [issue10701] Error pickling objects with mutating __getstate__
In-Reply-To: <1292338436.19.0.0995184249123.issue10701@psf.upfronthosting.co.za>
Message-ID: <1386306789.81.0.78031502251.issue10701@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
title: Error pickling a dict -> Error pickling objects with mutating __getstate__

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

From report at bugs.python.org  Fri Dec  6 06:16:00 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 06 Dec 2013 05:16:00 +0000
Subject: [issue18400] Minor increase to Pickle test coverage
In-Reply-To: <1373259878.07.0.171161881505.issue18400@psf.upfronthosting.co.za>
Message-ID: <1386306960.84.0.257954712691.issue18400@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy: +alexandre.vassalotti
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Fri Dec  6 06:45:32 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Dec 2013 05:45:32 +0000
Subject: [issue19703] Upate pydoc to PEP 451
Message-ID: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za>


New submission from Eric Snow:

Here are the functions that should (?) be updated:

synopsis()
importfile()
safeimport()?
HTMLDoc.docmodule()
HTMLDoc.index()
TextDoc.docmodule()
ModuleScanner.run()?

----------

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

From report at bugs.python.org  Fri Dec  6 06:47:53 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Dec 2013 05:47:53 +0000
Subject: [issue19697] refactor pythonrun.c to make use of specs
 (__main__.__spec__)
In-Reply-To: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za>
Message-ID: <1386308873.67.0.093237250186.issue19697@psf.upfronthosting.co.za>


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


----------
dependencies: +Update runpy for PEP 451

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

From report at bugs.python.org  Fri Dec  6 06:48:17 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Dec 2013 05:48:17 +0000
Subject: [issue19701] Update multiprocessing for PEP 451
In-Reply-To: <1385138043.59.0.905087765846.issue19701@psf.upfronthosting.co.za>
Message-ID: <1386308897.78.0.466015515098.issue19701@psf.upfronthosting.co.za>


Eric Snow added the comment:

In Lib/multiprocessing/spawn.py the following need changing:

get_preparation_data()
import_main_path()

----------
dependencies: +refactor pythonrun.c to make use of specs (__main__.__spec__)

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

From report at bugs.python.org  Fri Dec  6 06:48:40 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Dec 2013 05:48:40 +0000
Subject: [issue19703] Update pydoc to PEP 451
In-Reply-To: <1386308732.16.0.241139477522.issue19703@psf.upfronthosting.co.za>
Message-ID: <1386308920.09.0.762066583653.issue19703@psf.upfronthosting.co.za>


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


----------
title: Upate pydoc to PEP 451 -> Update pydoc to PEP 451

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

From report at bugs.python.org  Fri Dec  6 07:31:44 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Dec 2013 06:31:44 +0000
Subject: [issue19850] asyncio: limit EINTR occurrences with SA_RESTART
In-Reply-To: <1385899755.41.0.415738852454.issue19850@psf.upfronthosting.co.za>
Message-ID: <1386311504.4.0.9484580753.issue19850@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Thanks!

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

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

From report at bugs.python.org  Fri Dec  6 07:35:08 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Dec 2013 06:35:08 +0000
Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic
In-Reply-To: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za>
Message-ID: <1386311708.11.0.398728623736.issue19698@psf.upfronthosting.co.za>


Eric Snow added the comment:

Is the problem here that builtins (and extension modules) don't necessarily obey the rules to the letter?  load_module() is supposed to use whatever is in sys.modules. [1]  (BuiltinImporter.load_module() is essentially a synonym for _imp.init_builtin(), right?)

So in each PyInit_*() the code should be using the module out of sys.modules...  That sounds like a bug and I expect that the builtin modules and most extension modules don't comply.

That said, I realize the spirit of the load_module() rule is to support reloading, which is mostly not applicable to builtins and extension modules.  The code you reverted would rely on enforcing the rule outside the implicit applicability.

I'll be glad when we've resolved the extension module API changes that support exec_module()!

[1] http://docs.python.org/dev/library/importlib.html#importlib.abc.Loader.load_module

----------

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

From report at bugs.python.org  Fri Dec  6 08:17:51 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 06 Dec 2013 07:17:51 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386314271.97.0.144266839031.issue19700@psf.upfronthosting.co.za>


Eric Snow added the comment:

_run_module_as_main() is particularly related to #19697.

----------

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

From report at bugs.python.org  Fri Dec  6 09:26:38 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Dec 2013 08:26:38 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386318398.49.0.100849748806.issue19904@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Do you have a particular application / use-case in mind?  Would int.from_bytes and int.to_bytes fill the need?

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

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

From report at bugs.python.org  Fri Dec  6 09:33:33 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Dec 2013 08:33:33 +0000
Subject: [issue19698] Implement _imp.exec_builtin and exec_dynamic
In-Reply-To: <1386311708.11.0.398728623736.issue19698@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cq-mjn+ZCSXuty9jO+K5siULLaubCSDOjGADAMfHRE-g@mail.gmail.com>


Nick Coghlan added the comment:

There are assorted shenanigans in the dynamic module loading code that make
me think we should leave the associated loaders alone for now. Running
PyInit_* more than once isn't permitted by default, so reloading is a
no-op, and "loading again" *copies* the existing module. But modules can
opt in to allowing reinitialization by declaring a module state size of
zero :)

It's a solvable problem, but not an urgent one, and hence better addressed
when we're redesigning the associated C APIs for a PEP 451 based import
system.

----------

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

From report at bugs.python.org  Fri Dec  6 11:46:04 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 06 Dec 2013 10:46:04 +0000
Subject: [issue19906] Typo in urllib documentation
Message-ID: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

In the first note from urllib.rst, there is a reference to urllib being replaced by urllib2 in Python 3, which is False.

----------
assignee: docs at python
components: Documentation
files: urllib2.patch
keywords: patch
messages: 205359
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in urllib documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file33002/urllib2.patch

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

From report at bugs.python.org  Fri Dec  6 12:01:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 11:01:28 +0000
Subject: [issue19900] improve pickle intro
In-Reply-To: <CADiSq7dwdM8rysJObA3E=Da_VKOzg978uZFg4AsvVBi4_0oUWA@mail.gmail.com>
Message-ID: <1386327686.2298.0.camel@fsol>


Antoine Pitrou added the comment:

> Looks good to me, although I'm not sure the specific note about the C
> accelerator is needed.

Neither am I. I moved it to the end to deemphasize it, but we can as
well remove it.

----------

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

From report at bugs.python.org  Fri Dec  6 12:20:33 2013
From: report at bugs.python.org (=?utf-8?q?Michael_M=C3=BCller?=)
Date: Fri, 06 Dec 2013 11:20:33 +0000
Subject: [issue19907] gettext - Non ascii chars in header
Message-ID: <1386328833.52.0.797354581277.issue19907@psf.upfronthosting.co.za>


New submission from Michael M?ller:

When having non ascii chars in the header of an translation file (xxx.po) the following error will be raised:

  File "D:\Python33\lib\gettext.py", line 410, in translation
    t = _translations.setdefault(key, class_(fp))
  File "D:\Python33\lib\gettext.py", line 160, in __init__
    self._parse(fp)
  File "D:\Python33\lib\gettext.py", line 265, in _parse
    item = b_item.decode().strip()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 51: invalid continuation byte

translation file head:

"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2013-12-06 11:47\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE+Mitteleurop?ische Zeit\n"
"Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
"Language-Team: LANGUAGE <LL at li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: utf-8\n"
"Generated-By: pygettext.py 1.5\n"

The problem here exists with the PO-Revision-Date which is followed by the timezone offset in current language (here "Mitteleurop?ische Zeit") which is automatically added by pygettext.py.
When removing it the file will work without any problems.

Current pygettext.py code part:
[Line 444] ...
    def write(self, fp):
        options = self.__options
        timestamp = time.strftime('%Y-%m-%d %H:%M+%Z')
        # The time stamp in the header doesn't have the same format as that
        # generated by xgettext...
        print(pot_header % {'time': timestamp, 'version': __version__}, file=fp)
...

To avoid this it would be better to use gmtime and not to append the timezone:

...
    def write(self, fp):
        options = self.__options
        timestamp = time.strftime('%Y-%m-%d %H:%M', time.gmtime())
...

----------
components: Library (Lib)
messages: 205361
nosy: Michael.M?ller
priority: normal
severity: normal
status: open
title: gettext - Non ascii chars in header
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  6 12:44:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 11:44:43 +0000
Subject: [issue16465] dict creation performance regression
In-Reply-To: <1352823544.31.0.485629860142.issue16465@psf.upfronthosting.co.za>
Message-ID: <1386330283.26.0.461636986733.issue16465@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

So what we should do with this?

----------

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

From report at bugs.python.org  Fri Dec  6 12:48:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 11:48:39 +0000
Subject: [issue16465] dict creation performance regression
In-Reply-To: <1352823544.31.0.485629860142.issue16465@psf.upfronthosting.co.za>
Message-ID: <1386330519.35.0.00893132119159.issue16465@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

You said it yourself: """The gain is too small and undistinguished on a background of random noise""". Closing would be reasonable, unless someone exhibits a reasonable benchmark where there is a significant difference.

In any case, it's too late for perf improvements on 3.4.

----------
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Fri Dec  6 12:50:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 11:50:09 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
Message-ID: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> pathlib.PureWindowsPath('C:/a/b').joinpath('D:x/y')
PureWindowsPath('D:/a/b/D:/x/y')

See also issue19456.

----------
components: Library (Lib)
messages: 205364
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pathlib.PureWindowsPath doesn't join relative paths correctly when a drive is present
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec  6 13:15:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 12:15:12 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <1386332112.29.0.794831107792.issue19908@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file33003/joinwinpath.patch

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

From report at bugs.python.org  Fri Dec  6 13:50:08 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 06 Dec 2013 12:50:08 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1386334208.73.0.867213537689.issue19524@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here are two patches: a test case, and a fix for my issue. They were done against an installed version of Python 3.3.3.

I?m not entirely happy with the fix because it is accessing the private HTTPConnection.sock attribute from the urllib.request module, which seems a bit hacky. Other ideas would be to let HTTPConnection grow a new public method (or just a flag?) for cleaning itself up while leaving the response object still open. Or some kind of wrapper to augment the HTTPResponse.close() method to explicitly close the connection as well, like I originally mentioned.

Also my test case borrows some classes from the ?test_urllib? module into the ?test_urllib2?. This is the first time I?ve looked closely at the Python test suite; maybe there is a better to do that as well.

A bonus from my fix: it looks like it resolves a couple warnings running ?test_urllib2net?.

----------
keywords: +patch
Added file: http://bugs.python.org/file33004/urllib-close-test.diff

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

From report at bugs.python.org  Fri Dec  6 13:50:24 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 06 Dec 2013 12:50:24 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1386334224.67.0.336959082131.issue19524@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file33005/urlopen-sock-close.diff

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

From report at bugs.python.org  Fri Dec  6 14:13:48 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2013 13:13:48 +0000
Subject: [issue19909] Best practice docs for new SSL features
Message-ID: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The new ssl-module features #19509 (check_hostname) and  #19689 (create_default_context) need more documentation, a whatsnew entry and a best-practice paragraph in the ssl documentation.

----------
assignee: christian.heimes
components: Documentation
messages: 205367
nosy: christian.heimes
priority: high
severity: normal
stage: needs patch
status: open
title: Best practice docs for new SSL features
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Dec  6 14:16:29 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2013 13:16:29 +0000
Subject: [issue19509] No SSL match_hostname() in ftp, imap, nntp, pop,
 smtp modules
In-Reply-To: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>
Message-ID: <1386335789.7.0.763460563848.issue19509@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm closing this ticket. All features have been implemented and tests are passing, too.

I have created #19909 as a reminder for doc improvements.

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

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

From report at bugs.python.org  Fri Dec  6 14:34:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 13:34:13 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <1386336853.52.0.0208609424539.issue19908@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is simplified patch.

----------
Added file: http://bugs.python.org/file33006/joinwinpath_2.patch

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

From report at bugs.python.org  Fri Dec  6 14:34:44 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Dec 2013 13:34:44 +0000
Subject: [issue19909] Best practice docs for new SSL features
In-Reply-To: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>
Message-ID: <1386336884.17.0.84891604838.issue19909@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/issue19909>
_______________________________________

From report at bugs.python.org  Fri Dec  6 14:38:31 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 06 Dec 2013 13:38:31 +0000
Subject: [issue18144] FD leak in urllib2
In-Reply-To: <1370459423.62.0.313188871142.issue18144@psf.upfronthosting.co.za>
Message-ID: <1386337111.44.0.722764622033.issue18144@psf.upfronthosting.co.za>


Martin Panter added the comment:

Confirmed that this happens when the server sends a chunked response, or sends a Content-Length header, but not when the server just sends ?Connection: close?. So this looks like the same as Issue 19524, and my patch for that seems to fix the issue here.

Python 3 version of the demo code:

import os, urllib.request
data = b"""{"imp": [{"h": 50, "battr": ["9", "10", "12"], "api": 3, "w": 320,
"instl": 0, "impid": "5d6dedf3-17bb-11e2-b5c0-1040f38b83e0"}]""" * 10
req = urllib.request.Request("http://localhost:8000/bogus?src=1", data)
resp = urllib.request.urlopen(req)
v = resp.read()
resp.close()
os.system("ls -alh /proc/%d/fd/*" % os.getpid())

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

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

From report at bugs.python.org  Fri Dec  6 14:44:41 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 06 Dec 2013 13:44:41 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1386337481.84.0.804067677886.issue19842@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/issue19842>
_______________________________________

From report at bugs.python.org  Fri Dec  6 14:49:17 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 06 Dec 2013 13:49:17 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386337757.01.0.711455039688.issue19891@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, this bug is valid. I can reproduce it in Ubuntu and Fedora.

bash-4.2$ ./python
Python 3.4.0b1 (default:7a668179d691, Dec  6 2013, 21:44:31) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
Error in atexit._run_exitfuncs:
FileNotFoundError: [Errno 2] No such file or directory
bash-4.2$ ./python -S
Python 3.4.0b1 (default:7a668179d691, Dec  6 2013, 21:44:31) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
>>> 
bash-4.2$

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

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

From report at bugs.python.org  Fri Dec  6 14:54:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 06 Dec 2013 13:54:16 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386338056.84.0.191239402677.issue19891@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Additional information:

When I created /home/cutecat with another user account.

bash-4.2$ ./python
Python 3.4.0b1 (default:7a668179d691, Dec  6 2013, 21:44:31) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
Error in atexit._run_exitfuncs:
PermissionError: [Errno 13] Permission denied

Of course, so I change the ownership of /home/cutecat to cutecat. Then it works.

bash-4.2$ ./python
Python 3.4.0b1 (default:7a668179d691, Dec  6 2013, 21:44:31) 
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
bash-4.2$

So what did it try to do in /home/cutecat?

[sky at localhost cpython]$ ls -la /home/cutecat/
total 8
drwxr-xr-x. 2 cutecat root    4096 Dec  6 21:50 .
drwxr-xr-x. 4 root    root    4096 Dec  6 21:50 ..
-rw-------. 1 cutecat cutecat    0 Dec  6 21:50 .python_history

So I leave to core Python developers to decide whether this ticket is valid or not.

----------

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

From report at bugs.python.org  Fri Dec  6 14:56:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 13:56:12 +0000
Subject: [issue19891] Exiting Python REPL prompt with user without home
 directory throws error in atexit._run_exitfuncs
In-Reply-To: <1386217330.5.0.714990905065.issue19891@psf.upfronthosting.co.za>
Message-ID: <1386338172.76.0.528308217719.issue19891@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The main question here is whether "interactive user without a home directory" is a valid / common use case. I think silencing the FileNotFoundError would be ok.

(however, the "home directory with wrong permissions" case sounds crazy)

----------
priority: normal -> low
versions: +Python 3.3

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

From report at bugs.python.org  Fri Dec  6 15:12:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 14:12:26 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <1386339146.07.0.295084212596.issue19908@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks! Patch looks ok to me.

----------

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

From report at bugs.python.org  Fri Dec  6 15:46:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 14:46:55 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <1386341215.82.0.321030943573.issue19908@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, drives should be compared with ignored cases.

----------
Added file: http://bugs.python.org/file33007/joinwinpath_3.patch

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

From report at bugs.python.org  Fri Dec  6 15:51:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Dec 2013 14:51:50 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <1386341510.78.0.0357003359431.issue19908@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Good point :)

----------

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

From report at bugs.python.org  Fri Dec  6 16:14:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 15:14:47 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <3dbcm66fmXzLr1@mail.python.org>


Roundup Robot added the comment:

New changeset 1ba15c3f45fa by Serhiy Storchaka in branch 'default':
Issue #19908: pathlib now joins relative Windows paths correctly when a drive
http://hg.python.org/cpython/rev/1ba15c3f45fa

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

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

From report at bugs.python.org  Fri Dec  6 16:18:18 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Dec 2013 15:18:18 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386343098.17.0.231436306028.issue19883@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/issue19883>
_______________________________________

From report at bugs.python.org  Fri Dec  6 16:19:05 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Dec 2013 15:19:05 +0000
Subject: [issue18716] Deprecate the formatter module
In-Reply-To: <1376334968.93.0.863346638514.issue18716@psf.upfronthosting.co.za>
Message-ID: <1386343145.69.0.386998563291.issue18716@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  6 16:20:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 15:20:54 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <1386343254.33.0.0608068224128.issue19908@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Antoine for your patch.

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

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

From report at bugs.python.org  Fri Dec  6 16:26:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 15:26:17 +0000
Subject: [issue19908] pathlib.PureWindowsPath doesn't join relative paths
 correctly when a drive is present
In-Reply-To: <1386330609.63.0.822642752717.issue19908@psf.upfronthosting.co.za>
Message-ID: <3dbd1N2y4Qz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 0c508d87f80b by Serhiy Storchaka in branch 'default':
Test same drive in different cases (issue #19908).
http://hg.python.org/cpython/rev/0c508d87f80b

----------

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

From report at bugs.python.org  Fri Dec  6 16:28:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 15:28:30 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386343710.59.0.853430942976.issue19883@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, these fields are unsingned.

----------

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

From report at bugs.python.org  Fri Dec  6 16:57:13 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 15:57:13 +0000
Subject: [issue19842] selectors: refactor BaseSelector implementation
In-Reply-To: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>
Message-ID: <1386345433.53.0.55714801895.issue19842@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

This is done AFAICT.

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

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

From report at bugs.python.org  Fri Dec  6 17:01:24 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:01:24 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386345684.06.0.765236466183.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Ping? Charle-Fran?ois, what do you think of my patch to ignore OSError in unregister()?

----------
assignee: docs at python -> neologix

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

From report at bugs.python.org  Fri Dec  6 17:12:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:12:46 +0000
Subject: [issue19910] Document that compile() source may be bytes
Message-ID: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

compile() takes a string, bytes or AST as the "source" argument.  The bytes option are not documented except in the error message you get when you pass something else.  The AST option is in the library docs but not in the function docstring.

----------
assignee: docs at python
components: Documentation
messages: 205383
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: Document that compile() source may be bytes
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 17:14:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 16:14:31 +0000
Subject: [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386346471.9.0.930057176294.issue19910@psf.upfronthosting.co.za>


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


----------
keywords: +easy
priority: normal -> low
stage:  -> needs patch

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

From report at bugs.python.org  Fri Dec  6 17:23:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Dec 2013 16:23:53 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386347033.83.0.20639483566.issue18864@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I just realized that there is no way to make ModuleSpec.has_location return True if the spec is created by simply instantiating ModuleSpec. As it stands now you **must** go through importlib.util.spec_from_file_location(), which makes it not a helper but a **required** API to use. I think this is the only thing that cannot be stated directly through ModuleSpec instantiation or public attribute assignment.

This means either (a) the docs on ModuleSpec need to be **very** clear that you must use spec_from_file_location() to make spec.has_location be true, (b) add another keyword-only argument to ModuleSpec.__init__(), or (c) make has_location settable (e.g. be able to only set it to True/False or alternatively assigning it sets both has_location to True and origin to the assigned value).

----------

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

From report at bugs.python.org  Fri Dec  6 17:46:46 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Dec 2013 16:46:46 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386345684.06.0.765236466183.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM02pjCueto9SsFxU5LjuyFTGmAAF5tYDDTLwUOoUQiPNw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Sorry for the delay, I didn't have any free time this week.
I'll review the patch shortly, but the idea sounds fine (I just need
to check if we can't be a little more specific for errnos upon
unregister).

----------

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

From report at bugs.python.org  Fri Dec  6 18:06:06 2013
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 06 Dec 2013 17:06:06 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1386349566.25.0.282508216059.issue16991@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


----------
nosy: +Ryan.Gonzalez

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

From report at bugs.python.org  Fri Dec  6 18:07:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 17:07:33 +0000
Subject: [issue19712] Make sure there are exec_module tests for _LoaderBasics
 subclasses
In-Reply-To: <3dWT7W736GzQPM@mail.python.org>
Message-ID: <3dbgGD708Fz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 543c76769c14 by Brett Cannon in branch 'default':
Issue #19712: Update test.test_importlib.import_ to test/use PEP 451
http://hg.python.org/cpython/rev/543c76769c14

----------

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

From report at bugs.python.org  Fri Dec  6 18:08:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Dec 2013 17:08:51 +0000
Subject: [issue19712] Make sure there are exec_module tests for _LoaderBasics
 subclasses
In-Reply-To: <3dWT7W736GzQPM@mail.python.org>
Message-ID: <1386349731.62.0.141537042555.issue19712@psf.upfronthosting.co.za>


Brett Cannon added the comment:

test.test_importlib.source is the last thing to update for PEP 451 for this bug.

----------

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

From report at bugs.python.org  Fri Dec  6 18:29:17 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:29:17 +0000
Subject: [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386350957.57.0.919683386091.issue19910@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/issue19910>
_______________________________________

From report at bugs.python.org  Fri Dec  6 18:32:27 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:32:27 +0000
Subject: [issue19907] gettext - Non ascii chars in header
In-Reply-To: <1386328833.52.0.797354581277.issue19907@psf.upfronthosting.co.za>
Message-ID: <1386351147.74.0.728153440453.issue19907@psf.upfronthosting.co.za>


?ric Araujo added the comment:

It looks like there are two issues here.  First, what would be a correct format for the PO-Revision-Date line? (human-readable string or numerical timezone)  Second, gettext supports UTF-8 for the po file, which should support ? without problem, so maybe pygettext uses the wrong encoding when saving the file.  Can you tell what?s the encoding of your xxx.po?

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

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

From report at bugs.python.org  Fri Dec  6 18:33:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:33:01 +0000
Subject: [issue19906] Typo in urllib documentation
In-Reply-To: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>
Message-ID: <1386351181.97.0.386534218529.issue19906@psf.upfronthosting.co.za>


?ric Araujo added the comment:

LGTM.

----------
nosy: +eric.araujo, ezio.melotti
stage:  -> commit review

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

From report at bugs.python.org  Fri Dec  6 18:38:49 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:38:49 +0000
Subject: [issue19862] Unclear xpath caching for custom  namespaces
In-Reply-To: <1385997526.09.0.197144583843.issue19862@psf.upfronthosting.co.za>
Message-ID: <1386351529.47.0.530442367003.issue19862@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  6 18:39:08 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:39:08 +0000
Subject: [issue17011] ElementPath ignores different namespace mappings for the
 same path expression
In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>
Message-ID: <1386351548.26.0.146810187914.issue17011@psf.upfronthosting.co.za>


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


----------
resolution: fixed -> duplicate

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

From report at bugs.python.org  Fri Dec  6 18:39:19 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:39:19 +0000
Subject: [issue17011] ElementPath ignores different namespace mappings for the
 same path expression
In-Reply-To: <1358838984.91.0.0315362873275.issue17011@psf.upfronthosting.co.za>
Message-ID: <1386351559.06.0.740310393755.issue17011@psf.upfronthosting.co.za>


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


----------
resolution: duplicate -> fixed

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

From report at bugs.python.org  Fri Dec  6 18:42:05 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:42:05 +0000
Subject: [issue19841] ConfigParser PEP issues
In-Reply-To: <1385817419.05.0.067066998342.issue19841@psf.upfronthosting.co.za>
Message-ID: <1386351725.08.0.143247844051.issue19841@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Do you mean PEP 8 violations?  These aren?t usually enough to cause a change.

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

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

From report at bugs.python.org  Fri Dec  6 18:46:00 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Dec 2013 17:46:00 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1386351960.31.0.152061969631.issue19837@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/issue19837>
_______________________________________

From report at bugs.python.org  Fri Dec  6 18:58:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 17:58:50 +0000
Subject: [issue19456] ntpath doesn't join paths correctly when a drive is
 present
In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za>
Message-ID: <1386352730.48.0.799665455824.issue19456@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With previous patch:

>>> ntpath.join('C:a/b', 'D:y/z')
'D:y/z\\y/z'

Should be 'D:y/z'.

Here is other patch which implements same algorithm as in pathlib (issue19908). Added new tests, removed duplicated tests.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Dec  6 18:59:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 17:59:09 +0000
Subject: [issue19456] ntpath doesn't join paths correctly when a drive is
 present
In-Reply-To: <1383174757.86.0.861423882665.issue19456@psf.upfronthosting.co.za>
Message-ID: <1386352749.67.0.0815495945524.issue19456@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file33008/ntpath_join.patch

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

From report at bugs.python.org  Fri Dec  6 19:18:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 18:18:26 +0000
Subject: [issue19911] ntpath.splitdrive() fails when UNC part contains \u0130
Message-ID: <1386353906.42.0.949556557512.issue19911@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ntpath.splitdrive() returns wrong result when UNC part contains LATIN CAPITAL LETTER I WITH DOT ABOVE ('?', '\u0130').

>>> ntpath.splitdrive('//host/I/abc')
('//host/I', '/abc')
>>> ntpath.splitdrive('//host/?/abc')
('//host/?/', 'abc')
>>> ntpath.splitdrive('//host/??/abc')
('//host/??/a', 'bc')
>>> ntpath.splitdrive('//host/???/abc')
('//host/???/ab', 'c')

This is because ntpath.splitdrive() find an index for a split in normcased path and len('\u0130'.lower()) != 1.

----------
components: Library (Lib)
messages: 205392
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: ntpath.splitdrive() fails when UNC part contains \u0130
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  6 19:39:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 18:39:18 +0000
Subject: [issue19911] ntpath.splitdrive() fails when UNC part contains \u0130
In-Reply-To: <1386353906.42.0.949556557512.issue19911@psf.upfronthosting.co.za>
Message-ID: <1386355158.07.0.196825622438.issue19911@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file33009/ntpath_splitdrive_u0130.patch

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

From report at bugs.python.org  Fri Dec  6 20:02:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 19:02:51 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
Message-ID: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

ntpath.splitunc() returns illegal results when path contains redundant slashes.

>>> import ntpath
>>> ntpath.splitunc("\\\\\\conky\\mountpoint\\foo\\bar")
('\\\\\\conky', '\\mountpoint\\foo\\bar')
>>> ntpath.splitunc("///conky/mountpoint/foo/bar")
('///conky', '/mountpoint/foo/bar')
>>> ntpath.splitunc("\\\\conky\\\\mountpoint\\foo\\bar")
('\\\\conky\\', '\\mountpoint\\foo\\bar')

It also affected by a bug from issue19911.

It also emits warnings in wrong place (from stdlib, not from places where it is used).

It has no tests.

Proposed patch fixes these issues.

----------
assignee: serhiy.storchaka
components: Library (Lib), Tests
files: ntpath_splitunc.patch
keywords: patch
messages: 205394
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: ntpath.splitunc() is broken and not tested
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33010/ntpath_splitunc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19912>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:03:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 19:03:05 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
In-Reply-To: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>
Message-ID: <1386356585.25.0.896310117239.issue19912@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +ntpath.splitdrive() fails when UNC part contains \u0130

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19912>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:25:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 19:25:10 +0000
Subject: [issue19712] Make sure there are exec_module tests for _LoaderBasics
 subclasses
In-Reply-To: <3dWT7W736GzQPM@mail.python.org>
Message-ID: <3dbkK03jlVz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 07ef52e751f3 by Brett Cannon in branch 'default':
Issue #19712: Update test.test_importlib.source for PEP 451
http://hg.python.org/cpython/rev/07ef52e751f3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19712>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:25:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Dec 2013 19:25:22 +0000
Subject: [issue19712] Make sure there are exec_module tests for _LoaderBasics
 subclasses
In-Reply-To: <3dWT7W736GzQPM@mail.python.org>
Message-ID: <1386357922.26.0.884999466.issue19712@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19712>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:28:41 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Dec 2013 19:28:41 +0000
Subject: [issue6501] Fatal error on startup with invalid PYTHONIOENCODING
In-Reply-To: <1247826105.17.0.941734297485.issue6501@psf.upfronthosting.co.za>
Message-ID: <1386358121.75.0.076385676752.issue6501@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is there anything to backport as referred to in msg136670 or can this be closed?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6501>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:30:52 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 06 Dec 2013 19:30:52 +0000
Subject: [issue19909] Best practice docs for new SSL features
In-Reply-To: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>
Message-ID: <1386358252.53.0.233422444835.issue19909@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/issue19909>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:35:10 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 Dec 2013 19:35:10 +0000
Subject: [issue16465] dict creation performance regression
In-Reply-To: <1352823544.31.0.485629860142.issue16465@psf.upfronthosting.co.za>
Message-ID: <1386358510.06.0.307449813331.issue16465@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This patch looks correct and like the right thing to do.  I recommend applying it to 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16465>
_______________________________________

From report at bugs.python.org  Fri Dec  6 20:38:55 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 Dec 2013 19:38:55 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386358735.64.0.355963101602.issue19904@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions:  -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:05:27 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 06 Dec 2013 20:05:27 +0000
Subject: [issue16373] Recursion error comparing set() and collections.Set
 instances
In-Reply-To: <1351694000.44.0.179883669733.issue16373@psf.upfronthosting.co.za>
Message-ID: <1386360327.62.0.257389020971.issue16373@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This should be backported to Python 2.7 as well.

----------
assignee: rhettinger -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16373>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:06 2013
From: report at bugs.python.org (Fil Mackay)
Date: Fri, 06 Dec 2013 20:45:06 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386362706.54.0.713694423648.issue19904@psf.upfronthosting.co.za>


Fil Mackay added the comment:

The use case is interacting with C structures that have 128/256/512 bit integers in them. These require correct memory alignment, and can't reliably be hacked with multiple int64's.

These size ints come from the fact that CPU's now have registers of these sizes, and can't be serviced with int.from/to_bytes for performance reasons. The same reason int64 being supported with this approach would be very inconvenient and terrible for performance since they are an intrinsic type in modern hardware, not a software construction.

Two key use cases I can think of are:

- any form of integer SIMD operation (vectors)
- hosting and maintaining hash values which are routinely 128-bit and greater

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:43 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:45:43 +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: <1386362743.72.0.560377771611.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file24568/pickle.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:45 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:45:45 +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: <1386362745.47.0.874326518999.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file24640/BytestrPickler_c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:46 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:45:46 +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: <1386362746.86.0.560252077734.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file24688/test_pickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:47 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:45:47 +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: <1386362747.82.0.905241421288.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file24719/pickle_bytestr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:48 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:45:48 +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: <1386362748.8.0.877174681403.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file24906/pickle_bytes_code.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:45:49 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:45:49 +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: <1386362749.95.0.664054402593.issue6784@psf.upfronthosting.co.za>


Changes by Merlijn van Deen <valhallasw at gmail.com>:


Removed file: http://bugs.python.org/file24907/pickle_bytes_tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:46:37 2013
From: report at bugs.python.org (Fil Mackay)
Date: Fri, 06 Dec 2013 20:46:37 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386362797.88.0.65968680961.issue19904@psf.upfronthosting.co.za>


Fil Mackay added the comment:

I noticed that python 2.7 has been removed - why would this not be appropriate for this version?

Given the current level of use of this version, I see it's inclusion as very important - without having to be relegated to 3.x only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:47:18 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 06 Dec 2013 20:47:18 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386362838.97.0.0218718829224.issue19904@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Fri Dec  6 21:47:25 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 20:47:25 +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: <1386362845.45.0.152890563021.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

Hi Alexandre,

Attached is a diff based on r87793:0c508d87f80b.

Merlijn

----------
Added file: http://bugs.python.org/file33011/bytestrpickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Fri Dec  6 22:13:59 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2013 21:13:59 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
Message-ID: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Since today test_venv fails because Avira Antivir claims that easy_install.exe contains the trojan horse TR/Crypt.XPACK.Gen-4. I haven't seen the issue before. I'm running CPython default on Windows 7 64bit with Avira 13.

----------
files: easyinstall.png
messages: 205402
nosy: christian.heimes, dstufft, larry, ncoghlan
priority: release blocker
severity: normal
status: open
title: TR/Crypt.XPACK.Gen-4 in easy_install.exe
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file33012/easyinstall.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Fri Dec  6 22:17:46 2013
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Dec 2013 21:17:46 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386364666.16.0.539306041246.issue19904@psf.upfronthosting.co.za>


Tim Peters added the comment:

Fil, here's the release schedule for Python 2.8:

    http://www.python.org/dev/peps/pep-0404/

In short, 2.8 will never be released (well, never by us), and only bugfixes can be applied to the 2.7 line.  That's why 2.7 was removed.  Regardless of its merits, this is a new feature request, not a bugfix.

A future Python 3 release is the only possibility for new features.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Fri Dec  6 22:24:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 21:24:27 +0000
Subject: [issue16373] Recursion error comparing set() and collections.Set
 instances
In-Reply-To: <1351694000.44.0.179883669733.issue16373@psf.upfronthosting.co.za>
Message-ID: <3dbmyf6nPyz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset 9bf55766d935 by Serhiy Storchaka in branch '2.7':
Issue #16373: Prevent infinite recursion for ABC Set class comparisons.
http://hg.python.org/cpython/rev/9bf55766d935

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16373>
_______________________________________

From report at bugs.python.org  Fri Dec  6 22:25:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Dec 2013 21:25:14 +0000
Subject: [issue16373] Recursion error comparing set() and collections.Set
 instances
In-Reply-To: <1351694000.44.0.179883669733.issue16373@psf.upfronthosting.co.za>
Message-ID: <1386365114.41.0.544381359377.issue16373@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Done.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16373>
_______________________________________

From report at bugs.python.org  Fri Dec  6 22:40:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 21:40:32 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386366032.25.0.36813667749.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a new patch.  Note that it includes a commented-out test that demonstrates the failure if the socket object itself is closed (rather than just its FD).

----------
Added file: http://bugs.python.org/file33013/unregister2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Fri Dec  6 22:43:13 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Dec 2013 21:43:13 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1386366193.73.0.961107351695.issue19913@psf.upfronthosting.co.za>


Christian Heimes added the comment:

7 of 47 AV programs detect malicious software in PIPs easy_install.exe:

Agnitum 	Packed/MPress 	20131206
AhnLab-V3 	Trojan/Win32.TesA 	20131206
AntiVir 	TR/Crypt.XPACK.Gen4 	20131206 
Bkav 	HW32.CDB.9028 	20131206 
McAfee-GW-Edition 	Heuristic.BehavesLike.Win32.Suspicious-BAY.K 	20131206 
TrendMicro 	PAK_Generic.001 	20131206
TrendMicro-HouseCall 	PAK_Generic.001 	20131206 

https://www.virustotal.com/de/file/4a22ec7ceae5bb480c3dbda55f13838af0cef9ed6e1d033e896723c29eadbb19/analysis/1386366065/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Fri Dec  6 23:00:53 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 22:00:53 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386367253.07.0.59743525311.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's a variant that documents the ValueError issue and omits the commented-out test.

----------
Added file: http://bugs.python.org/file33014/unregister3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Fri Dec  6 23:15:16 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 22:15:16 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386368116.71.0.314149961478.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Here's an attempt at fixing the ValueError.

I don't like the exhaustive search much, but the alternative is to maintain an inverse dict.  What do you think?

----------
Added file: http://bugs.python.org/file33015/unregister4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Fri Dec  6 23:59:10 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 06 Dec 2013 22:59:10 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386368116.71.0.314149961478.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0KE-7Yu0_VEm+Bw8DcD_FoxoM_ghKLLig42K5hc-ojSQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Guido van Rossum added the comment:
>
> Here's an attempt at fixing the ValueError.
>
> I don't like the exhaustive search much, but the alternative is to maintain an inverse dict.  What do you think?

I was going to suggest such an exhaustive search.
I think it's the cleanest/simplest solution, and the performance
overhead is IMO completely unimportant since it's not supposed to
happen often, and if the key isn't found we're going to raise an
exception anyway.

So if we want to handle this case (and I think we should to be
consistent), that's the best way to go.

But I think that OSError should still be caught in
EpollSelector.unregister(): since if the FD is closed before,
epoll.unregister() will raise ENOENT/EBADF since the FD will have
automatically been removed (exactly as for kqueue according to the man
page).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 00:18:50 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Dec 2013 23:18:50 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386371930.11.0.0896296625338.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I'll make a new patch (maybe Monday).  I want to be a little more careful with the exhaustive search, I think it should not be attempted if we see KeyError or AttributeError (those should not be dynamic).

I tested for the epoll error on Ubuntu and didn't get OSError, but I'm happy to keep it in if the man pays says so.  (How sure are you about poll() not doing this?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 00:22:12 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 06 Dec 2013 23:22:12 +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: <1386372132.7.0.432169996226.issue6784@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

I have fixed most of the nits in this patch, except for:

1) the intermediate bytes object being created; inlining is an option, as storchaka suggested, but I'd rather have you decide what it should become before implementing it;

2) make clinic gives me 

./python -E ./Tools/clinic/clinic.py --make
Error in file "./Modules/_pickle.c" on line 6611:
Checksum mismatch!
Expected: bed0d8bbe1c647960ccc6f997b33bf33935fa56f
Computed: 58dcccb705487695fec30980f566027bc68d9c69
make: *** [clinic] Error 255

and I have no clue how to fix that -- the clinic docs are sparse, to say the least;

3) The tests are still in their own test case; please decide between the two of you what is the best solution;

4) I have grouped the test cases: test_load_python2_str_as_bytes (which checks protocols 0, 1, and 2), test_load_python2_unicode_as_str and test_load_long_python2_str_as_bytes;

5) I have moved the commands to create the shown pickled versions from docstrings to comments. If you think they are not useful, I'll remove them, but I found them pretty useful while shortening the strings.

----------
Added file: http://bugs.python.org/file33016/bytestrpickle.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Dec  7 00:27:27 2013
From: report at bugs.python.org (HCT)
Date: Fri, 06 Dec 2013 23:27:27 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
Message-ID: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>


New submission from HCT:

not sure if this ever worked. first time using help([object]), but these should work according to the documentation. OS is Win7 SP1 32-bit.

Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> help(list)
Not enough memory.

>>> help(list())
Not enough memory.

>>> help([])
Not enough memory.

>>> help(tuple())
Not enough memory.

>>> help(())
Not enough memory.

>>> help(str.format)
Not enough memory.

>>> help(str)
Not enough memory.

>>> help(b'1234')
Not enough memory.

>>> help(str.strip)
Not enough memory.

>>> help(str.count)
Not enough memory.

>>>

----------
components: Interpreter Core
messages: 205413
nosy: hct
priority: normal
severity: normal
status: open
title: help([object]) returns "Not enough memory." on standard Python types, object and object functions
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Sat Dec  7 00:57:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Dec 2013 23:57:51 +0000
Subject: [issue19900] improve pickle intro
In-Reply-To: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>
Message-ID: <3dbrMg1RNWz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 609325d187bf by Antoine Pitrou in branch '3.3':
Issue #19900: improve generalities at the start of the pickle module doc
http://hg.python.org/cpython/rev/609325d187bf

New changeset 595b8f82569c by Antoine Pitrou in branch 'default':
Issue #19900: improve generalities at the start of the pickle module doc
http://hg.python.org/cpython/rev/595b8f82569c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19900>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:06:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:06:28 +0000
Subject: [issue19900] improve pickle intro
In-Reply-To: <1386266808.09.0.595733431093.issue19900@psf.upfronthosting.co.za>
Message-ID: <1386374788.35.0.514254533144.issue19900@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19900>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:08:44 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Dec 2013 00:08:44 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1386374924.37.0.310855119706.issue19837@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> Changing return type based on argument *values* is still a bad idea in
general.

I understand the proposal to be changing the return based on argument *presence*. It strikes me a a convenient abbreviation for making a separate encoding call and definitely (specifically?) less bad than a separate module or separate functions.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19837>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:11:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:11:27 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1386375087.83.0.594153934592.issue19837@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To give another data point: returning a different type based on argument value is also what the open() functions does, more or less.

(that said, I would slightly favour a separate dump_bytes(), myself)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19837>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:12:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:12:01 +0000
Subject: [issue19888] Three argument type() super call sets __name__ but not
 __qualname__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386375121.84.0.0545287300126.issue19888@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, then it's no security issue at all :)

----------
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19888>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:12:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Dec 2013 00:12:03 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386375123.52.0.265322931294.issue19846@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Unless there is an actually possibility of changing this, which I doubt since it is a choice and not a bug, and changing might break things, this issue should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:13:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:13:52 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386375232.3.0.0487605837567.issue19846@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think the ship has sailed on this. We can't change our heuristic everyone someone finds a flaw in the current one.

In the long term, all sensible UNIX systems should be configured for utf-8 filenames and contents, so it won't make a difference anymore.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:15:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:15:15 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386375315.97.0.281469011568.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would prefer if you made the test simpler. The current setup makes it difficult to understand and reproduce with the command line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:27:06 2013
From: report at bugs.python.org (anon)
Date: Sat, 07 Dec 2013 00:27:06 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
Message-ID: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>


New submission from anon:

For many numeric algorithms it's useful to be able to read individual bits at a location in an integer. Currently there is no efficient way to do this. The following function is the closest to this:

def bit_at(i, n): return (i>>n)&1

However in computing the intermediate result i>>n we must spend O(b-n) time at least (where b is n.bit_length()). It should be possible to read bits in O(1) time. Adding int.bit_at(n) would complement int.bit_length().

I would suggest making the semantics of i.bit_at(n) the same as (i>>n)&1. Although the exact meaning when i is negative should be considered.

Real world uses of bit_at include binary exponentiation and bit counting algorithms.

----------
messages: 205421
nosy: anon
priority: normal
severity: normal
status: open
title: int.bit_at(n) - Accessing a single bit in O(1)
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:28:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:28:01 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386376081.97.0.1490761086.issue19915@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +mark.dickinson, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:28:24 2013
From: report at bugs.python.org (=?utf-8?q?Michael_M=C3=BCller?=)
Date: Sat, 07 Dec 2013 00:28:24 +0000
Subject: [issue19907] gettext - Non ascii chars in header
In-Reply-To: <1386328833.52.0.797354581277.issue19907@psf.upfronthosting.co.za>
Message-ID: <1386376104.49.0.72036399759.issue19907@psf.upfronthosting.co.za>


Michael M?ller added the comment:

Used encoding is utf-8.
Testfile I used added to this comment.

Second about the PO-Revision-Date:
It should be human readable. It's unimportant for the program itself - it's used for the translator of the xxx.po file.
Normally the whole header could be removed while compiling (except the encoding of course)

----------
Added file: http://bugs.python.org/file33017/messages.po

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19907>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:30:49 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Sat, 07 Dec 2013 00:30:49 +0000
Subject: [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386376249.88.0.404316576547.issue19910@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

There we go. I have changed the references to compile(), both in the docstring, and the documentation so that it states clearly that a bytes object is also acceptable as the "source" argument.

I also fixed the docstring to mention explicitly that it can also accept an AST as the "source argument".

Since this is my very first contribution to Python, I welcome all feedback. Thanks for your time.

----------
keywords: +patch
nosy: +Fotis.Koutoulakis
Added file: http://bugs.python.org/file33018/issue19910_python.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19910>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:36:28 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 07 Dec 2013 00:36:28 +0000
Subject: [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386376588.93.0.220477637933.issue19910@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks!  Patch looks good to me.

----------
keywords: +needs review
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19910>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:44:47 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Dec 2013 00:44:47 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386377087.99.0.492690755043.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

I'd rather see `i.bits_at(pos, width=1)`, to act like

(i >> pos) & ((1 << width) - 1)

That is, extract the `width` consecutive bits at positions 2**pos through 2**(pos + width - 1) inclusive.

Because Python ints maintain the illusion of having an infinite number of sign bits, I don't think negative `pos` (or `width`) can be assigned a sensible meaning.  Python ints only have "one end".

And, yup, I've often wanted this too!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:52:23 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 07 Dec 2013 00:52:23 +0000
Subject: [issue19888] Three argument type() super call sets __name__ but not
 __qualname__
In-Reply-To: <1386194767.46.0.367836396475.issue19888@psf.upfronthosting.co.za>
Message-ID: <1386377543.83.0.0351293921646.issue19888@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Oops, correct!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19888>
_______________________________________

From report at bugs.python.org  Sat Dec  7 01:59:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 00:59:58 +0000
Subject: [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <1386377998.9.0.461657776203.issue19910@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/issue19910>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:09:10 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Dec 2013 01:09:10 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386378550.76.0.46762959469.issue19915@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I've often wanted this too!

My want has been for a bitarray (parallel to the existing bytearray type).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:15:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 01:15:04 +0000
Subject: [issue19910] Document that compile() source may be bytes
In-Reply-To: <1386346366.06.0.667657442144.issue19910@psf.upfronthosting.co.za>
Message-ID: <3dbt4c2HhBz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 500cc1acc42f by Benjamin Peterson in branch '3.3':
document that compile() can take bytes (closes #19910)
http://hg.python.org/cpython/rev/500cc1acc42f

New changeset 44dacafdd48a by Benjamin Peterson in branch 'default':
merge 3.3 (#19910)
http://hg.python.org/cpython/rev/44dacafdd48a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19910>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:16:15 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 Dec 2013 01:16:15 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386378975.16.0.512754891965.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

Raymond, I expect they have overlapping - but not identical - audiences.  There's seem to be a quite capable bitarray extension here:

https://pypi.python.org/pypi/bitarray/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:32:58 2013
From: report at bugs.python.org (HCT)
Date: Sat, 07 Dec 2013 01:32:58 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386379978.98.0.837871259973.issue19915@psf.upfronthosting.co.za>


HCT added the comment:

or just allow slicing of int. otherwise function call overhead may defeat the speed up of such function.

----------
nosy: +hct

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:37:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 01:37:29 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386380249.65.0.593162717167.issue19904@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> any form of integer SIMD operation (vectors)

Wouldn't these be appropriately represented by a tuple of integers (or floats)? For example, a SIMD vector of four 32-bit integers could be represented as four Python ints. Or would that be "terrible for performance"?

Note that the struct module may include support for int128_t, but it certainly won't have native support for every SIMD vector format under the sun (if they have different alignment requirements).

> hosting and maintaining hash values which are routinely 128-bit and greater

That sounds like a job for a bytes object (as returned by e.g. hashlib.sha1(...).digest()).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:51:30 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 01:51:30 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386381090.34.0.467347621107.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

So I think this is why epoll doesn't raise OSError:

http://hg.python.org/cpython/file/44dacafdd48a/Modules/selectmodule.c#l1335

The Python wrapper explicitly checks for EBADF and turns this into a non-error result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 02:58:56 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 01:58:56 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386381536.61.0.888590575063.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, I take it back. If you close the FD and then reuse it, you get ENOENT, which is not caught.  So we still need the try/except OSError.

I am going to experiment with a PollSelector as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 03:00:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 02:00:32 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386381632.44.0.788357783542.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

PollSelector doesn't seem to have this behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 03:19:37 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 02:19:37 +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: <1386382777.49.0.0551501212839.issue6784@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I cleaned up the patch. I will submit it tonight if there is no major objections.

----------
Added file: http://bugs.python.org/file33019/pickle_python2_str_as_bytes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Dec  7 03:57:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 02:57:04 +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: <1386385024.39.0.249009986986.issue6784@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

How about updating the documentation as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Dec  7 04:33:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Dec 2013 03:33:55 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386387235.4.0.69135394667.issue19914@psf.upfronthosting.co.za>


R. David Murray added the comment:

This works in general, so there must be something odd going on with your system.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Sat Dec  7 04:37:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 03:37:32 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386387452.77.0.21125493009.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

New patch. Please review.

The error handling is a bit complicated but I like to be careful in which errors I catch.

----------
Added file: http://bugs.python.org/file33020/unregister5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 07:25:24 2013
From: report at bugs.python.org (soumen ganguly)
Date: Sat, 07 Dec 2013 06:25:24 +0000
Subject: [issue19916] urllib2 fails on https,SSL broken.
Message-ID: <1386397524.1.0.0289783025044.issue19916@psf.upfronthosting.co.za>


New submission from soumen ganguly:

>>import urllib2
>>urllib2.urlopen('https://example.com')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
    return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
    response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 427, in _open
    'unknown_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
    result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1249, in unknown_open
    raise URLError('unknown url type: %s' % type)
urllib2.URLError: <urlopen error unknown url type: https>
------------------------------------------------------------------------
>>import ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ssl.py", line 60, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: /usr/lib/python2.7/lib-dynload/_ssl.so: symbol SSLeay_version, version OPENSSL_1.0.1 not defined in file libcrypto.so.10 with link time reference

----------
components: Build
messages: 205439
nosy: sganguly
priority: normal
severity: normal
status: open
title: urllib2 fails on https,SSL broken.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19916>
_______________________________________

From report at bugs.python.org  Sat Dec  7 08:47:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 07:47:30 +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: <1386402450.53.0.430904849063.issue6784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And what about an issue mentioned in msg153659?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Dec  7 08:52:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 07:52:46 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386402766.23.0.739261107967.issue19915@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> My want has been for a bitarray (parallel to the existing bytearray type).

Or bitview (parallel to the existing memoryview type). It should work as with int's and bytes object's (immutable), so with bytearray (mutable).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 09:04:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 08:04:15 +0000
Subject: [issue19887] Path.resolve() ENAMETOOLONG on pathologic symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386403455.85.0.616932474845.issue19887@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How the test can be simpler? It is already simple.

You ca use pathlib_resolve_test.py but replace `os.symlink('.', 'testdir/0')` by `os.symlink(os.path.abspath('testdir'), 'testdir/0')`. Or use following shell commands:

mkdir testdir
for i in $(seq 100); do ln -s $((i-1))/$((i-1)) testdir/$i; done
ln -s "$(pwd)/testdir" testdir/0

./python -c "import pathlib; print(pathlib.Path('testdir/100').resolve())"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Sat Dec  7 09:10:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 08:10:25 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386403825.02.0.417171994873.issue19887@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: Path.resolve() ENAMETOOLONG on pathologic symlinks -> Path.resolve() fails on complex symlinks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Sat Dec  7 10:09:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 09:09:38 +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: <3dc4cK6x8Mz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset bd71352e950f by Alexandre Vassalotti in branch 'default':
Issue #6784: Strings from Python 2 can now be unpickled as bytes objects.
http://hg.python.org/cpython/rev/bd71352e950f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Dec  7 10:12:55 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:12:55 +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: <1386407575.8.0.0932260828655.issue6784@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

I fixed up the last few review comments and submitted the patch. Thank you for the help!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6784>
_______________________________________

From report at bugs.python.org  Sat Dec  7 10:16:43 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:16:43 +0000
Subject: [issue6673] Uncaught comprehension SyntaxError eats up all memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1386407803.0.0.509024050057.issue6673@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
nosy:  -alexandre.vassalotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6673>
_______________________________________

From report at bugs.python.org  Sat Dec  7 10:32:30 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:32:30 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1386408750.39.0.859869341085.issue12290@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> patch review
versions: +Python 3.4 -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/issue12290>
_______________________________________

From report at bugs.python.org  Sat Dec  7 10:33:40 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 09:33:40 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1386408820.97.0.120102006395.issue12290@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12290>
_______________________________________

From report at bugs.python.org  Sat Dec  7 11:17:59 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 07 Dec 2013 10:17:59 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
 unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1386411479.97.0.446310873129.issue13566@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

Adding a special type is not a bad idea. We have to keep the code for loading BINSTRING opcodes anyway, so we might as well use it. It could be helpful for unit-testing our Python 2 compatibility support for pickle.

We should still fix array in 2.7 to accept unicode object for the typecode though.

----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13566>
_______________________________________

From report at bugs.python.org  Sat Dec  7 11:44:40 2013
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 07 Dec 2013 10:44:40 +0000
Subject: [issue19917] [httplib] logging information for request is not pretty
 printed
Message-ID: <1386413080.92.0.351429113589.issue19917@psf.upfronthosting.co.za>


New submission from Matej Cepl:

looking at
http://hg.python.org/cpython/file/543c76769c14/Lib/http/client.py#l847
(logging in HTTPConnection.send method; but this code has been same since like forever) I see that the HTTP request is NOT pretty printed:

     if self.debuglevel > 0:
         print("send:", repr(data))

whereas response in effect (because every header is printed separately) is. Wouldn't it be better to pretty print the request as well?

Otherwise I get quite unreadable debugging logs like the following (notice how much response is more readable than request).

It seems to me that proper solution could be just to replace repr() here with something more readable. Wouldn't just str() help? Barring that we can go all the way to pprint.pformat().

----------
components: Library (Lib)
files: urllib2-kerberos-log.txt
messages: 205446
nosy: mcepl
priority: normal
severity: normal
status: open
title: [httplib] logging information for request is not pretty printed
Added file: http://bugs.python.org/file33021/urllib2-kerberos-log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19917>
_______________________________________

From report at bugs.python.org  Sat Dec  7 11:47:49 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 07 Dec 2013 10:47:49 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386413269.82.0.210123614095.issue19904@psf.upfronthosting.co.za>


Stefan Krah added the comment:

If performance is the reason for the feature: My impression is that
the goal of the struct module is not necessarily top performance.

E.g. in memoryview the custom unpackers for comparisons are 30-60 times
faster than using the struct module.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Sat Dec  7 12:02:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 11:02:31 +0000
Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive
Message-ID: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import pathlib
>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('C:/Foo')
PureWindowsPath('Bar')
>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('C:/foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pathlib.py", line 797, in relative_to
    .format(str(self), str(formatted)))
ValueError: 'C:\\Foo\\Bar' does not start with 'C:\\foo'
>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('c:/Foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/pathlib.py", line 797, in relative_to
    .format(str(self), str(formatted)))
ValueError: 'C:\\Foo\\Bar' does not start with 'c:\\Foo'

It also returns strange result when an argument is naked drive:

>>> pathlib.PureWindowsPath('C:/Foo/Bar').relative_to('C:')
PureWindowsPath('//Foo/Bar')

----------
components: Library (Lib)
messages: 205448
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: PureWindowsPath.relative_to() is not case insensitive
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19918>
_______________________________________

From report at bugs.python.org  Sat Dec  7 12:19:29 2013
From: report at bugs.python.org (anon)
Date: Sat, 07 Dec 2013 11:19:29 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386415169.35.0.798178286397.issue19915@psf.upfronthosting.co.za>


anon added the comment:

I like the i.bits_at(pos, width=1) suggestion. Unless slicing is chosen instead this seems the most future-proof idea.

I think slicing semantically "seems wrong" but it might be more elegant. It might also make catching errors harder (in the case where an int is sent to a function that does slicing and now won't fail with a TypeError).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 12:47:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 11:47:19 +0000
Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive
In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>
Message-ID: <1386416839.04.0.315865792887.issue19918@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes first bug.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file33022/pathlib_relative_to.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19918>
_______________________________________

From report at bugs.python.org  Sat Dec  7 13:47:49 2013
From: report at bugs.python.org (Jon Clements)
Date: Sat, 07 Dec 2013 12:47:49 +0000
Subject: [issue18925] select.poll.modify is not documented
In-Reply-To: <1378328037.99.0.424927131422.issue18925@psf.upfronthosting.co.za>
Message-ID: <1386420469.75.0.682961680965.issue18925@psf.upfronthosting.co.za>


Jon Clements added the comment:

Was looking up epoll.modify and noticed in the docs it's listed as "
Modify a register file descriptor." - I believe that should be "Modify a registered file descriptor"...

----------
nosy: +joncle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18925>
_______________________________________

From report at bugs.python.org  Sat Dec  7 14:02:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 13:02:46 +0000
Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive
In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>
Message-ID: <1386421366.52.0.287860740226.issue19918@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually relative_to() returns invalid path object.

>>> import pathlib
>>> p = pathlib.PureWindowsPath('C:/Foo/Bar/Baz').relative_to('C:')
>>> p
PureWindowsPath('//Foo/Bar/Baz')
>>> str(p)
'\\\\Foo\\Bar\\Baz'
>>> p.drive
''
>>> p.root
''
>>> p.parts
('\\', 'Foo', 'Bar', 'Baz')
>>> p.is_absolute()
False
>>> p2 = pathlib.PureWindowsPath(str(p))
>>> p2.drive
'\\\\Foo\\Bar'
>>> p2.root
'\\'
>>> p2.parts
('\\\\Foo\\Bar\\', 'Baz')
>>> p2.is_absolute()
True

Here is a patch which fixes both bugs.

>>> import pathlib
>>> p = pathlib.PureWindowsPath('C:/Foo/Bar/Baz').relative_to('C:')
>>> p
PureWindowsPath('/Foo/Bar/Baz')
>>> str(p)
'\\Foo\\Bar\\Baz'
>>> p.drive
''
>>> p.root
'\\'
>>> p.parts
('\\', 'Foo', 'Bar', 'Baz')

----------
Added file: http://bugs.python.org/file33023/pathlib_relative_to_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19918>
_______________________________________

From report at bugs.python.org  Sat Dec  7 14:08:00 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Dec 2013 13:08:00 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386421680.88.0.190962819182.issue19915@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I'd rather see `i.bits_at(pos, width=1)`

Me too.  Extracting sign, exponent and significand fields from the binary representation of a float is at least one thing I'd use this for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 14:58:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Dec 2013 13:58:45 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386424725.41.0.661593748126.issue19915@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/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 15:01:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Dec 2013 14:01:31 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386424891.21.0.812042531993.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If you want to avoid the encoding errors, you can also use PYTHONIOENCODING=:replace or PYTHONIOENCODING=:backslashreplace in Python 3.4 to use the locale encoding, but use an error handler different than strict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 15:15:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 14:15:11 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386425711.26.0.184407891662.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> How the test can be simpler? It is already simple.

I mean, don't use loops but a simple test setup as in test_resolve_dot.
I am not interested in the pathologic "100 symlinks" case, just the case where the symlink is absolute.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Sat Dec  7 15:38:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 07 Dec 2013 14:38:22 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386427102.88.0.133957224927.issue19887@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

And don't forget to use self.dirlink instead of os.symlink(src, dst, target_is_directory=True).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Sat Dec  7 15:44:24 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Dec 2013 14:44:24 +0000
Subject: [issue19916] urllib2 fails on https,SSL broken.
In-Reply-To: <1386397524.1.0.0289783025044.issue19916@psf.upfronthosting.co.za>
Message-ID: <1386427464.52.0.462222077229.issue19916@psf.upfronthosting.co.za>


R. David Murray added the comment:

This isn't a bug in Python, it is a bug in your particular *installation* of Python (or OpenSSL).  Your best resource for getting help resolving this would be to post to the python-list mailing list, or to a support forum for your particular Linux distribution.

----------
nosy: +r.david.murray
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19916>
_______________________________________

From report at bugs.python.org  Sat Dec  7 15:52:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 14:52:02 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386427922.19.0.821355682715.issue19887@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with unrolled loops.

----------
Added file: http://bugs.python.org/file33024/pathlib_resolve_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:00:20 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Dec 2013 15:00:20 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1386428420.02.0.660399187423.issue5996@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/issue5996>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:03:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Dec 2013 15:03:45 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1386428625.58.0.602985422552.issue5996@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:14:30 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 07 Dec 2013 15:14:30 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386429270.85.0.469407641779.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

Using an environment variable is not the holy grail for this. On writing a non-single-user application you can't expect the user to set extra environment variables.

If compatibility is the only reason in my opinion it would be much better to include something like sys.use_strict_encoding() which decides if print()/write() will use sys.getfilesystemencoding() or sys.getdefaultencoding().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:16:28 2013
From: report at bugs.python.org (anon)
Date: Sat, 07 Dec 2013 15:16:28 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386429388.72.0.0977184205712.issue19915@psf.upfronthosting.co.za>


anon added the comment:

I didn't really consider floats. bit_length() is only provided to ints for example.

I think a better solution to pick apart floats would be a function similar to math.frexp, if it isn't already sufficient. float.bits_at(pos, width) seems a worse solution because the position of each bit would be arbitrary. But I have no major objection against it being extended to floats.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:26:39 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 15:26:39 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1386429999.75.0.0267759136758.issue19913@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I found the offenders. distlib's wrapper scripts are detected as malicious programs by some anti virus programs.

pip/_vendor/distlib/t32.exe

https://www.virustotal.com/de/file/d06ad386d9dab9d08bdc01a3a14c713bd90b218ec4893c22da819826bd452e31/analysis/1386429889/

pip/_vendor/distlib/t64.exe

https://www.virustotal.com/de/file/b043b38b8c24c31cffed5e29e995d879a14228901bee5b15e4158b8428e2699e/analysis/1386429784/

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:34:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 15:34:40 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1386429270.85.0.469407641779.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386430477.9327.4.camel@fsol>


Antoine Pitrou added the comment:

> Using an environment variable is not the holy grail for this. On
> writing a non-single-user application you can't expect the user to set
> extra environment variables.

I am not understanding why the user would have to set anything at all.
What is the use case for per-user encoding settings?

I understand that passing LANG=C (e.g. to disable a program's
translations) forces ASCII instead of UTF-8, which is a flaw. Perhaps
the filesystem encoding should be set to UTF-8 when the system locale
says ASCII.

(OTOH, it's IMHO a system bug that LANG=C forces the ASCII charset;
we're not in the 80s anymore)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 16:54:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 15:54:47 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386431687.94.0.595574268492.issue19846@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/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:05:23 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Dec 2013 16:05:23 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1386432323.79.0.363850789791.issue19913@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Hmmm. I use mpress (http://www.matcode.com/mpress.htm) to compress the executables. These AV results seem to be false positives, given that the files are green-lit by Symantec, Sophos, McAfee, Kaspersky, F-Prot, AVG, Avast and a bunch of other reputable AV products (based on Christian's links).

I suppose the executables could be shipped uncompressed (apparently the UPX compressor also sometimes causes false positives with AV software - and UPX can't compress 64-bit executables).

There have been complaints in the past that Avira's heuristics are not careful enough:

https://forum.avira.com/wbb/index.php?page=Thread&threadID=127271

That link points to a 2011 thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:09:40 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 16:09:40 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1386432580.37.0.261857902202.issue19913@psf.upfronthosting.co.za>


Christian Heimes added the comment:

How are you creating these files anyway? I can't find any documentation or source files in distlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:10:51 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Dec 2013 16:10:51 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386432651.58.0.606199015507.issue19846@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Antoine's suggestion of being a little more aggressive in choosing utf-8 over ascii as the OS API encoding sounds reasonable to me.

I think we're getting to a point where a system claiming ASCII as the encoding to use is almost certainly a misconfiguration rather than a desired setting. If someone *really* means ASCII, they can force it for at least the std streams with PYTHONIOENCODING.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:18:40 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Dec 2013 16:18:40 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1386433120.69.0.118770416844.issue19913@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

It's in the docs at e.g.

http://distlib.readthedocs.org/en/latest/reference.html?highlight=launcher#distlib.scripts.ScriptMaker.__init__

and in the code at e.g.

https://bitbucket.org/vinay.sajip/distlib/src/a50562ee0b535b2966948f1a657c1cac4c1536eb/distlib/scripts.py?at=default#cl-272

The project to generate the launchers is at

https://bitbucket.org/vinay.sajip/simple_launcher/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:48:37 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 16:48:37 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
Message-ID: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>


New submission from Christian Heimes:

On Windows the test_connect_ex_error sometimes fails with EWOULDBLOCK instead of ECONNREFUSED. Valhallasw sometimes gets the same error with an Ubuntu VM on Windows. This might be a Windows socket issue. 

======================================================================
FAIL: test_connect_ex_error (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 10061 != 10035

>>> for k, v in errno.__dict__.items():
...     if v == 10035: print(k)
...
EWOULDBLOCK
WSAEWOULDBLOCK
>>> for k, v in errno.__dict__.items():
...     if v == 10061: print(k)
...
WSAECONNREFUSED
ECONNREFUSED

----------
components: Tests
messages: 205467
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: SSL: test_connect_ex_error fails with EWOULDBLOCK
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:49:39 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 16:49:39 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386434979.98.0.170615355055.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sorry, here's another version. It keeps the original _fileobj_to_fd function and wraps it with a method that does the exhaustive search.

----------
Added file: http://bugs.python.org/file33025/unregister6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 17:58:39 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 07 Dec 2013 16:58:39 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1386435519.96.0.404510920148.issue19919@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

My error is slightly different:

$ ./python -i -c "from test.test_ssl import *; support.run_unittest(NetworkedTests)"
(...)

======================================================================
FAIL: test_connect_ex_error (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/valhallasw/src/cpython/Lib/test/test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 111 != 11

----------------------------------------------------------------------
Ran 15 tests in 33.590s

FAILED (failures=1, skipped=1)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/valhallasw/src/cpython/Lib/test/support/__init__.py", line 1719, in run_unittest
    _run_suite(suite)
  File "/home/valhallasw/src/cpython/Lib/test/support/__init__.py", line 1694, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "/home/valhallasw/src/cpython/Lib/test/test_ssl.py", line 1205, in test_connect_ex_error
    s.connect_ex(("svn.python.org", 444)))
AssertionError: 111 != 11

>>> errno.errorcode[11]
'EAGAIN'
>>> errno.errorcode[111]
'ECONNREFUSED'

This is on Ubuntu x64 12.04 LTS, under VirtualBox 4.3.4 (r91027), running on Windows 7 Professional (6.1.7601).

OpenSSL versions as returned by test_ssl:

$ ./python -m Lib.test.test_ssl
test_ssl: testing with 'OpenSSL 1.0.1 14 Mar 2012' (1, 0, 1, 0, 15)
          under Linux ('debian', 'wheezy/sid', '')
          HAS_SNI = True
          OP_ALL = 0x800003ff
          OP_NO_TLSv1_1 = 0x10000000

----------
nosy: +valhallasw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:01:25 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 17:01:25 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1386435685.93.0.684077304146.issue19919@psf.upfronthosting.co.za>


Christian Heimes added the comment:

EAGAIN          Resource temporarily unavailable (may be the same value as EWOULDBLOCK) (POSIX.1)

Can you please check of EAGAIN and EWOULDBLOCK are the same value on your Linux box? They are the same on my box:

>>> import errno
>>> errno.EAGAIN, errno.EWOULDBLOCK
(11, 11)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:03:50 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 07 Dec 2013 17:03:50 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1386435830.73.0.285220903449.issue19919@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

Yes, they are.

>>> errno.EWOULDBLOCK
11

EAGAIN and EWOULDBLOCK are the only two with that errno:
>>> [(k,v) for (k,v) in errno.__dict__.items() if v==11]
[('EWOULDBLOCK', 11), ('EAGAIN', 11)]

111 is just ECONNREFUSED:
>>> [(k,v) for (k,v) in errno.__dict__.items() if v==111]
[('ECONNREFUSED', 111)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:17:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 17:17:20 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386436640.76.0.777660763339.issue19846@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

$ LANG=C ./python -c "import os, sys, locale; print(sys.getfilesystemencoding(), sys.stdin.encoding, os.device_encoding(0), locale.getpreferredencoding())"

-> Without the patch:
ascii ANSI_X3.4-1968 ANSI_X3.4-1968 ANSI_X3.4-1968

-> With the patch:
utf-8 utf-8 utf-8 ANSI_X3.4-1968

----------
keywords: +patch
nosy: +larry
stage:  -> patch review
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file33026/asciilocale.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:25:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 17:25:42 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386437142.92.0.604576397378.issue19846@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:26:49 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 07 Dec 2013 17:26:49 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386437209.83.0.574618053394.issue19915@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Sorry, I wasn't clear.  I'm not interested in applying this to floats themselves; I'm interested in applying it to the bit pattern of a float when that bit pattern is treated as an integer.

> But I have no major objection against it being extended to floats.

I do!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:27:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 17:27:16 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1386437236.14.0.0740940042159.issue19919@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The explanation for EAGAIN is in the test just above (test_timeout_connect_ex). Read it.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:37:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 17:37:40 +0000
Subject: [issue19920] TarFile.list() fails on some files
Message-ID: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

TarFile.list() fails on some files. In particular on Lib/test/testtar.tar.

>>> import tarfile
>>> tarfile.open('Lib/test/testtar.tar').list()
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/conttype 
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/regtype 
?rwxr-xr-x tarfile/tarfile          0 2003-01-06 01:19:43 ustar/dirtype/ 
?rwxr-xr-x tarfile/tarfile        255 2003-01-06 01:19:43 ustar/dirtype-with-size/ 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/lnktype link to ustar/regtype 
?rwxrwxrwx tarfile/tarfile          0 2003-01-06 01:19:43 ustar/symtype -> regtype 
?rw-rw---- tarfile/tarfile        3,0 2003-01-06 01:19:43 ustar/blktype 
?rw-rw-rw- tarfile/tarfile        1,3 2003-01-06 01:19:43 ustar/chrtype 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/fifotype 
?rw-r--r-- tarfile/tarfile      86016 2003-01-06 01:19:43 ustar/sparse 
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1846, in list
    print(tarinfo.name + ("/" if tarinfo.isdir() else ""), end=' ')
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc4' in position 14: surrogates not allowed

Command-line interface of the tarfile module also fails:

$ ./python -m tarfile -v -l Lib/test/testtar.tar
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/conttype 
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 ustar/regtype 
?rwxr-xr-x tarfile/tarfile          0 2003-01-06 01:19:43 ustar/dirtype/ 
?rwxr-xr-x tarfile/tarfile        255 2003-01-06 01:19:43 ustar/dirtype-with-size/ 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/lnktype link to ustar/regtype 
?rwxrwxrwx tarfile/tarfile          0 2003-01-06 01:19:43 ustar/symtype -> regtype 
?rw-rw---- tarfile/tarfile        3,0 2003-01-06 01:19:43 ustar/blktype 
?rw-rw-rw- tarfile/tarfile        1,3 2003-01-06 01:19:43 ustar/chrtype 
?rw-r--r-- tarfile/tarfile          0 2003-01-06 01:19:43 ustar/fifotype 
?rw-r--r-- tarfile/tarfile      86016 2003-01-06 01:19:43 ustar/sparse 
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/serhiy/py/cpython/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 2500, in <module>
    main()
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 2444, in main
    tf.list(verbose=args.verbose)
  File "/home/serhiy/py/cpython/Lib/tarfile.py", line 1846, in list
    print(tarinfo.name + ("/" if tarinfo.isdir() else ""), end=' ')
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc4' in position 14: surrogates not allowed
?rw-r--r-- tarfile/tarfile       7011 2003-01-06 01:19:43 serhiy at raxxla:~/py/cpython$

----------
components: IO, Library (Lib), Unicode
messages: 205475
nosy: benjamin.peterson, ezio.melotti, haypo, lars.gustaebel, lemburg, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: TarFile.list() fails on some files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19920>
_______________________________________

From report at bugs.python.org  Sat Dec  7 18:46:42 2013
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 07 Dec 2013 17:46:42 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1386438402.82.0.18913487925.issue19919@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

OK. I did some network sniffing; inside the VM, this is what I see:

$ sudo tshark host 82.94.164.164
tshark: Lua: Error during loading:
 [string "/usr/share/wireshark/init.lua"]:45: dofile has been disabled
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000    10.0.2.15 -> 82.94.164.164 TCP 74 52719 > snpp [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=10175140 TSecr=0 WS=16

while on the host, this is what I see:
1	0.000000000	192.168.1.122	82.94.164.164	TCP	66	49909 > snpp [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
2	0.029908000	82.94.164.164	192.168.1.122	TCP	54	snpp > 49909 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0


Basically, the RST sent by the server never reaches the VM. This might actually happen in other NAT-ed situations, too, I guess.

But even if this is a VM issue, it *does* make the tests misbehave. Maybe receiving EAGAIN should result in a test skip instead of an error?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Sat Dec  7 19:35:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 18:35:58 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
Message-ID: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Path.mkdir() can't create a directory with cleared write or list permission bits for owner when parent directories aren't created. This is because for parent directories same mode is used as for final directory.

To support this use case we should implicitly set write and list permission bits for owner when creating parent directories.

I don't know if this work on Windows.

----------
components: Library (Lib)
files: pathlib_mkdir_mode.patch
keywords: patch
messages: 205477
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Path.mkdir(0, True) always fails
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33027/pathlib_mkdir_mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 20:01:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 19:01:23 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386442883.39.0.830678903315.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think I got the closing sorted out now, and through reordering the dup2() calls are actually needed.

----------
Added file: http://bugs.python.org/file33028/unregister7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 20:35:25 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Dec 2013 19:35:25 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1386277185.98.0.181450665143.issue19901@psf.upfronthosting.co.za>
Message-ID: <1386444925.92.0.761499023098.issue19901@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I fixed this in 3.3 and 3.4 several weeks ago.

http://hg.python.org/cpython/rev/9791c5d55f52
http://hg.python.org/cpython/rev/00766fa3366b

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19901>
_______________________________________

From report at bugs.python.org  Sat Dec  7 20:48:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Dec 2013 19:48:44 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386445724.73.0.883335387987.issue19921@psf.upfronthosting.co.za>


R. David Murray added the comment:

Wouldn't it be better to throw an error rather than create a (parent) directory with possibly wrong permission bits?  It seems like this would require an unusual use case in any event.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 20:53:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 19:53:37 +0000
Subject: [issue19857] test_imaplib doesn't always reap SocketServer thread
In-Reply-To: <1385933568.04.0.453956644253.issue19857@psf.upfronthosting.co.za>
Message-ID: <3dcLvN5k66zRBC@mail.python.org>


Roundup Robot added the comment:

New changeset fbbb591dea09 by Charles-Fran?ois Natali in branch 'default':
Issue #19857: Make sure that test_imaplib reaps server threads even in face of
http://hg.python.org/cpython/rev/fbbb591dea09

New changeset 6c81df506739 by Charles-Fran?ois Natali in branch 'default':
Issue #19857: Make sure that test_imaplib reaps server threads even in face of
http://hg.python.org/cpython/rev/6c81df506739

New changeset 78efa2c06447 by Charles-Fran?ois Natali in branch '3.3':
Issue #19857: Make sure that test_imaplib reaps server threads even in face of
http://hg.python.org/cpython/rev/78efa2c06447

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19857>
_______________________________________

From report at bugs.python.org  Sat Dec  7 21:13:43 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 Dec 2013 20:13:43 +0000
Subject: [issue19843] Wait for multiple sub-processes to terminate
In-Reply-To: <1385826813.77.0.0339260517434.issue19843@psf.upfronthosting.co.za>
Message-ID: <1386447223.13.0.507835654213.issue19843@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I do not think this is ready to live in the standard library.  

I've left some comments on your patch review.  Consider those for incorporation into the psutils project.

wait_procs() implementation should live in the psutils module on PyPI with more iteration on its implementation happening there as it isn't ready yet.

In general: We have too many APIs in the subprocess module.  I want to avoid adding more unless they are a very clear improvement to ease of use of the module.  More things with deadlock caveats similar to the existing Popen.wait() call are undesirable.

----------
nosy: +gregory.p.smith
resolution:  -> rejected
stage:  -> patch review
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19843>
_______________________________________

From report at bugs.python.org  Sat Dec  7 21:22:29 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 20:22:29 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386447749.59.0.56038356385.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, here's another try. I ran what you suggested for all three tests I added and they are all clean.  I realized that every single call to socketpair() is followed by two addCleanup calls, so I added a make_socketpair() helper method that does this.

----------
Added file: http://bugs.python.org/file33029/unregister8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 21:37:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 20:37:27 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386448647.67.0.218583181124.issue19921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The mkdir utility creates parent directories with mode 0o777 & ~umask.

$ mkdir -p -m 0 t1/t2/t3
$ ls -l -d t1 t1/t2 t1/t2/t3
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/t2/
d--------- 2 serhiy serhiy 4096 Dec  7 22:30 t1/t2/t3/

So perhaps we should just use 0o777 mode for parent directories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 21:41:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 Dec 2013 20:41:41 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386448901.49.0.54010387476.issue19921@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, emulating mkdir -p seems like the sensible thing to do.  That's the least likely to be surprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 21:59:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 20:59:38 +0000
Subject: [issue19922] mbstate_t requires _INCLUDE__STDC_A1_SOURCE
Message-ID: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>


New submission from Christian Heimes:

On HP-UX mbstate_t for mbrtowc() is only available when _INCLUDE__STDC_A1_SOURCE is defined:

http://buildbot.python.org/all/builders/PA-RISC%20HP-UX%2011iv2%20%5BSB%5D%203.x/builds/2543/steps/compile/logs/stdio

	cc -Ae -c  -O  -O   -I. -IInclude -I./Include    -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c
cc: "Objects/unicodeobject.c", line 3493: error 1000: Unexpected symbol: "mbs".
cc: "Objects/unicodeobject.c", line 3493: error 1588: "mbstate_t" undefined.
cc: "Objects/unicodeobject.c", line 3497: error 1588: "mbs" undefined.
cc: "Objects/unicodeobject.c", line 3497: warning 563: Argument #1 is not the correct type.
cc: "Objects/unicodeobject.c", line 3497: error 1594: The sizeof operator cannot be applied to types with unknown size.

----------
messages: 205486
nosy: christian.heimes, trent
priority: low
severity: normal
stage: needs patch
status: open
title: mbstate_t requires _INCLUDE__STDC_A1_SOURCE
type: compile error
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19922>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:07:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 21:07:19 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386450439.9.0.0372536898566.issue19921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch emulates the mkdir utility.

----------
Added file: http://bugs.python.org/file33030/pathlib_mkdir_mode_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:23:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 21:23:20 +0000
Subject: [issue19923] OSError: [Errno 512] Unknown error 512 in
 test_multiprocessing
Message-ID: <1386451400.97.0.885839707191.issue19923@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This rather weird error occurred on a buildbot:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9297

[346/387] test_multiprocessing_forkserver
Process Process-497:
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 616, in wait
    self._wait(timeout)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 651, in _wait
    if not self._cond.wait_for(lambda : self._state != 0, timeout):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/synchronize.py", line 326, in wait_for
    self.wait(waittime)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/synchronize.py", line 270, in wait
    self._lock.acquire()
OSError: [Errno 512] Unknown error 512

----------
components: Library (Lib)
keywords: buildbot
messages: 205488
nosy: neologix, pitrou, sbt
priority: normal
severity: normal
status: open
title: OSError: [Errno 512] Unknown error 512 in test_multiprocessing
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19923>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:37:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 21:37:10 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386452230.96.0.118912576557.issue19921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Antoine's comments.

----------
Added file: http://bugs.python.org/file33031/pathlib_mkdir_mode_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:38:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Dec 2013 21:38:24 +0000
Subject: [issue19917] [httplib] logging information for request is not pretty
 printed
In-Reply-To: <1386413080.92.0.351429113589.issue19917@psf.upfronthosting.co.za>
Message-ID: <1386452304.22.0.757454426223.issue19917@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am not an expert in web stuff, but off the top of my head, it seems that requests should be handled the same way as responses.

----------
nosy: +orsenthil, r.david.murray, terry.reedy
stage:  -> test needed
type:  -> enhancement
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19917>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:47:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 21:47:03 +0000
Subject: [issue19922] mbstate_t requires _INCLUDE__STDC_A1_SOURCE
In-Reply-To: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>
Message-ID: <1386452823.76.0.540837349601.issue19922@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file33032/issue19922.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19922>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:50:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 21:50:06 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386453006.24.0.368167254122.issue19921@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Patch looks good to me. Do you think the documentation should be clarified a bit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:54:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Dec 2013 21:54:50 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386453290.95.0.490561189835.issue19921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, please clarify the documentation.

Perhaps we should add new argument parents_mode?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 22:56:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 21:56:17 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386453377.04.0.755615719846.issue19921@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

A new argument sounds overkill to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sat Dec  7 23:01:38 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Dec 2013 22:01:38 +0000
Subject: [issue13736] urllib.request.urlopen leaks exceptions from socket and
 httplib.client
In-Reply-To: <1326003740.31.0.0410778534365.issue13736@psf.upfronthosting.co.za>
Message-ID: <1386453698.35.0.432329312687.issue13736@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/issue13736>
_______________________________________

From report at bugs.python.org  Sat Dec  7 23:14:53 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 07 Dec 2013 22:14:53 +0000
Subject: [issue19922] mbstate_t requires _INCLUDE__STDC_A1_SOURCE
In-Reply-To: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>
Message-ID: <1386454493.82.0.845130318404.issue19922@psf.upfronthosting.co.za>


Christian Heimes added the comment:

http://www.mail-archive.com/autoconf-patches at gnu.org/msg04244.html
http://modman.unixdev.net/?sektion=3&page=wcsftime&manpath=HP-UX-11.11

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19922>
_______________________________________

From report at bugs.python.org  Sat Dec  7 23:39:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 22:39:41 +0000
Subject: [issue19922] mbstate_t requires _INCLUDE__STDC_A1_SOURCE
In-Reply-To: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>
Message-ID: <3dcQb10Dppz7Ljq@mail.python.org>


Roundup Robot added the comment:

New changeset d8cfc7106f41 by Christian Heimes in branch 'default':
Issue #19922: define _INCLUDE__STDC_A1_SOURCE in HP-UX to include mbstate_t
http://hg.python.org/cpython/rev/d8cfc7106f41

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19922>
_______________________________________

From report at bugs.python.org  Sat Dec  7 23:53:07 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 07 Dec 2013 22:53:07 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386447749.59.0.56038356385.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0Abn8bmzgy7hckSq3ZZUTP38i7Q-ibKZPRSdHfAaeeAQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

LGTM!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sat Dec  7 23:54:24 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 07 Dec 2013 22:54:24 +0000
Subject: [issue19857] test_imaplib doesn't always reap SocketServer thread
In-Reply-To: <1385933568.04.0.453956644253.issue19857@psf.upfronthosting.co.za>
Message-ID: <1386456864.03.0.847082461446.issue19857@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19857>
_______________________________________

From report at bugs.python.org  Sun Dec  8 00:18:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 07 Dec 2013 23:18:40 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386458320.16.0.94578147762.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There was a previous try to use a file encoding different than the locale encoding and it introduces too many issues:
https://mail.python.org/pipermail/python-dev/2010-October/104509.html
"Inconsistencies if locale and filesystem encodings are different"

Python uses the fact that the filesystem encoding is the locale encoding in various places. For example, Python uses the C codec (mbstowcs) to decode byte string from the filesystem encoding before Python codecs can be used. For example, the ISO 8859-15 codec is implemented in Python and so you need something during Python startup until the import machinery is ready and the codec is loaded (using ascii encoding is not correct).

The C locale may use a different encoding. For example on AIX, the ISO 8859-1 encoding is used. On FreeBSD and Solaris, the ISO 8859-1 encoding is announced but the ASCII encoding is used in practice. Python forces the ascii encoding on FreeBSD to avoid other issues.

I worked hard to have Python 3 working out of the box on all platform. In my opinion, going against the locale encoding in some cases (the C locale) would introduce more issues than it solves.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 00:22:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Dec 2013 23:22:23 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1386458320.16.0.94578147762.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386458541.9327.5.camel@fsol>


Antoine Pitrou added the comment:

> Python uses the fact that the filesystem encoding is the locale
> encoding in various places.

The patch doesn't change that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 00:57:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Dec 2013 23:57:15 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <3dcSJV1CwXz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 39e7995f9ad1 by Guido van Rossum in branch 'default':
Silently ignore unregistering closed files. Fixes issue 19876. With docs and slight test refactor.
http://hg.python.org/cpython/rev/39e7995f9ad1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 00:59:32 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Dec 2013 23:59:32 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386460772.27.0.201912377383.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Is this worthy of a Misc/NEWS entry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 01:03:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 00:03:46 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <3dcSS140wsz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset f334dd2471e7 by Guido van Rossum in branch 'default':
News item for issue 19876.
http://hg.python.org/cpython/rev/f334dd2471e7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 01:04:55 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Dec 2013 00:04:55 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386461095.2.0.266037399641.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Done.

----------
assignee: neologix -> gvanrossum
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 01:24:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2013 00:24:58 +0000
Subject: [issue19924] test_venv fails with --without-threads
Message-ID: <1386462298.14.0.707345567423.issue19924@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The test fails when Python is compiled --without-threads. Two 3rd party modules import threading unconditionally:

pip/_vendor/distlib/util.py
  import threading

pip/_vendor/requests/packages/urllib3/_collections.py
  from threading import RLock

----------
messages: 205503
nosy: christian.heimes, dstufft, ncoghlan, vinay.sajip
priority: high
severity: normal
stage: needs patch
status: open
title: test_venv fails with --without-threads
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19924>
_______________________________________

From report at bugs.python.org  Sun Dec  8 01:50:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2013 00:50:08 +0000
Subject: [issue19922] mbstate_t requires _INCLUDE__STDC_A1_SOURCE
In-Reply-To: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>
Message-ID: <1386463808.73.0.16738571015.issue19922@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19922>
_______________________________________

From report at bugs.python.org  Sun Dec  8 03:08:04 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 02:08:04 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386468484.84.0.820393751952.issue19883@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

zipimport.c makes no attempt to support zip files larger than 2GiB or zip64 files.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19883>
_______________________________________

From report at bugs.python.org  Sun Dec  8 03:16:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 02:16:03 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386468963.76.0.589393750893.issue19846@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note that the *only* change Antoine's patch makes is that:

- *if* the locale encoding is ASCII (or an alias for ASCII)
- *then* Python sets the filesystem encoding to UTF-8 instead

If the locale encoding is anything *other* than ASCII, then that will still be used as the filesystem encoding, so environments that use something other than ASCII for the C locale will retain their current behaviour.

The rationale for this approach is based on the assumption that the *most likely* way to get a locale encoding of ASCII at this point in time is to use "LANG=C" on a system where the locale encoding is normally something more suited to a Unicode world (likely UTF-8).

Will assuming utf-8 sometimes cause problems? Quite possibly. But assuming that the platform's claim to only support ASCII is correct causes serious usability problems, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 03:23:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 02:23:47 +0000
Subject: [issue19924] test_venv fails with --without-threads
In-Reply-To: <1386462298.14.0.707345567423.issue19924@psf.upfronthosting.co.za>
Message-ID: <1386469427.31.0.119823186081.issue19924@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_venv: test_with_pip() failed on "AMD64 Fedora without threads 3.x" buildbot: urllib3 dependency requires the threading module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19924>
_______________________________________

From report at bugs.python.org  Sun Dec  8 03:24:39 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 02:24:39 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386469479.1.0.05231218952.issue19766@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 19924 suggests we may need a new distlib as well

----------
nosy: +christian.heimes, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec  8 03:37:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 02:37:56 +0000
Subject: [issue19758] Warnings in tests
In-Reply-To: <1385327657.07.0.59921543232.issue19758@psf.upfronthosting.co.za>
Message-ID: <3dcWsv0s3Dz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 94593dcb195a by Eric Snow in branch 'default':
Issue #19758: silence PendingDeprecationWarnings in test_importlib.
http://hg.python.org/cpython/rev/94593dcb195a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19758>
_______________________________________

From report at bugs.python.org  Sun Dec  8 04:15:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 03:15:11 +0000
Subject: [issue19506] subprocess.communicate() should use a memoryview
In-Reply-To: <1383683686.87.0.96753537873.issue19506@psf.upfronthosting.co.za>
Message-ID: <3dcXht0CfSz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 44948f5bdc12 by Gregory P. Smith in branch '3.3':
Fixes issue #19506: Use a memoryview to avoid a data copy when piping data
http://hg.python.org/cpython/rev/44948f5bdc12

New changeset 5379bba2fb21 by Gregory P. Smith in branch 'default':
Fixes issue #19506: Use a memoryview to avoid a data copy when piping data
http://hg.python.org/cpython/rev/5379bba2fb21

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19506>
_______________________________________

From report at bugs.python.org  Sun Dec  8 04:17:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 03:17:52 +0000
Subject: [issue19506] subprocess.communicate() should use a memoryview
In-Reply-To: <1383683686.87.0.96753537873.issue19506@psf.upfronthosting.co.za>
Message-ID: <1386472672.05.0.896304087238.issue19506@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

fwiw, this patch made sense.  using test_sub.py on my dual-core amd64 box with an opt build is saw the times drop from ~0.90-0.97 to ~0.75-0.8.  more speedup than i was really anticipating for this use case.  it probably depends upon what the value of _PIPE_BUF is on your system.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19506>
_______________________________________

From report at bugs.python.org  Sun Dec  8 04:18:21 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 03:18:21 +0000
Subject: [issue19506] subprocess.communicate() should use a memoryview
In-Reply-To: <1383683686.87.0.96753537873.issue19506@psf.upfronthosting.co.za>
Message-ID: <1386472701.78.0.0333419233952.issue19506@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19506>
_______________________________________

From report at bugs.python.org  Sun Dec  8 04:27:44 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 03:27:44 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386473264.24.0.144679680995.issue19851@psf.upfronthosting.co.za>


Eric Snow added the comment:

This is actually a problem with importlib.reload() (which imp.reload() simply wraps).  The attached patch provides a test that reproduces the error.  I'll work on a fix ASAP.

Interestingly, the kind of failure depends on frozen vs. source importlib:

======================================================================
ERROR: test_reload_submodule (test.test_importlib.test_api.Frozen_ReloadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_importlib/test_api.py", line 430, in test_reload_submodule
    self.init.reload(ham)
  File "Lib/importlib/__init__.py", line 161, in reload
    methods.exec(module)
  File "<frozen importlib._bootstrap>", line 1134, in exec
AttributeError: 'NoneType' object has no attribute 'name'

======================================================================
ERROR: test_reload_submodule (test.test_importlib.test_api.Source_ReloadTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_importlib/test_api.py", line 430, in test_reload_submodule
    self.init.reload(ham)
  File "Lib/importlib/__init__.py", line 158, in reload
    raise ImportError(msg.format(parent_name), name=parent_name)
ImportError: parent 'spam' not in sys.modules

----------------------------------------------------------------------

----------
keywords: +patch
priority: normal -> critical
stage: test needed -> needs patch
title: imp.reload problem with submodule -> reload problem with submodule
Added file: http://bugs.python.org/file33033/issue19851-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Sun Dec  8 04:51:26 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 03:51:26 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386474686.29.0.849282746952.issue19851@psf.upfronthosting.co.za>


Eric Snow added the comment:

Actually, they're both getting the same error:

AttributeError: 'NoneType' object has no attribute 'name'

I forgot to clear the submodule from sys.modules first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Sun Dec  8 04:57:02 2013
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 08 Dec 2013 03:57:02 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386475022.69.0.306619043818.issue19766@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Requests was released and pip updated it, I can release a new pip but it appears that perhaps distlib needs fixed before the without threads case is taken care of?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec  8 05:20:32 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 04:20:32 +0000
Subject: [issue19925] Add unit test for spwd module
Message-ID: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

So we may have buildbot with root account after all. https://mail.python.org/pipermail/python-dev/2013-December/130708.html

So here is the unit test for spwd module that requires root account.

----------
components: Tests
files: unittest_for_spwd.patch
keywords: patch
messages: 205513
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Add unit test for spwd module
versions: Python 3.4
Added file: http://bugs.python.org/file33034/unittest_for_spwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19925>
_______________________________________

From report at bugs.python.org  Sun Dec  8 05:21:25 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 04:21:25 +0000
Subject: [issue19925] Add unit test for spwd module
In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za>
Message-ID: <1386476485.45.0.741463557596.issue19925@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33034/unittest_for_spwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19925>
_______________________________________

From report at bugs.python.org  Sun Dec  8 05:21:43 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 04:21:43 +0000
Subject: [issue19925] Add unit test for spwd module
In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za>
Message-ID: <1386476503.43.0.657467341458.issue19925@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33035/unittest_for_spwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19925>
_______________________________________

From report at bugs.python.org  Sun Dec  8 05:47:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 04:47:50 +0000
Subject: [issue19926] Refactor unit test in abstract numbers test
Message-ID: <1386478070.8.0.430049074258.issue19926@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There are superfluous lines and unused import in Lib/test/test_abstract_numbers.py.

Attached the patch to remove superfluous lines and unused import.

----------
components: Tests
files: refactor_test_abstract_number.patch
keywords: patch
messages: 205514
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Refactor unit test in abstract numbers test
versions: Python 3.4
Added file: http://bugs.python.org/file33036/refactor_test_abstract_number.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19926>
_______________________________________

From report at bugs.python.org  Sun Dec  8 06:08:13 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 05:08:13 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.ModuleSpec.__eq__() is highly sensitive to
 loader.__eq__()
Message-ID: <1386479293.44.0.514721108706.issue19927@psf.upfronthosting.co.za>


New submission from Eric Snow:

ModuleSpec.__eq__() does a comparision of its various attributes, one of them being the loader.  However, the __eq__() of the path-based loaders is just the stock one that compares object identity.  So most

----------
messages: 205515
nosy: brett.cannon, eric.snow, ncoghlan
priority: high
severity: normal
stage: test needed
status: open
title: Path-based loaders lack a meaningful __eq__() implementation.ModuleSpec.__eq__() is highly sensitive to loader.__eq__()
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 06:13:37 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 05:13:37 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479293.44.0.514721108706.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

(my browser farted the half finished report into existence :P )

The __eq__() implementation of the path-based loaders in importlib is just the stock one that compares object identity.  So two that are effectively the same compare unequal.  This has a material impact on ModuleSpec.  ModuleSpec.__eq__() does a comparision of its various attributes, one of them being the loader.  Thus most specs will compare unequal even though they are effectively equal.

I recommend that we provide a better implementation for SourceFileLoader and friends.

Larry: would such a feature addition be okay?

----------
nosy: +larry
title: Path-based loaders lack a meaningful __eq__() implementation.ModuleSpec.__eq__() is highly sensitive to loader.__eq__() -> Path-based loaders lack a meaningful __eq__() implementation.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 06:14:05 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 05:14:05 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386479645.14.0.821166124436.issue19927@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
Removed message: http://bugs.python.org/msg205515

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 06:46:12 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 05:46:12 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386481572.34.0.223814087814.issue19851@psf.upfronthosting.co.za>


Eric Snow added the comment:

The problem was that importlib.reload() was not passing the parent's __path__ to importlib._bootstrap._find_spec().  This was a consequence of us restoring the pre-3.3 reload semantics.

Patch attached.  (Note to self: add Misc/NEWS entry)

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file33037/issue19851-fix-reload.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Sun Dec  8 06:46:40 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 05:46:40 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386481600.28.0.335781077302.issue19851@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file33033/issue19851-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Sun Dec  8 07:16:12 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 06:16:12 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386483372.91.0.597426176229.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a patch.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file33038/issue19927-loader-eq.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 07:21:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 06:21:41 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386483701.75.0.0455083180772.issue19851@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Patch looks reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Sun Dec  8 07:22:40 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 08 Dec 2013 06:22:40 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386483760.33.0.0802928694634.issue18864@psf.upfronthosting.co.za>


Eric Snow added the comment:

Good catch.  My preference would be for (c) simply add a setter for the property that sets the underlying private variable to True or False.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Sun Dec  8 07:31:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 06:31:36 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386484296.54.0.215426996841.issue19927@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

There can be some interesting backwards compatibility consequences when adding an __eq__ implementation to a class that was previously using the default ID based __eq__:

- it becomes unhashable (unless you also add a suitable __hash__ definition)

- subclasses with additional significant state may start comparing equal, even though their additional state is not taken into account by the new __eq__ function.

For the latter problem, you can alleviate it by comparing the instance dictionaries rather than specific attributes:

>>> class Example:
...     def __eq__(self, other):
...         return self.__class__ == other.__class__ and self.__dict__ == other.__dict__
... 
>>> a = Example()
>>> b = Example()
>>> a == b
True
>>> a.foo = 1
>>> a == b
False
>>> b.foo = 1
>>> a == b
True

(technically this can still change subclass behaviour if they're messing about with slots, but there *is* such a thing as being *too* paranoid about backwards compatibility)

The hashability problem is easy enough to handle just by mixing together the hashes of the attributes of most interest:

    def __hash__(self):
        return hash(self.name) ^ hash(self.path)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 07:45:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 06:45:25 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <3dcdMS4KSMz7Ljq@mail.python.org>


Roundup Robot added the comment:

New changeset 3283fb24106d by Zachary Ware in branch '3.3':
Issue 19572: More silently skipped tests explicitly skipped.
http://hg.python.org/cpython/rev/3283fb24106d

New changeset 03afd2d7d395 by Zachary Ware in branch 'default':
Issue 19572: More silently skipped tests explicitly skipped.
http://hg.python.org/cpython/rev/03afd2d7d395

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Sun Dec  8 07:46:37 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Dec 2013 06:46:37 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386485197.68.0.681470068448.issue19572@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Committed on 3.3 and default; I'd still like some extra eyes on the 2.7 patch before I commit it.

----------
assignee:  -> zach.ware
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Sun Dec  8 08:02:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 07:02:37 +0000
Subject: [issue19926] Refactor unit test in abstract numbers test
In-Reply-To: <1386478070.8.0.430049074258.issue19926@psf.upfronthosting.co.za>
Message-ID: <3dcdlJ4zH4z7LmT@mail.python.org>


Roundup Robot added the comment:

New changeset 22c865babf0a by Zachary Ware in branch '3.3':
Issue #19926: Removed unneeded test_main from test_abstract_numbers.
http://hg.python.org/cpython/rev/22c865babf0a

New changeset 7ff101a449b4 by Zachary Ware in branch 'default':
Issue #19926: Removed unneeded test_main from test_abstract_numbers.
http://hg.python.org/cpython/rev/7ff101a449b4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19926>
_______________________________________

From report at bugs.python.org  Sun Dec  8 08:03:36 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 08 Dec 2013 07:03:36 +0000
Subject: [issue19926] Refactor unit test in abstract numbers test
In-Reply-To: <1386478070.8.0.430049074258.issue19926@psf.upfronthosting.co.za>
Message-ID: <1386486216.44.0.067465027462.issue19926@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed, thanks for the patch!

----------
assignee:  -> zach.ware
nosy: +zach.ware
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19926>
_______________________________________

From report at bugs.python.org  Sun Dec  8 08:25:56 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Dec 2013 07:25:56 +0000
Subject: [issue19920] TarFile.list() fails on some files
In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za>
Message-ID: <1386487556.0.0.933627600895.issue19920@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19920>
_______________________________________

From report at bugs.python.org  Sun Dec  8 08:26:24 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 08 Dec 2013 07:26:24 +0000
Subject: [issue19925] Add unit test for spwd module
In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za>
Message-ID: <1386487584.78.0.877434067993.issue19925@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hi. I left a comment on Rietveld.

----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19925>
_______________________________________

From report at bugs.python.org  Sun Dec  8 09:39:48 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 08:39:48 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386491988.07.0.718429989744.issue19921@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Fails on Windows Vista.

...................................................s..s..s..s.......F.
......
======================================================================
FAIL: test_mkdir_parents (__main__.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1502, in test_mkdir_parents
    self.assertEqual(stat.S_IMODE(p.stat().st_mode), 0o555 & mode)
AssertionError: 511 != 365

======================================================================
FAIL: test_mkdir_parents (__main__.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_pathlib.py", line 1502, in test_mkdir_parents
    self.assertEqual(stat.S_IMODE(p.stat().st_mode), 0o555 & mode)
AssertionError: 511 != 365

----------------------------------------------------------------------
Ran 326 tests in 3.293s

FAILED (failures=2, skipped=90)

This line is problematic.
self.assertEqual(stat.S_IMODE(p.stat().st_mode), 0o555 & mode)

>From http://docs.python.org/2/library/os.html#os.chmod:

Note
Although Windows supports chmod(), you can only set the file?s read-only flag with it (via the stat.S_IWRITE and stat.S_IREAD constants or a corresponding integer value). All other bits are ignored.

In Django, we skip chmod test on Windows.
https://github.com/django/django/blob/master/tests/staticfiles_tests/tests.py#L830

But this line is okay:
self.assertEqual(stat.S_IMODE(p.parent.stat().st_mode), mode)

So we should just skip that particular problematic line on Windows.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sun Dec  8 09:48:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 08:48:40 +0000
Subject: [issue19928] Implement cell repr test
Message-ID: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Repr test for cell is empty. Proposed patch implements it.

----------
components: Tests
files: test_cell_repr.patch
keywords: patch
messages: 205528
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Implement cell repr test
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33039/test_cell_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19928>
_______________________________________

From report at bugs.python.org  Sun Dec  8 09:53:32 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 08:53:32 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386492812.9.0.267959687164.issue19876@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

The test is failing on Windows buildbot:
http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1851/steps/test/logs/stdio
"""
======================================================================
ERROR: test_unregister_after_fd_close_and_reuse (test.test_selectors.DefaultSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_selectors.py", line 122, in test_unregister_after_fd_close_and_reuse
    os.dup2(rd2.fileno(), r)
OSError: [Errno 9] Bad file descriptor

======================================================================
ERROR: test_unregister_after_fd_close_and_reuse (test.test_selectors.SelectSelectorTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_selectors.py", line 122, in test_unregister_after_fd_close_and_reuse
    os.dup2(rd2.fileno(), r)
OSError: [Errno 9] Bad file descriptor
"""

Apparently, dup2() doesn't work on Windows because on Windows, sockets aren't file descriptors, but a different beast...

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 09:55:30 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 08:55:30 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1386492930.73.0.287088649801.issue19837@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

upstream simplejson (of which json is an earlier snapshot of) has an encoding parameter on its dump and dumps method.  Lets NOT break compatibility with that API.

Our users use these modules interchangeably today, upgrading from stdlib json to simplejson when they need more features or speed without having to change their code.

simplejson's dumps(encoding=) parameter tells the module what encoding to decode bytes objects found within the data structure as (whereas Python 3.3's builtin json module being older doesn't even support that use case and raises a TypeError when bytes are encountered within the structure being serialized).

http://simplejson.readthedocs.org/en/latest/

A json.dump_bytes() function implemented as:

def dump_bytes(*args, **kwargs):
  return dumps(*args, **kwargs).encode('utf-8')

makes some sense.. but it is really trivial for anyone to write that .encode(...) themselves.

a dump_bytes_to_file method that acts like dump() and calls .encode('utf-8') on all str's before passing them to the write call is also doable... but it seems easier to just let people use an existing io wrapper to do that for them as they already are.

As for load/loads, it is easy to allow that to accept bytes as input and assume it comes utf-8 encoded.  simplejson already does this.  json does not.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19837>
_______________________________________

From report at bugs.python.org  Sun Dec  8 10:00:11 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 09:00:11 +0000
Subject: [issue19837] Wire protocol encoding for the JSON module
In-Reply-To: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>
Message-ID: <1386493211.89.0.785366583968.issue19837@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

So why not put a dump_bytes into upstream simplejson first, then pull in a modern simplejson?

There might be some default flag values pertaining to new features that need changing for stdlib backwards compatible behavior but otherwise I expect it's a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19837>
_______________________________________

From report at bugs.python.org  Sun Dec  8 10:05:42 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 09:05:42 +0000
Subject: [issue19925] Add unit test for spwd module
In-Reply-To: <1386476432.59.0.431887490027.issue19925@psf.upfronthosting.co.za>
Message-ID: <1386493542.8.0.972264900002.issue19925@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Hi Claudiu, thanks for the review and the knowledge that on Windows, we don't have attribute getuid of os. Here is the updated patch. I do not check specifically for Windows but only whether the platform can import spwd module or not. That should be enough.

----------
Added file: http://bugs.python.org/file33040/unittest_for_spwd_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19925>
_______________________________________

From report at bugs.python.org  Sun Dec  8 10:21:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 09:21:55 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386494515.45.0.595845872601.issue19572@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have added few comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Sun Dec  8 10:38:10 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 09:38:10 +0000
Subject: [issue19929] subprocess: increase read buffer size
Message-ID: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

This is a spinoff of issue #19506: currently, subprocess.communicate() uses a 4K buffer when reading data from pipes.
This was probably optimal a couple years ago, but nowadays most operating systems have larger pipes (e.g. Linux has 64K), so we might be able to gain some performance by increasing this buffer size.

For example, here's a benchmark reading from a subprocess spawning "dd if=/dev/zero bs=1M count=100":

# before, 4K buffer
$ ./python ~/test_sub_read.py 
2.72450800300021

# after, 64K buffer
$ ./python ~/test_sub_read.py 
1.2509000449999803

The difference is impressive.

I'm attaching the benchmark script so that others can experiment a bit (on multi-core machines and also different OSes).

----------
components: Library (Lib)
files: test_sub_read.py
messages: 205534
nosy: gregory.p.smith, haypo, neologix, pitrou, sbt, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: subprocess: increase read buffer size
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file33041/test_sub_read.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 11:16:06 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 08 Dec 2013 10:16:06 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386497766.67.0.933900949509.issue19766@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I will look at doing a distlib update shortly - but there's another issue (#19913) that might also require an update - it' not clear yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec  8 11:18:29 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 08 Dec 2013 10:18:29 +0000
Subject: [issue19690] test_logging test_race failed with PermissionError
In-Reply-To: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za>
Message-ID: <1386497909.1.0.286658921135.issue19690@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'll close this for now as the failures seem to have stopped. Though I only added some diagnostics, that might have changed the relative timings enough so the race doesn't surface (for now).

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19690>
_______________________________________

From report at bugs.python.org  Sun Dec  8 11:24:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 10:24:43 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386498283.63.0.25141306595.issue19921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Vajrasky. Now this check is skipped on Windows.

----------
Added file: http://bugs.python.org/file33042/pathlib_mkdir_mode_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Sun Dec  8 11:49:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 10:49:59 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1386468963.76.0.589393750893.issue19846@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwavJyTMDxmVM_VNk-XE1y3DoLRaeci166gA8WboxNOP6A@mail.gmail.com>


STINNER Victor added the comment:

Antoine Pitrou added the comment:
> > Python uses the fact that the filesystem encoding is the locale
> > encoding in various places.
> The patch doesn't change that.

Nick Coghlan added the comment:
> Note that the *only* change Antoine's patch makes is that:
> - *if* the locale encoding is ASCII (or an alias for ASCII)
> - *then* Python sets the filesystem encoding to UTF-8 instead

If the locale encoding is ASCII, filesystem encoding (UTF-8) is
different than the locale encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:01:45 2013
From: report at bugs.python.org (alexd2)
Date: Sun, 08 Dec 2013 11:01: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: <1386500505.44.0.273518590993.issue17259@psf.upfronthosting.co.za>


alexd2 added the comment:

I encountered the same inconsistent behavior. That is, I don't get the same rounding from the two following commands:

print "%.f %.f" %(0.5, 1.5)               # Gives --> 0 2
print "%.f %.f" %(round(0.5), round(1.5)) # Gives --> 1 2

I also get:
print round(0.5), round(1.5) # Gives --> 1.0 2.0

>From what I read in the thread it seems to be more like a bug rather than something to just be documented, right?

----------
nosy: +alexd2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:02:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:02:32 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>
Message-ID: <1386500552.68.0.518343539266.issue19929@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Where is the buffer size? The hardcoded 4096 value in Popen._communicate()?
   data = os.read(key.fd, 4096)

I remember that I asked you where does 4096 come from when you patched subprocess to use selectors (#18923):
http://bugs.python.org/review/18923/#ps9827

Python 3.3 uses 1024 for its select.select() implementation, 4096 for its select.poll() implementation.

Since Popen.communicate() returns the whole content of the buffer, would it be safe to increase the buffer size? For example, use 4 GB as the buffer size? Should communicate() be "fair" between stdout and stderr?

To choose a new value, we need benchmark results on different OSes, at least Windows, Linux, FreeBSD (and maybe also Solaris) since these 3 OSes have a different kernel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:03:56 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:03:56 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>
Message-ID: <1386500636.65.0.382598172751.issue19929@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, Charles-Fran?ois Natali replied to my review by email, and it's not archived on Rietveld. Copy of him message:

> http://bugs.python.org/review/18923/diff/9757/Lib/subprocess.py#newcode420
> Lib/subprocess.py:420: _PopenSelector = selectors.SelectSelector
> This code should be factorized, but I opened a new issue for that:
> #19465.
> http://bugs.python.org/issue19465

OK, so we'll see in the other issue :-)

> http://bugs.python.org/review/18923/diff/9757/Lib/subprocess.py#newcode1583
> Lib/subprocess.py:1583: self._input_offset + _PIPE_BUF]
> (Unrelated to the selector issue) It may be more efficient to use a
> memory view instead of a slice here.

I also noticed, but that's also a different issue.

> http://bugs.python.org/review/18923/diff/9757/Lib/subprocess.py#newcode1597
> Lib/subprocess.py:1597: data = os.read(key.fd, 4096)
> In the old code, poll() uses 4096 whereas select() uses 1024 bytes... Do
> you know the reason? Why 4096 and not 1 byte or 1 MB? I would prefer a
> global constant rather than an harded limit.

When writing to the pipe, we should definitely write less than
PIPE_BUF, to avoid blocking after select()/poll() returns write-ready.
When reading, it's not so important, in the sense that any value will work.
The only difference will be a difference speed.

Logically, I would say that the ideal size is the pipe buffer size,
which varies between 4K and 64K: and indeed, I wrote a quick
benchmark, and a 64K value yields the best result.

> Use maybe os.stat(fd).st_blksize?

IMO that's not worth it, also, IIRC, some OS don't set it for pipes.

> Modules/_io/fileio.c uses SMALLCHUNK to read the whole content of a
> file:
>
> #if BUFSIZ < (8*1024)
> #define SMALLCHUNK (8*1024)
> #elif (BUFSIZ >= (2 << 25))
> #error "unreasonable BUFSIZ > 64MB defined"
> #else
> #define SMALLCHUNK BUFSIZ
> #endif
>
> The io module uses a default buffer size of 8 KB to read.

Well, that's just a heuristic: the ideal size depends on the OS, the
filesystem, backing device, etc (for an on-disk file)?

Anyway, this too belongs to another issue.

Please try to only make comments relevant to the issue at hand!

> http://bugs.python.org/review/18923/diff/9757/Lib/test/test_subprocess.py
> File Lib/test/test_subprocess.py (left):
>
> http://bugs.python.org/review/18923/diff/9757/Lib/test/test_subprocess.py#oldcode2191
> Lib/test/test_subprocess.py:2191: class
> ProcessTestCaseNoPoll(ProcessTestCase):
> Oh oh, removing a test is not a good idea. You should test select and
> poll selectors when poll is used by default.

Well, those distinct test cases made sense before, because there were
two different code paths depending on whether we were using select()
or poll(). Now, the code path is exactly the same, and the different
selectors implementations have their own tests, so IMO that's not
necessary anymore.

But I re-enabled them anyway...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:06:05 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 08 Dec 2013 11:06:05 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386500765.43.0.0698441335493.issue19766@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I've updated distlib to use dummy_threading where threading isn't available - see

https://bitbucket.org/pypa/distlib/commits/029fee573900765729402203e39b2171d7ae0784

Can someone please test with this version vendored into pip to check that the failures no longer occur in a no-thread environment, before I do a distlib release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:09:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 11:09:05 +0000
Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails
Message-ID: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

os.makedirs() can't create a directory with cleared write or list permission bits for owner when parent directories aren't created. This is because for parent directories same mode is used as for final directory.

Note that the mkdir utility creates parent directories with default mode (0o777 & ~umask).

$ mkdir -p -m 0 t1/t2/t3
$ ls -l -d t1 t1/t2 t1/t2/t3
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/
drwxrwxr-x 3 serhiy serhiy 4096 Dec  7 22:30 t1/t2/
d--------- 2 serhiy serhiy 4096 Dec  7 22:30 t1/t2/t3/

The proposed patch emulates the mkdir utility.

See also issue19921.

----------
components: Library (Lib)
messages: 205543
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: os.makedirs('dir1/dir2', 0) always fails
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19930>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:09:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 11:09:53 +0000
Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails
In-Reply-To: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za>
Message-ID: <1386500993.35.0.282084262521.issue19930@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file33043/os_makedirs_mode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19930>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:10:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:10:28 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386149645.66.0.0361978088367.issue19883@psf.upfronthosting.co.za>
Message-ID: <1386501028.03.0.46604243691.issue19883@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a work-in-progress patch.

PyMarshal_ReadShortFromFile() and PyMarshal_ReadLongFromFile() are still wrong: new Unsigned version should be added to marshal.c. I don't know if a C cast to unsigned is enough because long can be larger than 32-bit (ex: on Linux 64-bit):
#if SIZEOF_LONG > 4
        /* Sign extension for 64-bit machines */
        x |= -(x & 0x80000000L);
#endif

I didn't test my patch. Anyone interested to finish the patch?

----------
Added file: http://bugs.python.org/file33044/zipimport_int_overflow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19883>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:16:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 11:16:02 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386501362.54.0.660344740078.issue19846@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yes, that's the point. *Every* case I've seen where the locale encoding has been reported as ASCII on a modern Linux system has been because the environment has been configured to use the C locale, and that locale has a silly, antiquated, encoding setting.

This is particularly problematic when people remotely access a system with ssh and get given the C locale instead of something sensible, and then can't properly read the filesystem on that server.

The idea of using UTF-8 instead in that case is to *change* (and hopefully reduce) the number of cases where things go wrong.

- if no non-ASCII data is encountered, the choice of ASCII vs UTF-8 doesn't matter
- if it's a modern Linux distro, then the real filesystem encoding is UTF-8, and the setting it provides for LANG=C is just plain *wrong*
- there may be other cases where ASCII actually *is* the filesystem encoding (in which case they're going to have trouble anyway), or the real filesystem encoding is something other than UTF-8

We're already approximating things on Linux by assuming every filesystem is using the *same* encoding, when that's not necessarily the case. Glib applications also assume UTF-8, regardless of the locale (http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux).

At the moment, setting "LANG=C" on a Linux system *fundamentally breaks Python 3*, and that's not OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:16:16 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 11:16:16 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386501376.86.0.312900898827.issue19846@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding() -> Setting LANG=C breaks Python 3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:22:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:22:14 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386501734.2.0.686356422804.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't like generic "except OSError: pass". Here is a first patch for epoll() to use "except FileNotFoundError: pass" instead. Kqueue selector should also be patched.

I tested to close epoll FD (os.close(epoll.fileno())): on Linux 3.11, epoll.unregister(fd) and epoll.close() don't raise an error. Strange. (The C code looks correct).

(About the commit: I don't like "_fileobj_lookup" method name, we loose the information (compared to "_fileobj_to_fd" name) that the method returns a file dscriptor. I would prefer "_get_fd" or "_get_fileobj_fd".)

----------
resolution: fixed -> 
Added file: http://bugs.python.org/file33045/epoll_except.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:37:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:37:24 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1386501362.54.0.660344740078.issue19846@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb4Ga1_inPP1-H__O=JG4bwCiHLu-d8VSz7QG31dYX-cA@mail.gmail.com>


STINNER Victor added the comment:

2013/12/8 Nick Coghlan <report at bugs.python.org>:
> Yes, that's the point. *Every* case I've seen where the locale encoding has been reported as ASCII on a modern Linux system has been because the environment has been configured to use the C locale, and that locale has a silly, antiquated, encoding setting.
>
> This is particularly problematic when people remotely access a system with ssh and get given the C locale instead of something sensible, and then can't properly read the filesystem on that server.

The solution is to fix the locale, not to fix Python. For example,
don't set LANG to C.

>From the C locale, you cannot guess the "correct" encoding. In
Unicode, the general rule is to never try the encoding.

> The idea of using UTF-8 instead in that case is to *change* (and hopefully reduce) the number of cases where things go wrong.

If the OS uses ISO-8859-1, forcing Python (filesystem) encoding to
UTF-8 would produce invalid filenames, display mojibake and more
generally produce data incompatible with other applicatons (who rely
on the C locale, and so the ASCII encoding).

> - there may be other cases where ASCII actually *is* the filesystem encoding (in which case they're going to have trouble anyway), or the real filesystem encoding is something other than UTF-8

As I wrote before, os.getfilesystemencoding() is *not* the filesystem
encoding. It's the "OS" encoding used to decode any kind of data
coming for the OS and used to encode back Python data to the OS. Just
some examples:

- DNS hostnames
- Environment variables
- Command line arguments
- Filenames
- user/group entries in the grp/pwd modules
- almost all functions of the os module, they return various type of
information (ttyname, ctermid, current working directory, login, ...)

> We're already approximating things on Linux by assuming every filesystem is using the *same* encoding, when that's not necessarily the case. Glib applications also assume UTF-8, regardless of the locale (http://unix.stackexchange.com/questions/2089/what-charset-encoding-is-used-for-filenames-and-paths-on-linux).

If you use a different encoding but only just for filenames, you will
get mojibake when you pass a filename on the command line or in an
environment varialble.

> At the moment, setting "LANG=C" on a Linux system *fundamentally breaks Python 3*, and that's not OK.

Getting ASCII filesystem encoding is annoying, but I would not say
that it fundamentally breaks Python 3. If you want to do something,
you should write documentation explaining how to configure properly
Linux.

----------
title: Setting LANG=C breaks Python 3 -> print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:41:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 11:41:37 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <CAMpsgwb4Ga1_inPP1-H__O=JG4bwCiHLu-d8VSz7QG31dYX-cA@mail.gmail.com>
Message-ID: <1386502895.2291.0.camel@fsol>


Antoine Pitrou added the comment:

> If you use a different encoding but only just for filenames, you will
> get mojibake when you pass a filename on the command line or in an
> environment varialble.

That's not what the patch does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:43:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 11:43:54 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386503034.63.0.123273193818.issue19700@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:45:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 11:45:22 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1386458541.9327.5.camel@fsol>
Message-ID: <CAMpsgwbdGZMQnZMPrrx7F68HgZe+fCft4MH8xzJTeJckpRh13Q@mail.gmail.com>


STINNER Victor added the comment:

2013/12/8 Antoine Pitrou <report at bugs.python.org>:
>> Python uses the fact that the filesystem encoding is the locale
>> encoding in various places.
>
> The patch doesn't change that.

You wrote: "-> With the patch: utf-8 utf-8 utf-8 ANSI_X3.4-1968", so
os.get sys.getfilesystemencoding() != locale.getpreferredencoding().
Or said differently, the filesystem encoding is different than the
locale encoding.

So please read again my following message which list real bugs:
https://mail.python.org/pipermail/python-dev/2010-October/104509.html

If you want to use a filesystem encoding different than the locale
encoding, you have to patch Python where Python assumes that the
filesystem encoding is the locale encoding, to fix all these bugs.
Starts with:

- PyUnicode_DecodeFSDefaultAndSize()
- PyUnicode_EncodeFSDefault()
- _Py_wchar2char()
- _Py_char2wchar()

It should be easier to change this function if the FS != locale only
occurs when FS is "UTF-8". On Mac OS X, Python always use UTF-8 for
the filesystem encoding, it doesn't care of the locale encoding. See
_Py_DecodeUTF8_surrogateescape() in unicodeobject.c, you may reuse it.

With a better patch, I can do more experiment to check if they are
other tricky bugs.

Does at least your patch pass the whole test suite with LANG=C?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 12:52:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 11:52:08 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386503528.06.0.276463961672.issue19846@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Setting sys.stderr encoding to UTF-8 on ASCII locale is wrong. sys.stderr has the backslashreplace error handler by default, so it newer fails and should newer produce non-ASCII data on ASCII locale.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 13:12:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 12:12:00 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386501734.2.0.686356422804.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2VFiYXp-tS0D5VinVU5=ai96fkePSwbqc7fU02e7Z2Ug@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> STINNER Victor added the comment:
>
> I don't like generic "except OSError: pass". Here is a first patch for epoll() to use "except FileNotFoundError: pass" instead. Kqueue selector should also be patched.

Except that it can fail with ENOENT, but also EBADF, and EPERM if the
FD has been reused by a FD which doesn't support epoll.
So if we want to go this way, we should at least catach ENOENT, EBADF
and EPERM. Same for kqueue: we should at least catch ENOENT and EBADF.

> I tested to close epoll FD (os.close(epoll.fileno())): on Linux 3.11, epoll.unregister(fd) and epoll.close() don't raise an error. Strange. (The C code looks correct).

unregister() ignores EBADF.

> (About the commit: I don't like "_fileobj_lookup" method name, we loose the information (compared to "_fileobj_to_fd" name) that the method returns a file dscriptor. I would prefer "_get_fd" or "_get_fileobj_fd".)

Well, Guido likes it, I like it, and this is really nit-picking
(especially since it's a private method).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 13:22:58 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 12:22:58 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <1386500552.68.0.518343539266.issue19929@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2v2er4UGoDdtoU8-aHeRZzg_OHxgpkAa_+o92fc2TfpA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> STINNER Victor added the comment:
>
> Since Popen.communicate() returns the whole content of the buffer, would it be safe to increase the buffer size? For example, use 4 GB as the buffer size?

Sure, if you want to pay the CPU and memory overhead of allocating a
4GB buffer :-)

> Should communicate() be "fair" between stdout and stderr?

There's no reason to make the buffer depend on the FD.

> To choose a new value, we need benchmark results on different OSes, at least Windows, Linux, FreeBSD (and maybe also Solaris) since these 3 OSes have a different kernel.

Windows isn't concerned by this, since it doesn't use a selector, but threads.
For the other OSes, that's why I opened this issue (you forgot AIX in
your list :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 13:24:38 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 08 Dec 2013 12:24:38 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386505478.47.0.241342049711.issue19927@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Brett, could you weigh in please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 13:35:02 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 08 Dec 2013 12:35:02 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386506102.38.0.370442140545.issue19846@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Antoine: are you characterizing this as a "bug" rather than a "new feature"?

I'd like to see more of a consensus before something like this gets checked in.  Right now I see a variety of opinions.

When I think "conservative approach" and "knows about system encoding stuff", I think of Martin.  Martin, can I ask you to form an opinion about this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 13:38:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 12:38:15 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386506295.29.0.271334200978.issue19846@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Or said differently, the filesystem encoding is different than the
> locale encoding.

Indeed, but the FS encoding and the IO encoding are the same.
"locale encoding" doesn't really matter here, as we are assuming that it's wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:09:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 13:09:48 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386508188.82.0.759024393752.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OK, I just noticed that importlib.find_spec copies the annoying-as-hell behaviour of importlib.find_loader where it doesn't work with dotted names. Can we fix that please? It's stupid that pkgutil.get_loader has to exist to workaround that design flaw for find_loader, and I'd hate to see it replicated in a new public facing API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:19:43 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2013 13:19:43 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386508783.22.0.876968630327.issue19766@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Vinay, thanks for your fast response! :) #19913 should be resolved, too. A couple of months ago several people complained about a new file that looked like a ZIP bomb. This virus warnings looks even more severe although it's probably a false positive. Could you try a new set of binaries without UPX? https://www.virustotal.com/ lets you scan the files with more than 40 programs at once and for free.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:24:06 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 08 Dec 2013 13:24:06 +0000
Subject: [issue19343] Expose FreeBSD-specific APIs in resource module
In-Reply-To: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>
Message-ID: <1386509046.4.0.89623463652.issue19343@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I can live with this in 3.4 if you check it in before beta 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19343>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:36:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 13:36:14 +0000
Subject: [issue19343] Expose FreeBSD-specific APIs in resource module
In-Reply-To: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>
Message-ID: <3dcpTT6HVNz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset ad2cd599f1cf by Christian Heimes in branch 'default':
Issue #19343: Expose FreeBSD-specific APIs in resource module.  Original patch by Koobs.
http://hg.python.org/cpython/rev/ad2cd599f1cf

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19343>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:36:20 2013
From: report at bugs.python.org (alexd2)
Date: Sun, 08 Dec 2013 13:36:20 +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: <1386509780.97.0.579389784691.issue17259@psf.upfronthosting.co.za>


alexd2 added the comment:

Note:
I have python2.7.3 in Ubuntu 12.04.3 installed in a VirtualBox VM on a Windows 7 32-bit and an Intel(R) Core(TM)2 Duo CPU U9300 @ 1.20GHz (2 CPUs), ~1.2GHz processor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:36:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2013 13:36:36 +0000
Subject: [issue19343] Expose FreeBSD-specific APIs in resource module
In-Reply-To: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>
Message-ID: <1386509796.87.0.106632776446.issue19343@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks Larry!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19343>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:43:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 Dec 2013 13:43:16 +0000
Subject: [issue19343] Expose FreeBSD-specific APIs in resource module
In-Reply-To: <1382434038.91.0.920002784924.issue19343@psf.upfronthosting.co.za>
Message-ID: <1386510196.98.0.672963496987.issue19343@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Claudiu, I'm really sorry. :( The patch was originally developed by you, not by koobs. All credits to you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19343>
_______________________________________

From report at bugs.python.org  Sun Dec  8 14:59:55 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 13:59:55 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386511195.29.0.159366007985.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Deleted a bunch of code, and runpy now correctly sets both __file__ and __cached__ (runpy previously never set the latter properly).

You can also see the reason for my rant above in the form of runpy._fixed_find_spec. importlib.find_loader was always kind of useless in end user code that needed to handle arbitrary modules, you needed to use the pkgutil.get_loader wrapper instead. It would be nice if importlib.find_spec "just worked", instead of only working for top level modules. At the very least, it should fail noisily if a dotted name is passed in without specifying a path argument.

I may have argued in favour of the side effect free find_loader in the past, if I have, consider this me admitting I was wrong after wasting a bunch of time hunting down unexpected import errors in test_runpy after the initial conversion to using find_spec.

There's one final change needed to address the pickle-in-main compatibility issue: runpy has to alias the module under its real name as well as __main__. Once it does that, then using __spec__.name (when available) should ensure pickle does the right thing.

----------
keywords: +patch
Added file: http://bugs.python.org/file33046/issue19700_runpy_spec.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec  8 15:09:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Dec 2013 14:09:48 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1386506295.29.0.271334200978.issue19846@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e6ezh+WhioX48CXWCtaEYCXomj865S_uY_tjJT9Q9hpA@mail.gmail.com>


Nick Coghlan added the comment:

Victor, people set "LANG=C" for all sorts of reasons, and we have no
control over how operating systems define that locale. The user
perception is "Python 3 doesn't work properly when you ssh into
systems", not "Gee, I wish operating systems defined the C locale more
sensibly".

If you can come up with a more sensible guess than UTF-8, great, but
believing the nonsense claim of "ASCII" from the OS is a
not-insignificant usability issue on Linux, because it hoses *all* the
OS API interactions. Yes, theoretically, using UTF-8 can cause
problems, *if* the following all occur:

- the OS *claims* the OS encoding is ASCII (so Python uses UTF-8 instead)
- the OS encoding is *actually* something other than UTF-8
- the program encounters non-ASCII data and writes it out to disk

For fear of doing the wrong thing in that incredibly rare scenario,
you're leaving Python broken under the C locale on *every* modern
Linux distro as soon as it encounters non-ASCII data in an OS
interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 15:21:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 14:21:16 +0000
Subject: [issue19922] mbstate_t requires _INCLUDE__STDC_A1_SOURCE
In-Reply-To: <1386449978.34.0.25024018047.issue19922@psf.upfronthosting.co.za>
Message-ID: <3dcqTS1nKpz7Lk1@mail.python.org>


Roundup Robot added the comment:

New changeset 4221d5d9ac84 by Christian Heimes in branch 'default':
Attempt to fix OpenIndiana build issue introduced by #19922
http://hg.python.org/cpython/rev/4221d5d9ac84

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19922>
_______________________________________

From report at bugs.python.org  Sun Dec  8 15:23:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 14:23:34 +0000
Subject: [issue19736] posixmodule.c: Add flags for statvfs.f_flag to constant
 list
In-Reply-To: <1385222125.46.0.688361383331.issue19736@psf.upfronthosting.co.za>
Message-ID: <3dcqX52nDgz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 1d0b7e90da4d by doko in branch 'default':
- Issue #19736: Add module-level statvfs constants defined for GNU/glibc
http://hg.python.org/cpython/rev/1d0b7e90da4d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19736>
_______________________________________

From report at bugs.python.org  Sun Dec  8 15:41:56 2013
From: report at bugs.python.org (Nikolay Bogoychev)
Date: Sun, 08 Dec 2013 14:41:56 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <1386513716.82.0.354048811361.issue16099@psf.upfronthosting.co.za>


Nikolay Bogoychev added the comment:

Hey,
it has been more than an year since the last activity. 
Is there anything else I should do in order for someone of the python devs team to review my changes and perhaps give some feedback?

Nick

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16099>
_______________________________________

From report at bugs.python.org  Sun Dec  8 15:46:07 2013
From: report at bugs.python.org (Bastien Montagne)
Date: Sun, 08 Dec 2013 14:46:07 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386513967.33.0.894480863502.issue11299@psf.upfronthosting.co.za>


Changes by Bastien Montagne <b.mont29 at gmail.com>:


----------
nosy: +mont29

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 15:49:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 14:49:31 +0000
Subject: [issue19878] bz2.BZ2File.__init__() cannot be called twice with
 non-existent file
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <3dcr630vY7z7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 55a748f6e396 by Nadeem Vawda in branch '2.7':
Closes #19878: Fix segfault in bz2 module.
http://hg.python.org/cpython/rev/55a748f6e396

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19878>
_______________________________________

From report at bugs.python.org  Sun Dec  8 16:02:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 15:02:34 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1386514954.93.0.867900102697.issue5845@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the status of this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Dec  8 16:42:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 08 Dec 2013 15:42:19 +0000
Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails
In-Reply-To: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za>
Message-ID: <1386517339.8.0.238094392139.issue19930@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Fails on Windows Vista.

======================================================================
FAIL: test_mode (__main__.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 907, in test_mode
    self.assertEqual(stat.S_IMODE(os.stat(parent).st_mode), 0o775)
AssertionError: 511 != 509

----------------------------------------------------------------------
Ran 157 tests in 1.865s

FAILED (failures=1, skipped=61)
Traceback (most recent call last):
  File "Lib\test\test_os.py", line 2511, in <module>
    test_main()
  File "C:\Users\vajrasky\Code\cpython\lib\test\support\__init__.py", line 1831,
 in decorator
    return func(*args)
  File "Lib\test\test_os.py", line 2507, in test_main
    FDInheritanceTests,
  File "C:\Users\vajrasky\Code\cpython\lib\test\support\__init__.py", line 1719,
 in run_unittest
    _run_suite(suite)
  File "C:\Users\vajrasky\Code\cpython\lib\test\support\__init__.py", line 1694,
 in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib\test\test_os.py", line 907, in test_mode
    self.assertEqual(stat.S_IMODE(os.stat(parent).st_mode), 0o775)
AssertionError: 511 != 509

The permission of directory on Windows no matter what mode you give or umask you give to support.temp_umask, is always 0o777 (or 511). I think this test does not make sense in Windows.

>>> os.mkdir('cutecat', 0o555)
>>> os.mkdir('cutecat2', 0o777)
>>> os.stat('cutecat')
os.stat_result(st_mode=16895, st_ino=3940649674207852, st_dev=3960548439, st_nli
nk=1, st_uid=0, st_gid=0, st_size=0, st_atime=1386517061, st_mtime=1386517061, s
t_ctime=1386517061)
>>> os.stat('cutecat2')
os.stat_result(st_mode=16895, st_ino=5066549581050708, st_dev=3960548439, st_nli
nk=1, st_uid=0, st_gid=0, st_size=0, st_atime=1386517067, st_mtime=1386517067, s
t_ctime=1386517067)

Either that, or I am missing something.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19930>
_______________________________________

From report at bugs.python.org  Sun Dec  8 16:45:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 15:45:38 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <3dcsLn3yW2z7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 42d3afd29460 by Serhiy Storchaka in branch '2.7':
Issue #19099: The struct module now supports Unicode format strings.
http://hg.python.org/cpython/rev/42d3afd29460

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Sun Dec  8 16:48:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 15:48:19 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <1386517699.08.0.672144516904.issue19099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed. Thank you Musashi for your report.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Sun Dec  8 16:57:49 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 15:57:49 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>
Message-ID: <1386518269.21.0.515944628758.issue19929@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Linux, 64-bit quad core:

With 4K buffer:

$ time ./python test_sub_read.py 
0.25217683400114765

real	0m0.296s
user	0m0.172s
sys	0m0.183s

With 64K buffer:

$ time ./python test_sub_read.py 
0.09257541999977548

real	0m0.132s
user	0m0.051s
sys	0m0.096s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:10:39 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 08 Dec 2013 16:10:39 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386519039.06.0.371738848842.issue19904@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? added the comment:

> If performance is the reason for the feature: My impression is that
> the goal of the struct module is not necessarily top performance.

I'm not sure if it applies but on #19905 (message 205345 [1])
is said its a dependency for that issue

----
[1] http://bugs.python.org/issue19905#msg205345

----------
nosy: +francismb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:10:57 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Dec 2013 16:10:57 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386519057.48.0.842007444708.issue18864@psf.upfronthosting.co.za>


Brett Cannon added the comment:

(c) it is then! I would just take the time to call bool() on the arg to coalesce it into a True/False thing (which maybe makes sense in __init__() as well).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:11:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Dec 2013 16:11:31 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386519091.39.0.987388834419.issue18864@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Actually, ignore the __init__() part of my last comment since it's set to False directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:15:14 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Dec 2013 16:15:14 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386519314.62.0.736952784814.issue19927@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm fine with the suggestions Nick made. While loaders are not technically immutable (and thus technically probably shouldn't define __hash__), they have not been defined to be mutable and mucked with anyway, so I have no issue if someone breaks the hash of a loader by changing an attribute post-hash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:16:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 16:16:36 +0000
Subject: [issue19535] Test failures with -OO
In-Reply-To: <1383988883.0.0.831312717343.issue19535@psf.upfronthosting.co.za>
Message-ID: <3dct2W4pDdz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 910b1cb5176c by Serhiy Storchaka in branch '3.3':
Issue #19535: Fixed test_docxmlrpc when python is run with -OO.
http://hg.python.org/cpython/rev/910b1cb5176c

New changeset e71142abf8b6 by Serhiy Storchaka in branch 'default':
Issue #19535: Fixed test_docxmlrpc, test_functools, test_inspect, and
http://hg.python.org/cpython/rev/e71142abf8b6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19535>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:17:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:17:47 +0000
Subject: [issue19535] Test failures with -OO
In-Reply-To: <1383988883.0.0.831312717343.issue19535@psf.upfronthosting.co.za>
Message-ID: <1386519467.1.0.469164026728.issue19535@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
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/issue19535>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:18:29 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Dec 2013 16:18:29 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386519509.55.0.793726897594.issue19700@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Can you file a separate bug, Nick, for the importlib.find_spec() change you are after? I don't want to lose track of it (and I get what you are after but we should discuss why importlib.find_loader() was designed the way it was initially).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:22:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:22:54 +0000
Subject: [issue19830] test_poplib emits resource warning
In-Reply-To: <1385722372.69.0.175458653403.issue19830@psf.upfronthosting.co.za>
Message-ID: <1386519774.98.0.325681977645.issue19830@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19830>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:26:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:26:36 +0000
Subject: [issue19758] Warnings in tests
In-Reply-To: <1385327657.07.0.59921543232.issue19758@psf.upfronthosting.co.za>
Message-ID: <1386519996.92.0.357972068474.issue19758@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Christian and Eric.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19758>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:38:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:38:03 +0000
Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails
In-Reply-To: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za>
Message-ID: <1386520683.66.0.388213845473.issue19930@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Vajrasky. Now this check is skipped on Windows.

----------
Added file: http://bugs.python.org/file33047/os_makedirs_mode_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19930>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:41:49 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 08 Dec 2013 16:41:49 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386520909.82.0.510988080257.issue16669@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

I'll add my voice to those asking for a way to put docstrings on namedtuples.  As it is, namedtuples get automatic docstrings that seem to me to be almost worse than none.  Sphinx produces this:

```
class Key

    Key(scope, user_id, block_scope_id, field_name)

    __getnewargs__()

        Return self as a plain tuple. Used by copy and pickle.

    __repr__()

        Return a nicely formatted representation string

    block_scope_id None

        Alias for field number 2

    field_name None

        Alias for field number 3

    scope None

        Alias for field number 0

    user_id None

        Alias for field number 1
```

Why are `__getnewargs__` and `__repr__` included at all, they aren't useful for API documentation.  The individual property docstrings offer no new information over the summary at the top.   I'd like namedtuple not to be so verbose where it has no useful information to offer.  The one-line summary is all the information namedtuple has, so that is all it should include in the docstring:

```
class Key

    Key(scope, user_id, block_scope_id, field_name)
```

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16669>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:44:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:44:41 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386521081.89.0.803137996225.issue16669@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16669>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:46:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:46:16 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386521176.27.0.306822739518.issue16669@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unhide this discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16669>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:46:54 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 08 Dec 2013 16:46:54 +0000
Subject: [issue19931] namedtuple docstrings are verbose for no added benefit
Message-ID: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

When I make a namedtuple, I get automatic docstrings that use a lot of words to say very little.  Sphinx autodoc produces this:

```
class Key

    Key(scope, user_id, block_scope_id, field_name)

    __getnewargs__()

        Return self as a plain tuple. Used by copy and pickle.

    __repr__()

        Return a nicely formatted representation string

    block_scope_id None

        Alias for field number 2

    field_name None

        Alias for field number 3

    scope None

        Alias for field number 0

    user_id None

        Alias for field number 1
```
The individual property docstrings offer no new information over the summary at the top.   I'd like namedtuple to be not so verbose where it has no useful information to offer.  The one-line summary is all the information namedtuple has, so that is all it should include in the docstring:

```
class Key

    Key(scope, user_id, block_scope_id, field_name)
```

----------
components: Library (Lib)
messages: 205584
nosy: nedbat
priority: normal
severity: normal
status: open
title: namedtuple docstrings are verbose for no added benefit
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19931>
_______________________________________

From report at bugs.python.org  Sun Dec  8 17:52:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 16:52:01 +0000
Subject: [issue19931] namedtuple docstrings are verbose for no added benefit
In-Reply-To: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>
Message-ID: <1386521521.57.0.465244729885.issue19931@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19931>
_______________________________________

From report at bugs.python.org  Sun Dec  8 18:01:14 2013
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Sun, 08 Dec 2013 17:01:14 +0000
Subject: [issue19856] Possible bug in shutil.move() on Windows
In-Reply-To: <1385924474.74.0.566817188038.issue19856@psf.upfronthosting.co.za>
Message-ID: <1386522074.73.0.0668545594688.issue19856@psf.upfronthosting.co.za>


Francisco Mart?n Brugu? added the comment:

Just feedback on windows7. I tried the tests inside IDLE and done 'Run Module' (F5) (deleting the directories between tests):

test_A:

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo/', 'bar/')

test_B:

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo', 'bar/')

and finally test_C:

import os, shutil
os.makedirs('foo')
os.makedirs('bar/boo')
shutil.move('foo\\', 'bar/')


... and got the same traceback:

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> ================================ RESTART ================================
>>> 

Traceback (most recent call last):
  File "D:\temp\test.py", line 4, in <module>
    shutil.move('foo/','bar/')
  File "D:\programs\Python27\lib\shutil.py", line 291, in move
    raise Error, "Destination path '%s' already exists" % real_dst
Error: Destination path 'bar/' already exists
>>>

----------
nosy: +francismb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19856>
_______________________________________

From report at bugs.python.org  Sun Dec  8 18:17:19 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 17:17:19 +0000
Subject: [issue19923] OSError: [Errno 512] Unknown error 512 in
 test_multiprocessing
In-Reply-To: <1386451400.97.0.885839707191.issue19923@psf.upfronthosting.co.za>
Message-ID: <1386523039.52.0.889310717843.issue19923@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Looks like a kernel bug.
errno 512 is ERESTARTSYS, which shouldn't leak to user-mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19923>
_______________________________________

From report at bugs.python.org  Sun Dec  8 18:35:29 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 Dec 2013 17:35:29 +0000
Subject: [issue16549] regression: -m json.tool module is broken
In-Reply-To: <1353799140.48.0.264325786565.issue16549@psf.upfronthosting.co.za>
Message-ID: <1386524129.35.0.752147088714.issue16549@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Somehow these errors do not occur today. Maybe they were side effects of other failures in test_json. Closing for now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16549>
_______________________________________

From report at bugs.python.org  Sun Dec  8 18:44:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 17:44:41 +0000
Subject: [issue19856] shutil.move() can't move a directory in non-empty
 directory on Windows
In-Reply-To: <1385924474.74.0.566817188038.issue19856@psf.upfronthosting.co.za>
Message-ID: <1386524681.78.0.661367513422.issue19856@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Francisco for testing. Here is different bug than I expected.

Looks as shutil.move() can't move a directory in non-empty directory on Windows.

----------
nosy: +hynek, tarek
title: Possible bug in shutil.move() on Windows -> shutil.move() can't move a directory in non-empty directory on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19856>
_______________________________________

From report at bugs.python.org  Sun Dec  8 19:06:47 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 08 Dec 2013 18:06:47 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1386526007.45.0.557443679636.issue19913@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This commit in distlib uses uncompressed launcher executables which pass the virustotal.com checks:

https://bitbucket.org/pypa/distlib/commits/e23c9e4fd3125fa88063de4dec80367b1ac82aff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Sun Dec  8 19:07:12 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 08 Dec 2013 18:07:12 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386526032.66.0.441655639187.issue19766@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This commit in distlib uses uncompressed launcher executables which pass the virustotal.com checks:

https://bitbucket.org/pypa/distlib/commits/e23c9e4fd3125fa88063de4dec80367b1ac82aff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec  8 19:50:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 18:50:27 +0000
Subject: [issue18430] gzip, bz2,
 lzma: peek advances file position of existing file object
In-Reply-To: <1373571241.88.0.314815867736.issue18430@psf.upfronthosting.co.za>
Message-ID: <3dcxS21ctWz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 5ca6e8af0aab by Nadeem Vawda in branch '3.3':
#18430: Document that peek() may change the position of the underlying file for
http://hg.python.org/cpython/rev/5ca6e8af0aab

New changeset 0f587fe304be by Nadeem Vawda in branch 'default':
Closes #18430: Document that peek() may change the position of the underlying
http://hg.python.org/cpython/rev/0f587fe304be

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18430>
_______________________________________

From report at bugs.python.org  Sun Dec  8 19:58:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 18:58:40 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>
Message-ID: <3dcxdV46tpz7Llb@mail.python.org>


Roundup Robot added the comment:

New changeset 03a056c3b88e by Gregory P. Smith in branch '3.3':
Fixes issue #19929: Call os.read with 32768 within subprocess.Popen
http://hg.python.org/cpython/rev/03a056c3b88e

New changeset 4de4b5a4e405 by Gregory P. Smith in branch 'default':
Fixes issue #19929: Call os.read with 32768 within subprocess.Popen
http://hg.python.org/cpython/rev/4de4b5a4e405

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 19:59:50 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 18:59:50 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <3dcxdV46tpz7Llb@mail.python.org>
Message-ID: <CAH_1eM3L1HaX8Lv7cj9hcvcG-=cuM4p-Q5mSc+eA_Ay_K__xUA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Roundup Robot added the comment:
>
> New changeset 03a056c3b88e by Gregory P. Smith in branch '3.3':
> Fixes issue #19929: Call os.read with 32768 within subprocess.Popen
> http://hg.python.org/cpython/rev/03a056c3b88e

Not that it bothers me, but AFAICT this isn't a bugfix, and as such
shouldn't be backported to 3.3, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:05:42 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 19:05:42 +0000
Subject: [issue19929] subprocess: increase read buffer size
In-Reply-To: <1386495490.95.0.0341161010002.issue19929@psf.upfronthosting.co.za>
Message-ID: <1386529542.24.0.534353452244.issue19929@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I saw a small regression over 4k when using a 64k buffer on one of my machines (dual core amd64 linux).  With 32k everything (amd64 linux, armv7l 32-bit linux, 64-bit os x 10.6) showed a dramatic improvement on the microbenchmark.  approaching 50% less cpu use in many cases.

i doubt applications will notice as much as they're likely to be dominated by their own application code rather than the subprocess internals.

re: 3.3 or not, true, but since it doesn't change any APIs and is minor I did it anyways.  If you think it doesn't belong there, leave it to the release manager to back out.  This and the #19506 change should be invisible to users.

----------
resolution:  -> fixed
stage: needs patch -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19929>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:18:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 19:18:07 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1386530287.04.0.850969369023.issue5845@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would say it's now closed. If there's some fine tuning needed, separate issues should be opened.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5845>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:25:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 19:25:52 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386530752.76.0.401577884994.issue11299@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Instead of copy.deepcopy, why not call itertools.tee?

For the record, pickling a live generator implies pickling a frame object. We wouldn't be able to guarantee cross-version compatibility for such pickled objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:29:52 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 08 Dec 2013 19:29:52 +0000
Subject: [issue19883] Integer overflow in zipimport.c
In-Reply-To: <1386501028.03.0.46604243691.issue19883@psf.upfronthosting.co.za>
Message-ID: <CAGE7PN+VddAR85QGuU-7uoXUWQf=XAZJvr5vUQ=fZd-4ovbMeA@mail.gmail.com>


Gregory P. Smith added the comment:

comments added to the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19883>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:37:40 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 08 Dec 2013 19:37:40 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386531460.85.0.164401344308.issue11299@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

The issue here is copy.deepcopy will raise an exception whenever it encounters a generator. We would like to do better here. Unfortunately, using itertools.tee is not a solution here because it does not preserve the type of the object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:38:29 2013
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 08 Dec 2013 19:38:29 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386531509.55.0.327778831246.issue11299@psf.upfronthosting.co.za>


Ram Rachum added the comment:

"Instead of copy.deepcopy, why not call itertools.tee?"

It's hard for me to give you a good answer because I submitted this ticket 2 years ago, and nowadays I don't have personal interest in it anymore.

But, I think `itertools.tee` wouldn't have worked for me, because it just saves the value rather than really duplicating the generator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 20:59:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 19:59:02 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1386531460.85.0.164401344308.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386532740.2291.6.camel@fsol>


Antoine Pitrou added the comment:

> The issue here is copy.deepcopy will raise an exception whenever it
> encounters a generator. We would like to do better here.
> Unfortunately, using itertools.tee is not a solution here because it
> does not preserve the type of the object.

Indeed, itertools.tee is not a general solution for copy.deepcopy, but
it's a good solution to *avoid* calling copy.deepcopy when you simply
want to "fork" a generator.

IMHO supporting live generators (and therefore frame objects) in
copy.deepcopy would be a waste of effort.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 21:13:53 2013
From: report at bugs.python.org (Ned Deily)
Date: Sun, 08 Dec 2013 20:13:53 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1386533633.8.0.402396992239.issue19542@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +fdrake, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Sun Dec  8 21:23:26 2013
From: report at bugs.python.org (Bastien Montagne)
Date: Sun, 08 Dec 2013 20:23:26 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1298477739.0.0.699409651893.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386534206.31.0.962060247422.issue11299@psf.upfronthosting.co.za>


Bastien Montagne added the comment:

Yes, itertools.tee just keep in memory elements produced by the "most advanced" iterator, until the "least advanced" iterator consumes them. It may not be a big issue in most cases, but I can assure you that when you have to iter several times over a million of vertices, this is not a good solution? ;)

Fortunately, in this case I can just produce several times the same generator, but still, would be nicer (at least on the ?beauty of the code? aspect) if there was a way to really duplicate generators.

Unless I misunderstood things, and deepcopying a generator would imply to also copy its whole source of data?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 21:29:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 20:29:08 +0000
Subject: [issue11299] Allow deepcopying paused generators
In-Reply-To: <1386534206.31.0.962060247422.issue11299@psf.upfronthosting.co.za>
Message-ID: <1386534545.2291.7.camel@fsol>


Antoine Pitrou added the comment:

> Unless I misunderstood things, and deepcopying a generator would imply
> to also copy its whole source of data?

deepcopying is "deep", and so would have to recursively deepcopy the
generator's local variables...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11299>
_______________________________________

From report at bugs.python.org  Sun Dec  8 21:30:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 20:30:23 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1386534623.24.0.978916087645.issue19542@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think the underlying question is: are weak dicts otherwise MT-safe?

----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Sun Dec  8 21:47:02 2013
From: report at bugs.python.org (anon)
Date: Sun, 08 Dec 2013 20:47:02 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386535622.09.0.437305069068.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Then I think we're in agreement with regards to bits_at. :) What should happen next?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sun Dec  8 21:57:11 2013
From: report at bugs.python.org (Ziyuan Lin)
Date: Sun, 08 Dec 2013 20:57:11 +0000
Subject: [issue19932] Missing spaces in import.h?
Message-ID: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>


New submission from Ziyuan Lin:

In Include\import.h, line 89-97:

PyAPI_FUNC(PyObject *)_PyImport_FindBuiltin(
    const char *name            /* UTF-8 encoded string */
    );
PyAPI_FUNC(PyObject *)_PyImport_FindExtensionObject(PyObject *, PyObject *);
PyAPI_FUNC(int)_PyImport_FixupBuiltin(
    PyObject *mod,
    char *name                  /* UTF-8 encoded string */
    );
PyAPI_FUNC(int)_PyImport_FixupExtensionObject(PyObject*, PyObject *, PyObject *);


Shouldn't they be the following:

PyAPI_FUNC(PyObject *) _PyImport_FindBuiltin(
    const char *name            /* UTF-8 encoded string */
    );
PyAPI_FUNC(PyObject *) _PyImport_FindExtensionObject(PyObject *, PyObject *);
PyAPI_FUNC(int)_PyImport_FixupBuiltin(
    PyObject *mod,
    char *name                  /* UTF-8 encoded string */
    );
PyAPI_FUNC(int) _PyImport_FixupExtensionObject(PyObject*, PyObject *, PyObject *);

----------
messages: 205605
nosy: Ziyuan.Lin
priority: normal
severity: normal
status: open
title: Missing spaces in import.h?
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Sun Dec  8 22:06:48 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Dec 2013 21:06:48 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386536808.1.0.522639690707.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't think we should be more selective about the errno values, the try block is narrow enough (just one syscall) and we really don't know what the kernel will do on different platforms.  And what would we do about it anyway?

I will look into the Windows problem, but I suspect the best we can do there is skip the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 22:20:00 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 08 Dec 2013 21:20:00 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386536808.1.0.522639690707.issue19876@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3BiM4YUXpmAYm6KnUZjaDcz4Z5OSAQU4z58S7dCL7ObQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> I will look into the Windows problem, but I suspect the best we can do there is skip the test.

I already took care of that:
http://hg.python.org/cpython/rev/01676a4c16ff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 22:21:43 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 Dec 2013 21:21:43 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386537703.31.0.272825907102.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Then here's a hopeful fix for the Windows situation that relies on the socketpair() operation reusing FDs from the lowest value. I'm adding asserts to check that this is actually the case. (These are actual assert statements to indicate that they are verifying an assumption internal to the test, not verifying the functionality under test.)

I'll test it when I next get near a Windows box (Monday in the office) -- or someone else with Windows access can let me know.

----------
Added file: http://bugs.python.org/file33048/nodup2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Sun Dec  8 22:57:12 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 08 Dec 2013 21:57:12 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1386539832.69.0.558540637865.issue19542@psf.upfronthosting.co.za>


Armin Rigo added the comment:

As you can see in x.py, the underlying question is rather: are weakdicts usable in a single thread of a multithreaded program?  I believe that this question cannot reasonably be answered No, independently on the answer you want to give to your own question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Sun Dec  8 22:58:51 2013
From: report at bugs.python.org (Ziyuan Lin)
Date: Sun, 08 Dec 2013 21:58:51 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386539931.9.0.365735317259.issue19932@psf.upfronthosting.co.za>


Ziyuan Lin added the comment:

To see the errors, one can install PyCUDA and Theano, and run code at http://deeplearning.net/software/theano/tutorial/using_gpu.html#id1 :


import numpy, theano
import theano.misc.pycuda_init
from pycuda.compiler import SourceModule
import theano.sandbox.cuda as cuda

class PyCUDADoubleOp(theano.Op):
    def __eq__(self, other):
        return type(self) == type(other)
    def __hash__(self):
        return hash(type(self))
    def __str__(self):
        return self.__class__.__name__
    def make_node(self, inp):
        inp = cuda.basic_ops.gpu_contiguous(
           cuda.basic_ops.as_cuda_ndarray_variable(inp))
        assert inp.dtype == "float32"
        return theano.Apply(self, [inp], [inp.type()])
    def make_thunk(self, node, storage_map, _, _2):
        mod = SourceModule("""
    __global__ void my_fct(float * i0, float * o0, int size) {
    int i = blockIdx.x*blockDim.x + threadIdx.x;
    if(i<size){
        o0[i] = i0[i]*2;
    }
  }""")
        pycuda_fct = mod.get_function("my_fct")
        inputs = [ storage_map[v] for v in node.inputs]
        outputs = [ storage_map[v] for v in node.outputs]
        def thunk():
            z = outputs[0]
            if z[0] is None or z[0].shape!=inputs[0][0].shape:
                z[0] = cuda.CudaNdarray.zeros(inputs[0][0].shape)
            grid = (int(numpy.ceil(inputs[0][0].size / 512.)),1)
            pycuda_fct(inputs[0][0], z[0], numpy.intc(inputs[0][0].size),
                       block=(512,1,1), grid=grid)
        return thunk


The interpreter will complain errors like "c:\python33\include\import.h(97): error: explicit type is missing ("int" assumed)" (at least in my case)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:02:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 22:02:50 +0000
Subject: [issue19846] print() and write() are relying on
 sys.getfilesystemencoding() instead of sys.getdefaultencoding()
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386540170.63.0.144134910673.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"haypo: title: Setting LANG=C breaks Python 3 -> print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding()"

Oh, I didn't want to change the title of the issue, it's a bug in Roundup when I reply by email :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:03:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 22:03:09 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386540189.29.0.266018029043.issue19846@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding() -> Setting LANG=C breaks Python 3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:13:05 2013
From: report at bugs.python.org (Julian Gindi)
Date: Sun, 08 Dec 2013 22:13:05 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386540785.44.0.192723836992.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Just wanted to check to see if there was anything else I should do regarding this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:14:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 Dec 2013 22:14:19 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386540859.02.0.552758347362.issue18983@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage: needs patch -> patch review
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:15:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Dec 2013 22:15:46 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386421680.88.0.190962819182.issue19915@psf.upfronthosting.co.za>
Message-ID: <1458383.zzRE6dW8Xc@raxxla>


Serhiy Storchaka added the comment:

> Extracting sign, exponent and significand fields from the binary
> representation of a float is at least one thing I'd use this for.

You don't need special function for bit operations. Float values are short (32 
or 64 bits) and any bit operations are O(1). Special function for bit 
extracting (or modifying) is needed when you process many hundreds or 
thousands of bits. In any case >> and & for 64-bit values are faster than 
method call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:19:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Dec 2013 22:19:31 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1386541171.2.0.980177109076.issue19542@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, you're right. We just need to cook up a patch then.

----------
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Sun Dec  8 23:22:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 22:22:16 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386541336.36.0.656118740651.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> Or said differently, the filesystem encoding is different than the
>> locale encoding.

> Indeed, but the FS encoding and the IO encoding are the same.
> "locale encoding" doesn't really matter here, as we are assuming that
> it's wrong.

Oh, I realized that "FS encoding" term in not clear. When I wrote "FS encoding", I mean sys.getfilesystemencoding() which is mbcs on Windows, UTF-8 on Mac OS X and (currently) the locale encoding on other platforms (UNIX, ex: Linux/FreeBSD/Solaris/AIX).

--

IMO there are two different points in this issue:

(a) which encoding should be used when the C locale is used: the encoding announced by the OS using nl_langinfo(CODESET) (current choice) or use an arbitrary optimistic "utf-8" encoding?

(b) for technical reasons, Python reuses the C codec during Python initialization to decode and encode OS data, and so currently Python *must* use the locale encoding for its "filesystem encoding"

Before being able to pronounce me on the point (a), I would like to see a patch fixing the point (b). I'm not against fixing point (b). I'm just saying that it's not trivial and obviously it must be fixed to change the status of point (a). I even gave clues to fix point (b).

--

asciilocale.patch has many issues. Try to run the Python test suite using this patch to see what I mean. Example of failures:

======================================================================
FAIL: test_non_ascii (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_cmd_line.py", line 140, in test_non_ascii
    assert_python_ok('-c', command)
  File "/home/haypo/prog/python/default/Lib/test/script_helper.py", line 69, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/home/haypo/prog/python/default/Lib/test/script_helper.py", line 55, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Unable to decode the command from the command line:
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc3' in position 12: surrogates not allowed

======================================================================
FAIL: test_ioencoding_nonascii (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 603, in test_ioencoding_nonascii
    self.assertEqual(out, os.fsencode(test.support.FS_NONASCII))
AssertionError: b'' != b'\xc3\xa6'

======================================================================
FAIL: test_nonascii (test.test_warnings.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_warnings.py", line 774, in test_nonascii
    "['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

======================================================================
FAIL: test_nonascii (test.test_warnings.PyEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/test/test_warnings.py", line 774, in test_nonascii
    "['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"


test_warnings is probably #9988, test_cmd_line failure is maybe #9992.

There are maybe other issues, the Python test suite only have a few tests for non-ASCII characters.

--

If anything is changed, I would prefer to have more than a few months of test to make sure that it doesn't break anything. So I set the version field to Python 3.5.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:04:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 23:04:40 +0000
Subject: [issue17429] platform.platform() can throw Unicode error
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <3dd35N0NHyz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 4580976c07cb by Victor Stinner in branch '3.3':
Issue #17429: platform.linux_distribution() now decodes files from the UTF-8
http://hg.python.org/cpython/rev/4580976c07cb

New changeset 407f18c8ce8a by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17429: platform.linux_distribution() now decodes files from
http://hg.python.org/cpython/rev/407f18c8ce8a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:09:23 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Sun, 08 Dec 2013 23:09:23 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1386544163.08.0.264037357048.issue19771@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Hello, I'm in the process of trying to find a solution to this problem, but I'm afraid the choice of wording at some point is kind of...ambiguous.

I have some questions I want to ask, to clear some doubts in my head:

First one is: 

"if __main__ in a package throws ImportError, runpy will incorrectly report the package as not being directly executable (when it actually claims to be executable, it's just broken)"

In the above, from what I can understand from the first part of the sentence, before the paragraph, if __main__.py is not found in a package, run py will report that it won't be directly executable. Along these lines, it's mentioned that this behaviour is incorrect, but then the sentence inside the parentheses contradicts that position, suggesting that when it does suggest it's actually executable, it's just erroneous behaviour (so both behaviours are erroneous?)

The second one is:

"This can be fixed in 3.3+ by checking for an appropriate value in the name attribute of the caught exception, and only wrapping it if the failed lookup was for the __main__ submodule we're looking for."

Ok this seems to be pretty clear, we are expected to create a new package with a __main__.py that all it does is `raise ImportError`. (Disclaimer: I may be fairly wrong here). Question is, where should we put the new package? Obviously, we shouldn't litter the "real" modules, with the testing one, but if I try to use the test folder as a package, I get "ImportError: error while finding loader for xxx"

Please be lenient with me, this is one of my very first contributions to python. I will gladly accept all feedback.

----------
nosy: +Fotis.Koutoulakis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19771>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:20:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 23:20:33 +0000
Subject: [issue17429] platform.platform() can throw Unicode error
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <3dd3Rh4ZzKz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 831b2c80a9c9 by Victor Stinner in branch 'default':
Issue #17429: some PEP 8 compliance fixes for the platform modules, add whitespaces
http://hg.python.org/cpython/rev/831b2c80a9c9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:25:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 23:25:01 +0000
Subject: [issue17429] platform.platform() can throw Unicode error
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <1386545101.69.0.747850264798.issue17429@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks Toshio Kuratomi for your patch. I simplified the unit test. I'm not sure that "resetlocale" restores the locale in its previous state. I don't want to rely on two specific locales ('pt_BR.UTF8' and 'pt_BR.ISO8859-1') for a such simple test. We have enough buildbots to test other various locales.

I prefered to only change minor syntax issues (PEP 8) in Python 3.4 to limit changes in the stable release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:26:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 23:26:22 +0000
Subject: [issue17429] platform.platform() can throw Unicode error
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <1386545182.85.0.811483821866.issue17429@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:26:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Dec 2013 23:26:45 +0000
Subject: [issue17429] platform.platform() can throw Unicode error
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <3dd3Zr57yTz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset a951ab03bda0 by Victor Stinner in branch '3.3':
Issue #17429: Oops, remove unused import
http://hg.python.org/cpython/rev/a951ab03bda0

New changeset 209bf9576dc8 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #17429: Oops, remove unused import
http://hg.python.org/cpython/rev/209bf9576dc8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:28:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 23:28:35 +0000
Subject: [issue17429] platform.linux_distribution() should decode files from
 UTF-8, not from the locale encoding
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <1386545315.65.0.801247295943.issue17429@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: platform.platform() can throw Unicode error -> platform.linux_distribution() should decode files from UTF-8, not from the locale encoding

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 00:28:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Dec 2013 23:28:41 +0000
Subject: [issue17429] platform.linux_distribution() should decode files from
 UTF-8, not from the locale encoding
In-Reply-To: <1363360110.07.0.662014346708.issue17429@psf.upfronthosting.co.za>
Message-ID: <1386545321.71.0.471230077328.issue17429@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17429>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:15:01 2013
From: report at bugs.python.org (Meador Inge)
Date: Mon, 09 Dec 2013 00:15:01 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386548101.42.0.448284543878.issue19904@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:15:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2013 00:15:32 +0000
Subject: [issue19830] test_poplib emits resource warning
In-Reply-To: <1385722372.69.0.175458653403.issue19830@psf.upfronthosting.co.za>
Message-ID: <3dd4g80Lhlz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 1e3c7153a14d by Victor Stinner in branch 'default':
Fix #19830: Fix a ResourceWarning in test_poplib.
http://hg.python.org/cpython/rev/1e3c7153a14d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19830>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:15:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 00:15:55 +0000
Subject: [issue19830] test_poplib emits resource warning
In-Reply-To: <1385722372.69.0.175458653403.issue19830@psf.upfronthosting.co.za>
Message-ID: <1386548155.25.0.077886156019.issue19830@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch fixes the ResourceWarning, thanks.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19830>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:16:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 00:16:09 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386548169.9.0.624885379409.issue18864@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/issue18864>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:24:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Dec 2013 00:24:19 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3
In-Reply-To: <1386541336.36.0.656118740651.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386548656.2291.11.camel@fsol>


Antoine Pitrou added the comment:

On dim., 2013-12-08 at 22:22 +0000, STINNER Victor wrote:
> (b) for technical reasons, Python reuses the C codec during Python
> initialization to decode and encode OS data, and so currently Python
> *must* use the locale encoding for its "filesystem encoding"

Ahhh! Well indeed that's a bummer :-)

> asciilocale.patch has many issues. Try to run the Python test suite
> using this patch to see what I mean.

I'm assuming much of this is due to (b) (all those tests seem to spawn
external processes).

It seems there is more work to do to get this right, but I'm not
terribly interested either. Feel free to take over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:30:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 00:30:50 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386549050.75.0.868448254943.issue19893@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, but I still don't understand this issue.

"Invalid read of size 4" is a known false positive. It can be worked around using ./configure --with-valgrind and the suppression list, or using ./configure --without-pymalloc. If you still get the warning, you used the wrong options or you are still using another Python binary (or shared library). Make sure that you are linked to your newly compiled shared library.

"valgrind --leak-check=full --log-file=valgrind.log ./python -c pass" shows me "possibly lost: 286,779 bytes in 654 blocks". This is also another known issue: Python doesn't release all the memory at exit, they are many "singletons" and variables initialized once but never released.

The PEP 3121 helps this issue but the PEP is not fully implemented yet, many modules should still be modified.

So what is your question? Do you think that Python leaks memory? Why do you think so?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19893>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:33:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 00:33:03 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386549183.93.0.570982081682.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It seems there is more work to do to get this right, but I'm not
> terribly interested either. Feel free to take over.

If you are talking to me: I'm currently opposed to change anything, so I'm not interested to work on a patch. IMO Python works fine and you should try to workaround the current limitations :-)

If someone is interested to write an huge patch fixing all these issues, I would be able to reconsider my opinion on point (a).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:34:26 2013
From: report at bugs.python.org (Fil Mackay)
Date: Mon, 09 Dec 2013 00:34:26 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386549266.38.0.317241267185.issue19904@psf.upfronthosting.co.za>


Fil Mackay added the comment:

Stefan, performance is not the principle motivator here: the intention is that it is just sensible to support this integer type, just like supporting int64 since it is an intrinsic type supported by CPU's.

Of course any integer length could be handled by memoryview unpacker, but this would not really make sense for int64. My view is that any intrinsic type (ie. register type) is the key point at which it should be supported by struct, and not a custom unpacker. 128/256/512 bit integers are in this category..

Principally this is so that it can be used by ctypes (see #19905).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:38:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Dec 2013 00:38:55 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386549266.38.0.317241267185.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386549532.2291.15.camel@fsol>


Antoine Pitrou added the comment:

> Of course any integer length could be handled by memoryview unpacker,
> but this would not really make sense for int64. My view is that any
> intrinsic type (ie. register type) is the key point at which it should
> be supported by struct, and not a custom unpacker. 128/256/512 bit
> integers are in this category..

I don't think "register types" matter here. The struct module provides
interoperability with low-level *data types* (in C and other common
languages), not CPU *registers*.

So IMHO the question is whether there is an use case for 128-bit
integers; *not* for arrays of four 32-bit integers packed in a 128-bit
register.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:39:25 2013
From: report at bugs.python.org (Fil Mackay)
Date: Mon, 09 Dec 2013 00:39:25 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386549565.71.0.377815756724.issue19904@psf.upfronthosting.co.za>


Fil Mackay added the comment:

Antoine,

No, the SIMD vector should be treated as a int128 (for eg.), not as 4 python ints. It is the unpacking process that unpacks into 4 python ints. The two shouldn't be confused - you definitely want to be able to treat the vector in both states (packed and unpacked).

I'm not saying that Python should necessarily make use of SIMD instructions (don't think performance is critical there in py), but that it should at least be access to a raw 128/256/512 bit integer within a C structure. Part of this is interacting with SIMD'able structures - at least in my use cases :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:44:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Dec 2013 00:44:45 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386549565.71.0.377815756724.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386549883.2291.18.camel@fsol>


Antoine Pitrou added the comment:

> The two shouldn't be confused - you definitely want to be able to
> treat the vector in both states (packed and unpacked).

Why do you need the packed state as a 128-bit int, rather than as a
bytes object? You are not doing arithmetic on it, AFAIU.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:49:12 2013
From: report at bugs.python.org (Meador Inge)
Date: Mon, 09 Dec 2013 00:49:12 +0000
Subject: [issue19905] Add 128-bit integer support to ctypes
In-Reply-To: <1386295654.39.0.271762839295.issue19905@psf.upfronthosting.co.za>
Message-ID: <1386550152.27.0.490965942566.issue19905@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19905>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:56:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2013 00:56:40 +0000
Subject: [issue19880] unittest: on failure,
 TestCase.run() keeps a reference to the exception
In-Reply-To: <1386110800.98.0.113346130856.issue19880@psf.upfronthosting.co.za>
Message-ID: <3dd5Zc0NyMz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 09658ea0b93d by Victor Stinner in branch 'default':
Close #19880: Fix a reference leak in unittest.TestCase. Explicitly break
http://hg.python.org/cpython/rev/09658ea0b93d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19880>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:57:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2013 00:57:33 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <3dd5bb6FZPz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset c4c1c4bc8086 by Victor Stinner in branch 'default':
Issue #19876: Run also test_selectors.test_unregister_after_fd_close_and_reuse() on Windows
http://hg.python.org/cpython/rev/c4c1c4bc8086

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Mon Dec  9 01:59:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 00:59:59 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386550799.6.0.0914291790593.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, I reverted my changeset c4c1c4bc8086, I didn't read why the test was skipped on Windows. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:01:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 01:01:06 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386550866.65.0.314450489276.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Except that it can fail with ENOENT, but also EBADF, and EPERM if the
FD has been reused by a FD which doesn't support epoll."

Oh, I didn't know that. I ran the unit test, and I expected the two unit test to cover any error case. So ignore my epoll_except.patch, the current "except OSError: pass" is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:04:52 2013
From: report at bugs.python.org (Fil Mackay)
Date: Mon, 09 Dec 2013 01:04:52 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386551092.5.0.939453411262.issue19904@psf.upfronthosting.co.za>


Fil Mackay added the comment:

Antoine,

> I don't think "register types" matter here. The struct module provides
> interoperability with low-level *data types* (in C and other common
> languages), not CPU *registers*.

OK, see where you're coming from. I guess my thinking was such that struct (and ctypes) support is required for data types that are common within C structures. The fact that 128-bit ints are now appearing within these structures is due to the fact that CPU support has dramatically improved, and are supported natively in register types. So it was kind of an indirect connection.

So the question I guess is whether you think these types are "common enough" in C structs, which for me they certainly are for my data processing applications.. (pretty please :)

> So IMHO the question is whether there is an use case for 128-bit
> integers; *not* for arrays of four 32-bit integers packed in a 128-bit
> register.

Agree completely - just stick to thinking about atomic 128-bit integers. A pack/unpack function should do the conversion, and have nothing to do with this struct support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:14:21 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 01:14:21 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386551661.09.0.324883144126.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

I have finished the changes needed to move script_helper from Lib/test to Lib/test/support, and I have also documented it. Tests run gracefully (but be sure to check out if it works as intended on your machines too)

Two notes though:

1. I have only made the changes on the default branch. Will do 3.3 tomorrow.

2. When it came to the documentation, I had to break the 80 characters limit, as going by it was resulting in weird rendering or wrong information depicted from sphinx (for example, when showing that script_helper functions belonged to test.support instead of the correct location, test.support.script_helper).

Last but not least, this is one of my first contributions to Python, so I would appreciate your input.

----------
keywords: +patch
nosy: +Fotis.Koutoulakis
Added file: http://bugs.python.org/file33049/script_helper-default.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:26:23 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 01:26:23 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1386552382.99.0.980228748818.issue19771@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

By providing a __main__.py submodule, a package is saying "I am directly executable". When runpy says it isn't (because running that file happened to raise ImportError), then runpy is wrong.

runpy can't make the file work (it's genuinely broken), but it can avoid reporting a misleading error message - that's the bug to be fixed.

As far as the testing goes, if you look at the existing runpy tests, the usual approach is to create a temporary directory, write out a package with the desired behaviour, and then run it from there. So, for this test, it's a matter of copying the general structure of the existing package execution test in test_runpy, but replacing the body of the __main__.py file with something like "raise ImportError('This should not be replaced')"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19771>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:54:26 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 01:54:26 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386554066.53.0.779178662607.issue19846@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list.

My current understanding of the situation:

- we should leave Windows and Mac OS X alone, since they ignore the locale when choosing the OS API encoding anyway

- the main problem is on Linux (but potentially other *nix systems as well), where people set "LANG=C" for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs.

Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces).

Tangentially related, we may want to consider aliasing sys.getfilesystemencoding, os.fsencode and os.fsdecode as something like sys.getosapiencoding, os.apiencode and os.apidecode, since the current naming is misleading (the value is based on the platform and environment, not any particular filesystem, and is used for almost all bytes-based OS APIs, not just filesystem metadata)

----------
nosy: +a.badger, bkabrda
title: Setting LANG=C breaks Python 3 -> Setting LANG=C breaks Python 3 on Linux

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 02:57:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 01:57:02 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386554222.87.0.406265968465.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I wouldn't worry about 3.3 at this point - the 3.3 test suite isn't going to see major changes for its final release, so the risk of merge conflicts is low.

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:02:04 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 02:02:04 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386554524.08.0.604807453773.issue18576@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: docs at python -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:04:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 02:04:40 +0000
Subject: [issue15403] Refactor package creation support code into a common
 location
In-Reply-To: <1342782793.3.0.140383152387.issue15403@psf.upfronthosting.co.za>
Message-ID: <1386554680.95.0.825214907365.issue15403@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I took a look at this last night, and found the combination of moving stuff around *and* refactoring it at the same time was too hard to review.

So, once the PEP 451 changes for runpy are done, I think it would make more sense to tackle this as at least three patches:

1. Do the refactoring *within* test_runpy to make the helper API a bit cleaner (this should also use types.SimpleNamespace where appropriate rather than a custom alternative)

2. Move the helper API out to a documented test.support.package_helper module without altering the test.support API

3+. Refactor other test modules to use the now shared API (there may be some pkg related functionality to move out of script_helper as well).

----------
dependencies: +Rename and document test.script_helper as test.support.script_helper, Update runpy for PEP 451

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15403>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:08:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 02:08:27 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1386554066.53.0.779178662607.issue19846@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbwqwqsFNLKk4ym4pzc7+HWwXjv_NpsFKtc-mFgCXq8JQ@mail.gmail.com>


STINNER Victor added the comment:

> End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list.

Sorry, I'm not aware of such issue. Do you have examples?

> - the main problem is on Linux (but potentially other *nix systems as well), where people set "LANG=C" for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs.

Why do you think that the issue is specific to Python 3? Try to open a
terminal with LC_ALL=C and try to type non-ASCII characters with your
keyboard. You can't because your terminal uses ASCII. Did you
applications written in another language handling Unicode, like Perl?
(Perl with Unicode support correctly enabled, it's "use utf8;" if I
remember correctly).

Can you explain the "various reasons" why users explictly force the
encoding to ASCII?

I use LANG=C to get manual pages and error messages in english. But
"LANG=en_US man ls" would be more correct, or "LC_MESSAGES=en_US man
ls" to be pedantic. (Env var priority: LC_ALL > LANG > LC_xxx).

IMO if you use LANG=C, you must not complain that Unicode stopped
working, but you should learn how to configure locales. Trivial
examples like the one which can be found in the initial message
(msg204849) are wrong: why would you force all locales to C and use
non-ASCII characters?

> Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces).

I don't see how it would help to solve my point (b).

Technically, this issue cannot be fixed. Or to be more specific, I
don't want to fix it, it's a waste of time. So I don't understand what
do you expect from this open issue?

I would prefer to close it as invalid or wontfix to be clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:31:39 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 09 Dec 2013 02:31:39 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <1386556299.59.0.2039097736.issue16099@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I left a few comments on Rietveld.

----------
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16099>
_______________________________________

From report at bugs.python.org  Mon Dec  9 03:56:42 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 02:56:42 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <CAMpsgwbwqwqsFNLKk4ym4pzc7+HWwXjv_NpsFKtc-mFgCXq8JQ@mail.gmail.com>
Message-ID: <CADiSq7dyf0F9wkM9LgNkACWfP23KVaa6zz2o0EXgBH9VW2rVmA@mail.gmail.com>


Nick Coghlan added the comment:

On 9 December 2013 12:08, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor added the comment:
>
>> End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list.
>
> Sorry, I'm not aware of such issue. Do you have examples?

Armin's travails with remote shell access and Python 3 are just as
likely today as they were a couple of years ago:
http://lucumr.pocoo.org/2011/12/7/thoughts-on-python3/

(although technically that was a terminal ending up with the POSIX
locale, rather than specifically LANG=C)

>> - the main problem is on Linux (but potentially other *nix systems as well), where people set "LANG=C" for a variety of reasons, but this has the side effect of Python 3 choosing an inappropriate encoding (ASCII rather than UTF-8) when talking to the OS APIs.
>
> Why do you think that the issue is specific to Python 3? Try to open a
> terminal with LC_ALL=C and try to type non-ASCII characters with your
> keyboard. You can't because your terminal uses ASCII. Did you
> applications written in another language handling Unicode, like Perl?
> (Perl with Unicode support correctly enabled, it's "use utf8;" if I
> remember correctly).

It's the fact this used to work transparently in Python 2 (since all
these interfaces were just bytes based on the Python side as well)
that's a problem. That makes the new sensitivity to the locale
encoding a usability regression, and that's a concern for distros that
are considering switching their default Python version.

> Can you explain the "various reasons" why users explictly force the
> encoding to ASCII?

- testing applications for POSIX compliance
- default settings on servers where you don't control the environment
- because they never previously had to care, and it's only Python 3
deciding to pay attention to it which makes it relevent for them

> I use LANG=C to get manual pages and error messages in english. But
> "LANG=en_US man ls" would be more correct, or "LC_MESSAGES=en_US man
> ls" to be pedantic. (Env var priority: LC_ALL > LANG > LC_xxx).
>
> IMO if you use LANG=C, you must not complain that Unicode stopped
> working, but you should learn how to configure locales. Trivial
> examples like the one which can be found in the initial message
> (msg204849) are wrong: why would you force all locales to C and use
> non-ASCII characters?

And yet, in Python 2, people could do that, and Python didn't care.
*That's* the regression I'm worried about. If it hadn't round-tripped
cleanly in Python 2, I wouldn't care here either.

>> Given the initialisation problems, this may be something that PEP 432 (the initialisation process rewrite) can help with (since it changes the initialisation order to create a more complete Python runtime before it starts to configure the OS interfaces).
>
> I don't see how it would help to solve my point (b).

Having a Python runtime available makes things that are currently
tediously painful to deal with during startup easier to tweak. I'm not
sure it *will* help in this particular case, but it's now one I'm
going to keep an eye on.

> Technically, this issue cannot be fixed. Or to be more specific, I
> don't want to fix it, it's a waste of time. So I don't understand what
> do you expect from this open issue?

A way to get Python 3 to cope as well with a misconfigured OS
environment as Python 2 did.

> I would prefer to close it as invalid or wontfix to be clear.

It's a usability regression from Python 2, so I don't want to give up
on it. It may be that we just implement a "ignore what the OS claims,
it's misconfigured, just use UTF-8 for everything" flag. But OS
configuration errors shouldn't cripple the Python runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 04:29:44 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Dec 2013 03:29:44 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386559784.81.0.342826722451.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

@serhiy, Mark certainly knows the proposed addition isn't _needed_ to pick apart 64-bit integers.  It's an issue there of clarity, not O() behavior.  For example, `i.bits_at(0, 52)` to get at a double's mantissa requires no thought at all to write or to read later; bit-level gibberish like

i & ~((~0) << 52)

or

i & ((1 << 52) - 1)

or ... is painful to write and to read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 04:35:30 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Dec 2013 03:35:30 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386560130.57.0.424485208059.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

[@anon]
> What should happen next?

1. Write docs.
2. Write a test suite and test a Python implementation.
3. Write C code, and reuse the test suite to test that.
4. Attach a patch for all of that to this issue (although a
   Python implementation is no longer interesting at this point).
5. After that's all ready, seek consensus on Python-Dev.

The good news:  this is too minor to require a PEP ;-)

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 04:55:35 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Dec 2013 03:55:35 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1386561335.05.0.0659919159877.issue19542@psf.upfronthosting.co.za>


Tim Peters added the comment:

The weakref.slice fix looks solid to me, although it appears to be specific to 2.7 (the methods are fancier on the current default branch, fiddling with self._pending_removals too).

Does anyone know why the signature of pop is:

    def pop(self, key, *args)

?  It doesn't make sense to me to accept any number of arguments following `key`.  Perhaps it's just an obscure way to avoid doing:

_noarg = object()  # unique sentinel

def pop(self, key, default=_noarg):

?

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:03:50 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 09 Dec 2013 04:03:50 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386561830.94.0.170501136856.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

You should keep things more simple:

- Python and the operation system/filesystem are in a client-server relationship and Python should validate all.
- It doesn't matter what you will finally decide to be the default encoding on various places - all will provide race-conditions with no exception.
- The easiest way to fix this is to give the developer the ability to make a decision (like sys.use_strict_encoding(), sys.setfilesystemencoding(), sys.setdefaultencoding() etc.).
* For example giving the developer control is especially needed if he wants to handle multiple different filesystems.


> Why do you think that the issue is specific to Python 3? Try to open a
> terminal with LC_ALL=C and try to type non-ASCII characters with your
> keyboard. You can't because your terminal uses ASCII.

sworddragon at ubuntu:~$ LANG=C
sworddragon at ubuntu:~$ ?
bash: $'\303\244': command not found

- The terminal doesn't pseudo-crash with an exception because it doesn't matter about encodings.
- It allows to change the encoding at runtime.


> Did you
> applications written in another language handling Unicode, like Perl?

Compare C: It wouldn't matter like the terminal. For example fopen will simply return NULL if it can't open the file '?' because the filesystem is endoded with ISO-8859-1 and we wanted to open the utf-8 counterpart.


> Can you explain the "various reasons" why users explictly force the
> encoding to ASCII?

For example I'm using this for testcases to set the language uncomplicated to english.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:24:20 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 04:24:20 +0000
Subject: [issue19933] Round default argument for "ndigits"
Message-ID: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo:

>From the docs for built-in function "round":
   "If ndigits is omitted, it defaults to zero"
   (http://docs.python.org/3/library/functions.html#round)

But, the only way to get an integer from `round` is by not having the second argument (ndigits):

    >>> round(3.5)
    4
    >>> round(3.5, 1)
    3.5
    >>> round(3.5, 0)
    4.0
    >>> round(3.5, -1)
    0.0
    >>> round(3.5, None)
    Traceback (most recent call last):
      File "<pyshell#6>", line 1, in <module>
        round(3.5, None)
    TypeError: 'NoneType' object cannot be interpreted as an integer


Either the docs are wrong or the behavior is wrong. I think it's easier to fix the former...

But also there should be a way to make round return an integer (e.g. passing `None` as 2nd argument)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 205647
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: Round default argument for "ndigits"
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:54:38 2013
From: report at bugs.python.org (Matthew Gilson)
Date: Mon, 09 Dec 2013 04:54:38 +0000
Subject: [issue19934] collections.Counter.most_common does not document `None`
 as acceptable input.
Message-ID: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>


New submission from Matthew Gilson:

Reading the source for collections.Counter.most_common, the docstring mentions that `n` can be `None` or omitted, but the online documentation does not mention that `n` can be `None`.

----------
assignee: docs at python
components: Documentation
messages: 205648
nosy: docs at python, mgilson
priority: normal
severity: normal
status: open
title: collections.Counter.most_common does not document `None` as acceptable input.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19934>
_______________________________________

From report at bugs.python.org  Mon Dec  9 05:59:56 2013
From: report at bugs.python.org (Matthew Gilson)
Date: Mon, 09 Dec 2013 04:59:56 +0000
Subject: [issue19934] collections.Counter.most_common does not document `None`
 as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1386565196.04.0.355334813737.issue19934@psf.upfronthosting.co.za>


Matthew Gilson added the comment:

This is a very simple patch which addresses the issue.  I am still curious whether the reported function signature should be changed from:

    .. method:: most_common([n])

to:

    .. method:: most_common(n=None)

.  Any thoughts?

Also, while I was in there, I changed a few *None* to ``None`` for consistency with the rest of the documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file33050/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19934>
_______________________________________

From report at bugs.python.org  Mon Dec  9 07:52:30 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 06:52:30 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386571950.57.0.635364876825.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch.

After patch:

round(1.23, 0) => 1 not 1.0

round(4.67, 0) => 5 not 5.0

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33051/fix_round_with_zero_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 07:53:13 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 06:53:13 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386571993.27.0.685216157149.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 08:02:16 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 07:02:16 +0000
Subject: [issue19934] collections.Counter.most_common does not document `None`
 as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1386572536.54.0.389201442971.issue19934@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19934>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:30:47 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 08:30:47 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386577847.69.0.681233550112.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> After patch:
> round(1.23, 0) => 1 not 1.0
> round(4.67, 0) => 5 not 5.0

Please no!  Two-argument round should continue to return a float in all cases.

The docs should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:32:07 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 08:32:07 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386577927.34.0.562343917751.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> But also there should be a way to make round return an integer

I don't understand.  There's already a way to make round return an integer: don't pass a second argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:56:39 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:56:39 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579399.38.0.211814636939.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, here is the patch to fix the doc.

----------
Added file: http://bugs.python.org/file33052/fix_doc_round_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:57:09 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:57:09 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579429.58.0.255190889492.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33052/fix_doc_round_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:57:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:57:23 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579442.99.0.750984725928.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33053/fix_doc_round_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:57:58 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:57:58 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579478.88.0.730386768016.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33053/fix_doc_round_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 09:58:06 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 08:58:06 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386579486.32.0.657112433624.issue19933@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33054/fix_doc_round_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:36:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 09:36:51 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386581811.22.0.490923009542.issue19846@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> And yet, in Python 2, people could do that, and Python didn't care.
> *That's* the regression I'm worried about. If it hadn't round-tripped
> cleanly in Python 2, I wouldn't care here either.

$ python2.7 -c "print u'\u20ac'"
?
$ LANG=C python2.7 -c "print u'\u20ac'"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position 0: ordinal not in range(128)

And even worse:

$ python2.7 -c "print u'\u20ac'" >/dev/null
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position 0: ordinal not in range(128)

What the wart!

Other program can produces wrong (or even absolutely senseless) output with C locale.

$ LANG=C ls
???????????? ????????????????                                      ???????????????????? ??????????
?????????? ??????????????                                          ?????????????? ????????????????????????
?????????? ????????                                                ???????????? ??????????????
?????????????? ??????????????????                                  ???????? ????????????????????

What is better, silently produce corrupted output or raise an exception? If first, then let just set the "replace" or "backslashreplace" error handler for sys.stdout by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:40:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 09:40:34 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1386561830.94.0.170501136856.issue19846@psf.upfronthosting.co.za>
Message-ID: <3749452.KIQ9uviEyx@raxxla>


Serhiy Storchaka added the comment:

> sworddragon at ubuntu:~$ LANG=C
> sworddragon at ubuntu:~$ ?
> bash: $'\303\244': command not found
> 
> - The terminal doesn't pseudo-crash with an exception because it doesn't
> matter about encodings. - It allows to change the encoding at runtime.

This is not a locale of your terminal. Try `LANG=C xterm`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:46:27 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 09:46:27 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386582387.27.0.987544731097.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Hello again.

Is everything ok with the patch? Is there something not working as expected? Perhaps an omission or something? Do I need to do something more to get it accepted?

Thanks for your time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:58:25 2013
From: report at bugs.python.org (Yu Yang)
Date: Mon, 09 Dec 2013 09:58:25 +0000
Subject: [issue19935] IPv6 urlparse error on python 2.6
Message-ID: <1386583105.68.0.458235905987.issue19935@psf.upfronthosting.co.za>


New submission from Yu Yang:

Actually, there is a bug which has been fixed this issue on python 2.7 and python 3.3. http://bugs.python.org/issue2987. Open this issue aims for back port this fix to python 2.6.

----------
components: Library (Lib)
messages: 205657
nosy: yuyangbj
priority: normal
severity: normal
status: open
title: IPv6 urlparse error on python 2.6
type: enhancement
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19935>
_______________________________________

From report at bugs.python.org  Mon Dec  9 10:59:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 09:59:36 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386583176.68.0.897960063604.issue19915@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> For example, `i.bits_at(0, 52)` to get at a double's mantissa requires no thought at all to write or to read later; bit-level gibberish like

I agree that special function or method looks more clear. But I suppose that in many cases the performance does matter. And function call has larger overhead in current Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:01:15 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2013 10:01:15 +0000
Subject: [issue19935] IPv6 urlparse error on python 2.6
In-Reply-To: <1386583105.68.0.458235905987.issue19935@psf.upfronthosting.co.za>
Message-ID: <1386583275.47.0.270974776051.issue19935@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python 2.6 has reached its end of life cycle and doesn't receive fixes anymore. You have to maintain a bugfix yourself or update to a more recent version of Python.

----------
nosy: +christian.heimes
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19935>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:05:55 2013
From: report at bugs.python.org (Yu Yang)
Date: Mon, 09 Dec 2013 10:05:55 +0000
Subject: [issue19935] IPv6 urlparse error on python 2.6
In-Reply-To: <1386583105.68.0.458235905987.issue19935@psf.upfronthosting.co.za>
Message-ID: <1386583555.77.0.352048818291.issue19935@psf.upfronthosting.co.za>


Yu Yang added the comment:

As the OpenStack support python 2.6, python 2.7 and python 3.3, and IPv6 management network is supported by OpenStack, so we need to back port urlparse problem for IPv6 to python 2.6, otherwise there will be limitation on python 2.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19935>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:07:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 10:07:16 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386583636.74.0.210535620246.issue18576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please left test.script_helper as alias to test.support.script_helper.

I.e. test/script_helper.py should contains something like:

from test.support.script_helper import *

And test this with unmodifiable other tests.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:08:20 2013
From: report at bugs.python.org (Yu Yang)
Date: Mon, 09 Dec 2013 10:08:20 +0000
Subject: [issue19935] IPv6 urlparse error on python 2.6
In-Reply-To: <1386583105.68.0.458235905987.issue19935@psf.upfronthosting.co.za>
Message-ID: <1386583700.52.0.928476547567.issue19935@psf.upfronthosting.co.za>


Yu Yang added the comment:

@Christian Heimes, thanks for your response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19935>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:11:55 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 09 Dec 2013 10:11:55 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386583915.11.0.38564520601.issue19846@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The "C" locale is part of the ANSI C standard. The "POSIX" locale is an alias for the "C" locale and a POSIX standard, so we cannot just replace the ASCII encoding with UTF-8 as we wish, so Antoine's patch won't work.

See e.g. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html

The C and POSIX locale settings are the only locale settings that are guaranteed to always exist in C libraries. Python 3 should work with such locale settings. It doesn't have to be able to output non-ASCII code points, but it should run with ASCII data.

AFAIK, Python 3 does work with ASCII data in the C locale, so I'm not sure whether this is a bug at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:13:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 10:13:15 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386583995.79.0.249540871674.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't understand Serhiy's "ls" example. I tried:

$ mkdir unicode
$ cd unicode
$ python3 -c 'open("ab\xe9.txt", "w").close()'
$ python3 -c 'open("euro\u20ac.txt", "w").close()'
$ ls
ab?.txt  euro?.txt
$ LANG=C ls
ab??.txt  euro???.txt


Ah yes, I didn't remember that "ls" is aware of the locale encoding.

printf() and wprintf() behave differently on unencodable/undecoable characters:
http://unicodebook.readthedocs.org/en/latest/programming_languages.html#printf-functions-family

Again, the issue is not specific to Python. So it's time to learn how to configure correctly your locales.

About the "interoperability" point I mentionned in my first message ("This encoding is the best choice for interopability with other (python2 or non python) programs."): if you work around the annoying ASCII encoding by forcing UTF-8 encoding, Python may produce data which would be incompatible with other applications following POSIX and so using the ASCII encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:17:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 10:17:14 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386584234.11.0.138647229776.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Nick> testing applications for POSIX compliance

Sorry but what do you mean by "POSIX compliance"? The POSIX standard only specify the ASCII encoding.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
"The tables in Locale Definition describe the characteristics and behavior of the POSIX locale for data consisting entirely of characters from the portable character set and the control character set. For other characters, the behavior is unspecified. For C-language programs, the POSIX locale shall be the default locale when the setlocale() function is not called."

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap06.html#tagtcjh_3
"Portable character set" = ASCII

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:19:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 10:19:10 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386584350.77.0.371148951076.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Marc-Andre> AFAIK, Python 3 does work with ASCII data in the C locale, so I'm not sure whether this is a bug at all.

What do you mean? Python uses the surrogateescape encoding since Python 3.1, undecodable bytes are stored as surrogate characters.

Many bugs related to locales were fixed in Python 3.2, 3.3 and 3.4.

There are remaining bugs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:30:12 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 09 Dec 2013 10:30:12 +0000
Subject: [issue19846] Setting LANG=C breaks Python 3 on Linux
In-Reply-To: <1386584350.77.0.371148951076.issue19846@psf.upfronthosting.co.za>
Message-ID: <52A59BB1.40007@egenix.com>


Marc-Andre Lemburg added the comment:

On 09.12.2013 11:19, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> Marc-Andre> AFAIK, Python 3 does work with ASCII data in the C locale, so I'm not sure whether this is a bug at all.
> 
> What do you mean? Python uses the surrogateescape encoding since Python 3.1, undecodable bytes are stored as surrogate characters.
> 
> Many bugs related to locales were fixed in Python 3.2, 3.3 and 3.4.
> 
> There are remaining bugs?

I was referring to the original bug report on this ticket.

FWIW: I don't think you can expect Python to work without exceptions
if you use a C locale and write non-ASCII data to stdout. I also
don't think that the new ticket title is correct - or at least,
I fail to see which aspect of Python breaks with LANG=C :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:41:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Dec 2013 10:41:07 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1386585667.66.0.290865601086.issue19542@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Changeset ea70032a24b1 is where the pop(*args) thing comes from.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec  9 11:42:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 10:42:16 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386585736.77.0.335520394132.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm closing the issue as invalid, because Python 3 behaviour is correct and must not be changed.


Standard streams (sys.stdin, sys.stdout, sys.stderr) uses the locale encoding. sys.stdin and sys.stdout use the strict error handler, sys.stderr uses the backslashreplace error handler. These encodings and error handlers can be overriden by the PYTHONIOENCODING. Since Python 3.3, it's possible to only set the error handler using ":errors" syntax (ex: PYTHONIOENCODING=":replace").


Python uses sys.getfilesystemencoding() to decode data from / encode data to the operating system. Example of operating system data: command line arguments, environment variables, host names, filenames, user names, etc.

On Windows, Python tries to use the wide character (Unicode) API of Windows anywhere to avoid any conversion, to not loose data. The MBCS codec (ANSI code page) of Windows uses a replace error handler by default, it looses data. Try for example os.listdir() in a directory containing filenames not encodable to the ANSI code page in Python 2 (or os.listdir(b'.') in Python 3).

On Mac OS X, Python always use UTF-8 for sys.getfilesystemencoding() (with the surrogateescape error handler, see the PEP 383). The locale encoding is ignored for sys.getfilesystemencoding() (the locale encoding is still used in some functions).

On other operating systems... it's more complex. Python uses the locale encoding for sys.getfilesystemencoding() (with the surrogateescape error handler, see the PEP 383). For the POSIX locale (aka the "C" locale), you may get the ASCII encoding on Linux, ASCII on FreeBSD and Solaris (whereas these operating systems announce an alias of the ISO 8859-1 encoding, but use ASCII in practice), ISO 8859-1 on AIX etc. Using the locale encoding is the best choice for interoperability with other applications (which use also the locale encoding).

Even if an application uses "raw bytes" (like Python 2), these bytes are still "locale aware". For example, when "raw bytes" are written to the standard output, bytes are decoded to find the appropriate character in the font of the terminal. When "raw bytes" are written into a socket to generate a HTML document (ex: listing of a directory, so a list of filenames), the web brower will decode them from them encoding announced in the HTML page. Even if the encoding is not explicit, it does still exist. Read other comments of this issue for other examples.

Forcing the POSIX locale to get an user interface in english is wrong if you also expect from your application to still generate valid "raw bytes" in your "system" encoding (ISO 8859-1, ShiftJIS, UTF-8, whatever). To change the language, the correct environment variable is LC_CTYPE: use LC_CTYPE=C. Or better, use the real english locale which will probably handle better currency, numbers, etc. Example: LC_CTYPE=en_US.utf8 (on Fedora, "en_US" locale uses the ISO 8859-1 encoding).

----------
resolution:  -> invalid
status: open -> closed
title: Setting LANG=C breaks Python 3 on Linux -> Python 3 raises Unicode errors with the C locale
versions: +Python 3.3, Python 3.4 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:13:13 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 11:13:13 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386587593.23.0.413131823195.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Ok, here is the second (modified patch) which contains a script so that no modifications are required to existing tests.

I am uploading it as a second patch, so that the first one is left as a reference.

As a sidenote, I fail to see convincing reasons for why we would want the second solution more than the first. The first one looks cleaner to my eyes. The only downside I can see to the original approach is breaking a couple of tests, which is something that can be fixed easily without even making it to the repo (running the tests in 2-3 could help find all possible broken tests beforehand).

Could someone explain to me why the second solution is more desirable?

----------
Added file: http://bugs.python.org/file33055/issue_18576_second.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:23:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 11:23:21 +0000
Subject: [issue19936] Executable permissions of Python source files
Message-ID: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following files have executable permission bit but have no shebang ("#!"):

Lib/test/ssltests.py
Lib/test/test_pathlib.py
Lib/token.py
Tools/scripts/analyze_dxp.py
Tools/scripts/run_tests.py
Tools/scripts/win_add2path.py
Tools/stringbench/stringbench.py

I think executable bit should be cleared on them, because they can't be ran 
without correct shebang.

Following files have shebang but have no executable permission bit:

Doc/includes/email-alternative.py
Doc/includes/email-dir.py
Doc/includes/email-unpack.py
Lib/difflib.py
Lib/http/cookies.py
Lib/idlelib/PyShell.py
Lib/lib2to3/tests/data/different_encoding.py
Lib/lib2to3/tests/data/false_encoding.py
Lib/mailbox.py
Lib/operator.py
Lib/smtplib.py
Lib/tarfile.py
Lib/test/_test_multiprocessing.py
Lib/test/crashers/recursive_call.py
Lib/test/curses_tests.py
Lib/test/multibytecodec_support.py
Lib/test/test___future__.py
Lib/test/test_bz2.py
Lib/test/test_cmd.py
Lib/test/test_codecencodings_cn.py
Lib/test/test_codecencodings_hk.py
Lib/test/test_codecencodings_iso2022.py
Lib/test/test_codecencodings_jp.py
Lib/test/test_codecencodings_kr.py
Lib/test/test_codecencodings_tw.py
Lib/test/test_codecmaps_cn.py
Lib/test/test_codecmaps_hk.py
Lib/test/test_codecmaps_jp.py
Lib/test/test_codecmaps_kr.py
Lib/test/test_codecmaps_tw.py
Lib/test/test_dbm.py
Lib/test/test_dbm_dumb.py
Lib/test/test_eof.py
Lib/test/test_gzip.py
Lib/test/test_keywordonlyarg.py
Lib/test/test_logging.py
Lib/test/test_marshal.py
Lib/test/test_multibytecodec.py
Lib/test/test_popen.py
Lib/test/test_random.py
Lib/test/test_sched.py
Lib/test/test_smtpnet.py
Lib/test/test_socket.py
Lib/test/test_support.py
Lib/test/test_tcl.py
Lib/test/test_urllib2_localnet.py
Lib/test/test_urllib2net.py
Lib/test/test_urllibnet.py
Lib/test/test_with.py
Lib/test/test_xmlrpc_net.py
Lib/timeit.py
Lib/trace.py
Lib/turtledemo/bytedesign.py
Lib/turtledemo/clock.py
Lib/turtledemo/forest.py
Lib/turtledemo/fractalcurves.py
Lib/turtledemo/lindenmayer.py
Lib/turtledemo/minimal_hanoi.py
Lib/turtledemo/paint.py
Lib/turtledemo/peace.py
Lib/turtledemo/penrose.py
Lib/turtledemo/planet_and_moon.py
Lib/turtledemo/tree.py
Lib/turtledemo/two_canvases.py
Lib/turtledemo/yinyang.py
Lib/webbrowser.py
Mac/Tools/bundlebuilder.py
Mac/Tools/plistlib_generate_testdata.py
Modules/_ctypes/libffi/generate-ios-source-and-headers.py
Modules/_ctypes/libffi/generate-osx-source-and-headers.py
Modules/_decimal/tests/bench.py
Modules/_decimal/tests/deccheck.py
Modules/_decimal/tests/randdec.py
Objects/typeslots.py
Tools/clinic/clinic_test.py
Tools/gdb/libpython.py
Tools/i18n/makelocalealias.py
Tools/pybench/Setup.py
Tools/pybench/clockres.py
Tools/pybench/systimes.py
Tools/scripts/checkpip.py
Tools/ssl/make_ssl_data.py
Tools/test2to3/maintest.py
Tools/unicode/comparecodecs.py
Tools/unittestgui/unittestgui.py

I think most of them should got executable bit.

Exceptions are:

Doc/includes/*.py  -- they are just examples, it can be dangerous set 
executable bit on files which can be exposed via http server.

Lib/test/test_*.py -- they don't purposed to ran with with default system 
Python. Shebangs should be removed.

Lib/test/_test_multiprocessing.py, Lib/test/multibytecodec_support.py -- they 
are just auxiliary modules for other tests. Shebangs should be removed.

Lib/http/cookies.py, Lib/mailbox.py, Lib/operator.py, Modules/_decimal/tests/randdec.py -- they don't do anything. Shebangs should be removed.

Tools/test2to3/maintest.py -- this is Python2 script with Python3 shebang.

Lib/difflib.py -- this just runs doctests. Shebang should be removed.

Following files have shebang but have no executable permission bit. Both should be removed.

Lib/test/test_array.py
Lib/test/test_binhex.py
Lib/test/test_errno.py
Lib/test/test_urlparse.py
Lib/test/test_userstring.py

In Tools/unittestgui/unittestgui.py "python" should be changed to "python3" in the shebang.

Any thoughts?

----------
assignee: serhiy.storchaka
components: Demos and Tools, Library (Lib)
files: executable_scripts.patch
keywords: patch
messages: 205677
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Executable permissions of Python source files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33056/executable_scripts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19936>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:32:59 2013
From: report at bugs.python.org (Roman)
Date: Mon, 09 Dec 2013 11:32:59 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386588779.64.0.240852972618.issue19893@psf.upfronthosting.co.za>


Roman added the comment:

I've checked it one more time.
And you're right (Sorry for trouble). I left old pyconfig.h in one place, so my new python compilation was not just what I wanted. 

Now I belive that everything with memory is ok. 

Thank you very much for your help.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19893>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:40:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2013 11:40:36 +0000
Subject: [issue19817] tracemalloc add a memory limit feature
In-Reply-To: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za>
Message-ID: <3ddMsc1v1Rz7Lkg@mail.python.org>


Roundup Robot added the comment:

New changeset 45442f2a2494 by Victor Stinner in branch 'default':
Issue #19817: Fix print_exception(), clear the exception on error
http://hg.python.org/cpython/rev/45442f2a2494

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19817>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:44:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 11:44:45 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386589485.95.0.584906383075.issue18576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Third party code can use tests.script_helper.

I prefer to do these changes in several steps:

1) Move script_helper.py to Lib/test/support/, document it, and create an alias (with deprecation warning).
2) Ensure that this doesn't break any buildbot.
3) Change tests to use test.support.script_helper instead of test.script_helper.
4) One or two versions later remove an alias.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:46:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 11:46:34 +0000
Subject: [issue19893] Python cApi memory problem. Py_Initialize memory leak
In-Reply-To: <1386233423.48.0.18644500123.issue19893@psf.upfronthosting.co.za>
Message-ID: <1386589594.58.0.372706008177.issue19893@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19893>
_______________________________________

From report at bugs.python.org  Mon Dec  9 12:49:04 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 11:49:04 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386589744.8.0.198885528695.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Oh, I see. Does the last patch meet your expectations, or would you rather see all these changes implemented at once?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:04:29 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 12:04:29 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386590669.89.0.881694189595.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks.  It's inaccurate to say that a float is returned in general, though:  for most builtin numeric types, what's returned has the same type as its input.  So rounding a Decimal to two places gives a Decimal on output, etc.  (That's already explained in the next paragraph.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:06:37 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 12:06:37 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386590797.65.0.0572420085594.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

How about just removing the mention of 'defaults to zero', and say something like: "if ndigits is omitted, returns the nearest int to its input"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:17:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 12:17:34 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386591454.95.0.019856524284.issue18576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Does the last patch meet your expectations, or would you rather see all these changes implemented at once?

I left this for Nick.

I have added comments on Rietveld.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:41:14 2013
From: report at bugs.python.org (Jens Timmerman)
Date: Mon, 09 Dec 2013 12:41:14 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1386592874.41.0.817976544248.issue4130@psf.upfronthosting.co.za>


Jens Timmerman added the comment:

Since this is fixed in upstream libffi, can this be synced with the libffi included in python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Mon Dec  9 13:41:36 2013
From: report at bugs.python.org (Jens Timmerman)
Date: Mon, 09 Dec 2013 12:41:36 +0000
Subject: [issue13492] ./configure --with-system-ffi=LIBFFI-PATH
In-Reply-To: <1322472271.69.0.0807066602711.issue13492@psf.upfronthosting.co.za>
Message-ID: <1386592896.62.0.352391261396.issue13492@psf.upfronthosting.co.za>


Jens Timmerman added the comment:

As a workaround, you can make the libffi build work by applying this patch.

https://github.com/atgreen/libffi/pull/43

(indeed, see also http://bugs.python.org/issue4130 )

----------
nosy: +Jens.Timmerman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13492>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:15:59 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 09 Dec 2013 13:15:59 +0000
Subject: [issue19843] Wait for multiple sub-processes to terminate
In-Reply-To: <1385826813.77.0.0339260517434.issue19843@psf.upfronthosting.co.za>
Message-ID: <1386594959.24.0.718403086002.issue19843@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I replied to your comments here:
http://bugs.python.org/review/19843/
Assuming the deadlock problem gets fixed would you consider this feature worthy for inclusion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19843>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:20:13 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 09 Dec 2013 13:20:13 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386595213.13.0.927643727078.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

> I'm closing the issue as invalid, because Python 3 behaviour is correct > and must not be changed.

The fact that write() uses sys.getfilesystemencoding() is either a defect or a bad design (I leave the decision to you).


But I'm still missing a reply to my suggestion. As I'm seeing it has no disadvantages to give the developer optionally the control.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:20:44 2013
From: report at bugs.python.org (Fotis Koutoulakis)
Date: Mon, 09 Dec 2013 13:20:44 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1386595244.49.0.635528703671.issue18576@psf.upfronthosting.co.za>


Fotis Koutoulakis added the comment:

Taking the feedback during code review, this is a patch that has the points raised by Serhiy Storchaka fixed.

As always, please do note omission or mistakes from my part. Thanks for your help.

----------
Added file: http://bugs.python.org/file33057/issue18576_third_try.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:27:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 13:27:37 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386595657.29.0.462367847391.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The fact that write() uses sys.getfilesystemencoding() is either a defect or a bad design (I leave the decision to you).

"Standard streams (sys.stdin, sys.stdout, sys.stderr) uses the locale encoding. sys.stdin and sys.stdout use the strict error handler, sys.stderr uses the backslashreplace error handler. These encodings and error handlers can be overriden by the PYTHONIOENCODING. Since Python 3.3, it's possible to only set the error handler using ":errors" syntax (ex: PYTHONIOENCODING=":replace")."

stdout uses the locale encoding (and if you read my whole message, you may understand why sys.getfilesystemencoding() is also the locale encoding on UNIX).

(FYI on Windows, the OEM code page is used for standard streams.)

sys.getdefaultencoding() is always utf-8, this is unrelated to standard streams and OS data: it's the default value of the encoding parameter of str.encode() and str.decode(). I'm surprised that it's not documented to be utf-8, it is hardcoded and so always utf-8 in Python 3.

> But I'm still missing a reply to my suggestion. As I'm seeing it has no disadvantages to give the developer optionally the control.

"Standard streams (sys.stdin, sys.stdout, sys.stderr) uses the locale encoding. sys.stdin and sys.stdout use the strict error handler, sys.stderr uses the backslashreplace error handler. These encodings and error handlers can be overriden by the PYTHONIOENCODING. Since Python 3.3, it's possible to only set the error handler using ":errors" syntax (ex: PYTHONIOENCODING=":replace")."

If the environment variable is not enough, see also #15216 which proposes to add a TextIOWrapper.set_encoding() method. (I'm not really a fan of this proposition, but it looks like some users ask for it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:28:57 2013
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 09 Dec 2013 13:28:57 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386595737.86.0.198571114705.issue19846@psf.upfronthosting.co.za>


Larry Hastings added the comment:

> The fact that write() uses sys.getfilesystemencoding() is either
> a defect or a bad design (I leave the decision to you).

I have good news for you.  write() does not cal sys.getfilesystemencoding(), because the encoding is set at the time the file is opened.


> But I'm still missing a reply to my suggestion. As I'm seeing it
> has no disadvantages to give the developer optionally the control.

The programmer has all the control they need.  They can open their own pipes using any encoding they like, and they can even reopen stdin/stdout with a different encoding if they wish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:33:40 2013
From: report at bugs.python.org (Ryan Z)
Date: Mon, 09 Dec 2013 13:33:40 +0000
Subject: [issue19937] IDLE can't be launch
Message-ID: <1386596020.76.0.208874282893.issue19937@psf.upfronthosting.co.za>


New submission from Ryan Z:

After I installed a wrong version pygame on OSX 10.9, and may updated something OSX, Then, I can't launch the IDLE, 
It appears on the dock, then quit at the same moment.


bogon:~ RyanZ$ /usr/local/bin/python3.3 -m idlelib
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/idlelib/__main__.py", line 9, in <module>
    idlelib.PyShell.main()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/idlelib/PyShell.py", line 1572, in main
    shell.interp.runcommand(''.join(("print('", tkversionwarning, "')")))
AttributeError: 'NoneType' object has no attribute 'interp'

----------
assignee: ronaldoussoren
components: Macintosh
messages: 205692
nosy: Ryan.Z, ronaldoussoren
priority: normal
severity: normal
status: open
title: IDLE can't be launch
type: compile error
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19937>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:48:16 2013
From: report at bugs.python.org (Sworddragon)
Date: Mon, 09 Dec 2013 13:48:16 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386596896.22.0.0556684025328.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

> If the environment variable is not enough

There is a big difference between environment variables and internal calls: Environment variables are user-space while builtin/library functions are developer-space.


> I have good news for you.  write() does not cal 
> sys.getfilesystemencoding(), because the encoding is set at the time > the file is opened.

Thanks for the clarification. I wished somebody had sayed me that after this sentence in my startpost: "It seems that print() and write() (and maybe other of such I/O functions) are relying on sys.getfilesystemencoding()."


In theory this makes already my ticket invalid. Well, but now I would wish print() would allow to choose the encoding like open() too^^

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 14:55:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 13:55:31 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386597331.92.0.0249630006767.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> There is a big difference between environment variables and internal calls: Environment variables are user-space while builtin/library functions are developer-space.

You can reopen sys.stdout with a different encoding and replace sys.stdout. I don't remember the exact recipe, it's tricky if you want portable code (you have to take care of newline).

For example, I wrote:
http://hg.python.org/cpython/file/ebe28dba4a78/Lib/test/regrtest.py#l895

But you can avoid reopening the file using stdout.detach().

> In theory this makes already my ticket invalid. Well, but now I would wish print() would allow to choose the encoding like open() too^^

Many options were already proposed. Another way, less convinient is to use sys.stdout.buffer.write("text".encode(encoding)) (you have to flush sys.stdout before, and flush the buffer after, to avoid inconsistencies between the TextIOWrapper and the BufferedWriter).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:14:09 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 14:14:09 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386598449.67.0.511634331677.issue19933@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

> I don't understand.  There's already a way to make round return an integer: don't pass a second argument.

If this function were to be written in Python, it would be something like:

    def round(number, ndigits=0):
        ...

or 

    def round(number, ndigits=None):
        ...


But in C you can forge the signature to whatever you want and parse the arguments accordingly. In Python there's always a way to get the default behavior by passing the default argument, but in C it may not exist (in this case `PyObject *o_ndigits = NULL;`)

So, I propose the default value being `None`, so this behavior can be achieved using a second argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:27:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Dec 2013 14:27:41 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386599261.14.0.635943851848.issue19932@psf.upfronthosting.co.za>


Brett Cannon added the comment:

In case no one else sees it, Ziyuan is saying that there should be a space after the PyAPI_FUNC() uses.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:28:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 14:28:26 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386599306.93.0.611016364527.issue19932@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/issue19932>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:40:48 2013
From: report at bugs.python.org (Julian Gindi)
Date: Mon, 09 Dec 2013 14:40:48 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386600048.32.0.750855440763.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Implemented proposed changes to patch. Simplified "for-loop" and implemented invalid input test.

----------
Added file: http://bugs.python.org/file33058/issue18983_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:48:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 14:48:01 +0000
Subject: [issue16638] support multi-line docstring signatures in IDLE calltips
In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za>
Message-ID: <1386600481.44.0.876581542744.issue16638@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is synchronized with tip.

----------
versions:  -Python 3.2
Added file: http://bugs.python.org/file33059/idle_calltips_multiline_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16638>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:49:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 14:49:10 +0000
Subject: [issue16638] support multi-line docstring signatures in IDLE calltips
In-Reply-To: <1354909776.12.0.96265352257.issue16638@psf.upfronthosting.co.za>
Message-ID: <1386600550.23.0.647561927266.issue16638@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file28249/idle_calltips_multiline_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16638>
_______________________________________

From report at bugs.python.org  Mon Dec  9 15:55:18 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 09 Dec 2013 14:55:18 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386600918.07.0.174920229884.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the updated doc fix.

Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

----------
Added file: http://bugs.python.org/file33060/fix_doc_round_ndigits_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:00:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 15:00:28 +0000
Subject: [issue15696] Correct __sizeof__ support for mmap
In-Reply-To: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za>
Message-ID: <1386601228.16.0.398773212418.issue15696@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Synchronized with tip.

----------
nosy: +brian.curtin, tim.golden
versions:  -Python 3.2
Added file: http://bugs.python.org/file33061/mmap_sizeof-3.x_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15696>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:13:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 15:13:07 +0000
Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures
In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za>
Message-ID: <1386601987.78.0.553161873585.issue19681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the status of this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19681>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:17:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 09 Dec 2013 15:17:12 +0000
Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures
In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za>
Message-ID: <1386602232.09.0.861481999904.issue19681@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It still needs a proper fix, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19681>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:25:04 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 15:25:04 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386602704.78.0.239747003867.issue19933@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

> Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

It was the behavior on Python 2.x, but somehow when they changed the rounding method to nearest even number this happened... I think it's too late to change back the return type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:31:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Dec 2013 15:31:59 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386603119.18.0.58856989809.issue19933@psf.upfronthosting.co.za>


R. David Murray added the comment:

Do you have any real-world motivating use case for None?  Not just theoretical consistency with what a Python version of the function would look like.  (I'm not saying we shouldn't consider supporting None as a low priority change, I'm just trying to figure out where you'd ever need it in the real world.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:34:11 2013
From: report at bugs.python.org (Meador Inge)
Date: Mon, 09 Dec 2013 15:34:11 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386603251.51.0.462611674728.issue19915@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:34:57 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Mon, 09 Dec 2013 15:34:57 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386603297.43.0.521945453689.issue19851@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

I tested the patch on the current HEAD and it fixes a regression introduced between 3.3 and 3.4b1 that prevented to build scipy from source with "pip install scipy".

----------
nosy: +Olivier.Grisel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:44:54 2013
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Mon, 09 Dec 2013 15:44:54 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386603894.77.0.509489130649.issue19933@psf.upfronthosting.co.za>


Jo?o Bernardo added the comment:

Not really. Just consistency:

For the same reason  

    ' foo '.strip(None)

works... To avoid special casing the function call when you already have a variable to hold the argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:46:02 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Dec 2013 15:46:02 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <3ddTJn6LMjz7Llp@mail.python.org>


Roundup Robot added the comment:

New changeset 9bce03920afe by Serhiy Storchaka in branch 'default':
Issue #15475: Add __sizeof__ implementations for itertools objects.
http://hg.python.org/cpython/rev/9bce03920afe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15475>
_______________________________________

From report at bugs.python.org  Mon Dec  9 16:58:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 15:58:05 +0000
Subject: [issue15475] Correct __sizeof__ support for itertools
In-Reply-To: <1343418242.58.0.256146467281.issue15475@psf.upfronthosting.co.za>
Message-ID: <1386604685.47.0.0602317208077.issue15475@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/issue15475>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:00:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 16:00:23 +0000
Subject: [issue16055] incorrect error text for int(base=1000, x='1')
In-Reply-To: <1348688461.13.0.427927679227.issue16055@psf.upfronthosting.co.za>
Message-ID: <1386604823.66.0.371445489835.issue16055@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
priority: normal -> low
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16055>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:06:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Dec 2013 16:06:47 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386605207.42.0.601593203606.issue19933@psf.upfronthosting.co.za>


R. David Murray added the comment:

Right, but None in that case has real world utility, since you might have the the value in a variable.  But you are hardly going to hold int-or-not in a variable, especially a variable that is really about the number of places in the float result...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:25:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 16:25:22 +0000
Subject: [issue9645] PEP 383: os.pathconf() does not accept surrogateescape
 arguments
In-Reply-To: <1282243293.83.0.904461489597.issue9645@psf.upfronthosting.co.za>
Message-ID: <1386606322.49.0.617709699728.issue9645@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As 3.2 now in security fixes only mode, this issue has no targets.

----------
resolution:  -> out of date
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9645>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:44:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 16:44:49 +0000
Subject: [issue19681] test_repr (test.test_functools.TestPartialC) failures
In-Reply-To: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za>
Message-ID: <1386607489.1.0.507897690468.issue19681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If you don't like permutation() (which already imported in this file), here is a patch which uses explicit hardcoded permutations.

----------
Added file: http://bugs.python.org/file33062/issue19681_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19681>
_______________________________________

From report at bugs.python.org  Mon Dec  9 17:49:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Dec 2013 16:49:04 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386607744.46.0.963832785713.issue19915@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Should the signature be int.bits_at(start_bit, width) or int.bits_at(start_bit, end_bit+1) ? The latter would look more lire range() and slicing.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:01:45 2013
From: report at bugs.python.org (anon)
Date: Mon, 09 Dec 2013 17:01:45 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386608505.06.0.968669959835.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Antoine, I don't suggest that since you commonly want a fixed number of bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:06:00 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Dec 2013 17:06:00 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386608760.94.0.252127676305.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

@pitrou, I think usability is a lot more valuable than cross-feature "formal consistency" here.  I've been extracting bit fields for decades, and always think of them in terms of "least-significant bit and number of bits".  Perhaps the underlying difference is that nobody ever thinks of bit positions as being _between_ bits - instead we always think of "bit i" as being the bit with binary value 2**i.  It's more of a math concept than an indexing concept.

For a bit _array_ I'd agree slicing semantics would make more sense.  But Python ints have infinite width, and "index 0" is at the rightmost position (not the leftmost position - there is no leftmost position).

I'd also like to avoid the nuisance of having to implement all the goofy slicing possibilities, like non-unit strides and negative strides.  Not that they're "goofy" in general - they're goofy in the context of extracting bits from an integer.  Again a bit array is a different kind of beast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:07:55 2013
From: report at bugs.python.org (anon)
Date: Mon, 09 Dec 2013 17:07:55 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386608875.35.0.511659992211.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Here is my very rough attempt at bits_at. It doesn't handle negative numbers and I am not sure it's safe. This was my first time using Python internals.

Objects/longobject.c:



static PyObject *
long_bits_at(PyLongObject *v, PyObject *args)
{
    PyLongObject *z = NULL;
    
    if(Py_SIZE(v) < 0)
    {
        PyLongObject *a1, *a2;
        Py_RETURN_NOTIMPLEMENTED;
        a1 = (PyLongObject *)long_invert(v);
        //Handle the case where a1 == NULL
        a2 = (PyLongObject *)long_bits_at(a1, args);
        //Handle the case where a2 == NULL
        Py_DECREF(a1);
        Py_DECREF(a2);
        //return a2 ^ ((1 << width) - 1)
    }
    else
    {
        PyObject *at_ = NULL;
        PyObject *width_ = NULL;
        ssize_t at, width, i, j, bitsleft, step;
        ssize_t wordshift, size, newsize, loshift, hishift;
        digit mask;
        
        if (!PyArg_UnpackTuple(args, "bits_at", 1, 2, &at_, &width_))
            return NULL;
        
        at = PyLong_AsSsize_t((PyObject *)at_);
        if (at == -1L && PyErr_Occurred())
            return NULL;
        if (at < 0) {
            PyErr_SetString(PyExc_ValueError, "negative index");
            return NULL;
        }
        
        if (width_ == NULL)
            width = 1;
        else {
            width = PyLong_AsSsize_t((PyObject *)width_);
            if (width == -1L && PyErr_Occurred())
                return NULL;
            if (width < 0) {
                PyErr_SetString(PyExc_ValueError, "negative bit count");
                return NULL;
            }
        }
        
        wordshift = at / PyLong_SHIFT;
        size = ABS(Py_SIZE(v));
        newsize = (width-1) / PyLong_SHIFT + 1;
        if (newsize > size-wordshift)
            newsize = size-wordshift;
        if (newsize <= 0)
            return PyLong_FromLong(0L);
        
        loshift = at % PyLong_SHIFT;
        hishift = PyLong_SHIFT - loshift;
        bitsleft = width;
        z = _PyLong_New(newsize);
        if (z == NULL)
            return NULL;
        
        for (i = 0, j = wordshift; i < newsize; i++, j++) {
            step = bitsleft<hishift ? bitsleft : hishift;
            mask = ((digit)1 << step) - 1;
            z->ob_digit[i] = (v->ob_digit[j] >> loshift) & mask;
            bitsleft -= step;
            
            if (j+1 < size) {
                step = bitsleft<loshift ? bitsleft : loshift;
                mask = ((digit)1 << step) - 1;
                z->ob_digit[i] |= ((v->ob_digit[j+1] & mask) << hishift);
                bitsleft -= step;
            }
        }
        z = long_normalize(z);
    }
    
    return (PyObject *)z;
}

PyDoc_STRVAR(long_bits_at_doc,
"int.bits_at(pos, width=1) -> int\n\
\n\
Equivalent to (int >> pos) & ((1 << width) - 1).");

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:09:39 2013
From: report at bugs.python.org (anon)
Date: Mon, 09 Dec 2013 17:09:39 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386608979.83.0.779765603572.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Here are some inadequate tests to add to Lib/test/test_long.py



    def test_bits_at(self):
        def bits_at(n, pos, width=1):
            return (n>>pos) & ((1 << width) - 1)
        for n in [123, 7777777, (1<<35)|(1<<30)|(1<<25)]:
            for i in range(50):
                for j in range(20):
                    self.assertEqual(n.bits_at(i, j), bits_at(n, i, j))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:12:56 2013
From: report at bugs.python.org (anon)
Date: Mon, 09 Dec 2013 17:12:56 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386609176.62.0.364134276492.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Both segments of code are public domain. It would be great if someone could review them, improve them and produce a proper patch. I didn't handle the negative case, which I hope someone else can add.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:25:48 2013
From: report at bugs.python.org (anon)
Date: Mon, 09 Dec 2013 17:25:48 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386609948.45.0.171834474333.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Some of the code may be under Python's license though. So I should clarify that only MY parts of the two samples of code are public domain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:43:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 17:43:01 +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: <1386610981.54.0.146287432895.issue4945@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue19795 which contains much larger patch for other modules.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:52:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 17:52:31 +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: <1386611551.53.0.95428639742.issue4945@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated to tip.

----------
nosy: +georg.brandl
Added file: http://bugs.python.org/file33063/json_doc_truefalse_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4945>
_______________________________________

From report at bugs.python.org  Mon Dec  9 18:58:29 2013
From: report at bugs.python.org (Julian Gindi)
Date: Mon, 09 Dec 2013 17:58:29 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386611909.39.0.543578335885.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Incorporated updates suggested by serhiy.storchaka

----------
Added file: http://bugs.python.org/file33064/issue18983_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:05:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 18:05:08 +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: <1386612308.53.0.140292023083.issue17200@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +neologix
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:07:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 18:07:01 +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: <1386612421.75.0.407211144112.issue17200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is not compatible with 3.4. Does this bug exist in 3.4?

----------
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:11:55 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 Dec 2013 18:11:55 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1386612421.75.0.407211144112.issue17200@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3u17ddDir3OySPVZUfjQgHW+JJQNpvj4jN=ZEP0kFCgw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> The patch is not compatible with 3.4. Does this bug exist in 3.4?

No, selectors all expect a timeout in seconds, so this should be fixed in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:21:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 18:21:53 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386613313.27.0.848062900571.issue18983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It will be better to write error message to sys.stderr (see test_main_exception).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:22:46 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2013 18:22:46 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386613366.73.0.848067929507.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Sadly, the optimistic code doesn't work on Windows.  I think it may be because the socketpair() helper at the top of test_selectors.py uses an extra socket ('l') and the handles just don't match up (I get a failure on assert wr2.fileno() == w).  So I propose to stick with the current solution of skipping the test on Windows.

I'll close this bug in 24 hours unless I get a response sooner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:23:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 18:23:01 +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: <1386613381.0.0.863443093034.issue17200@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/issue17200>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:24:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Dec 2013 18:24:58 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386613498.89.0.728788852701.issue19876@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The current test using os.dup2() with a skip on Windows is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:28:31 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 Dec 2013 18:28:31 +0000
Subject: [issue19876] selectors (and asyncio?): document behaviour on closed
 files/sockets
In-Reply-To: <1386079879.4.0.237775070253.issue19876@psf.upfronthosting.co.za>
Message-ID: <1386613711.14.0.0713252301896.issue19876@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19876>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:50:38 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Mon, 09 Dec 2013 18:50:38 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386615038.62.0.477150221488.issue19846@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

Ahh... added to the nosy list and bug closed all before I got up for the day ;-)

A few words:

I do think that python is broken here.

I do not think that translating everything to utf-8 if ascii is the locale's encoding is the solution.

As I would state it, the problem is that python's boundary with the OS is not yet uniform.  If you set LC_ALL=C (note, LC_ALL=C is just one of multiple ways to beak things.  For instance, LC_ALL=en_US.utf8 when dealing with latin-1 data will also break) then python will still *read* non-ascii data from the OS through some interfaces but it won't output it back to the OS.  ie:

$ mkdir unicode && cd unicode
$ python3 -c 'open("?.txt".encode("latin-1"), "w").close()'
$ LC_ALL=en_US.utf8 python3
>>> import os
>>> dir_listing = os.listdir('.')
>>> for entry in dir_listing: print(entry)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcf1' in position 0: surrogates not allowed

Note that currently, input() and sys.stdin.read() won't read undecodable data so this is somewhat symmetrical but it seems to me that saying "everything that interfaces with the OS except the standard streams will use surrogateescape on undecodable bytes" is drawing a line in an unintuitive location.

(A further note to serhiy.storchaka.... Your examples are not showing anything broken in other programs.  xterm is refusing both input and output that is non-ascii.  This is symmetric behaviour.  ls is doing its best to display a *human-readable* representation of bytes that it cannot convert in the current encoding.  It also provides the -b switch to see the octal values if you actually care.  Think of this like opening a binary file in less or another pager.)

(Further note for haypo -- On Fedora, the default of en_US is utf8, not ISO8859-1.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 19:50:51 2013
From: report at bugs.python.org (Derek Wilson)
Date: Mon, 09 Dec 2013 18:50:51 +0000
Subject: [issue18616] enable more ssl socket options with
 get_server_certificate
In-Reply-To: <1375372562.92.0.356754094449.issue18616@psf.upfronthosting.co.za>
Message-ID: <1386615051.72.0.287561815275.issue18616@psf.upfronthosting.co.za>


Derek Wilson added the comment:

any thoughts on this? there's a lot of room for improvement in python ssl...

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18616>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:07:00 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 19:07:00 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386616020.33.0.589382546901.issue19933@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Anyway, why not round(1.2) -> 1.0 in the first place? Just curious.

All this changed as part of PEP 3141.  I wasn't watching Python 3 development closely back then, but I *think* at least part of the motivation was to provide a way to get away from the use of `int` to truncate a float to its integer part:  the argument goes that a simple type conversion shouldn't throw away information, and that if you want a transformation from float to int that throws away information you should ask for it explicitly.  So `math.trunc` was born as the preferred way to truncate a float to an int, and `math.floor`, `math.ceil` and `round` became alternative float -> int conversion methods.  That entailed those functions returning ints.

<off-topic> In the case of `math.floor` and `math.ceil` at least, I think this is regrettable.  There are plenty of places where you just want a float -> float floor or ceiling, and Python no longer has a cheap operation for that available:  floor as a float-to-float operation is cheap;  floor as a float-to-long-integer operation is significantly more costly.

In the case of `round`, we still have `round(x, 0)` available as a cheap float->float conversion, so it's less of a problem.  And I hardly ever use `trunc`, so I don't care about that case. </off-topic>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:09:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 19:09:53 +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: <1386616193.12.0.131521203352.issue17200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Last patch is corrupted and outdated. Here is updated and fixed version. I have not examined it closely.

----------
Added file: http://bugs.python.org/file33065/issue17200.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:24:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 19:24:33 +0000
Subject: [issue18010] pydoc search chokes on import errors
In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za>
Message-ID: <1386617073.88.0.189043157939.issue18010@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/issue18010>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:28:47 2013
From: report at bugs.python.org (Julian Gindi)
Date: Mon, 09 Dec 2013 19:28:47 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386617327.27.0.749957643061.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Updated patch to log to stderr.

----------
Added file: http://bugs.python.org/file33066/issue18983_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:29:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 19:29:09 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1386617349.62.0.367412606046.issue19481@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Pickling for the RPC protocol between the GUI process and the interpreter subprocess, which would explain why there is no problem when running idle -n (no subproces)?

Yes, it is.

If there are no objections I'll commit these patches.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19481>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:30:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 19:30:09 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386617409.08.0.729346307236.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:35:15 2013
From: report at bugs.python.org (Derek Wilson)
Date: Mon, 09 Dec 2013 19:35:15 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1386617715.35.0.435951615338.issue18233@psf.upfronthosting.co.za>


Derek Wilson added the comment:

I could really use this sooner than later... and sometimes having a full-featured (or even secure) interface is not what you want.

Consider zmap and masscan etc and ssl mapping (similar to what the EFF did a couple years back - https://www.eff.org/observatory - but with the full chain instead of just the cert). The desire here would be low level, low overhead, no validation on the fly: All you want is the cert chain.

There are plenty of research and security applications where a simple wrapper around OpenSSL that returns DER bytes would be desirable. Please reconsider this patch for inclusion in 3.4 ...

----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:42:24 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 Dec 2013 19:42:24 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386618144.26.0.742313745926.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Ping.

Bah.  Sorry; I haven't had time to deal with this.  Serhiy: are you interested in taking over?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 20:54:37 2013
From: report at bugs.python.org (Julian Gindi)
Date: Mon, 09 Dec 2013 19:54:37 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386618877.36.0.318425116184.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Added newline after error message.

----------
Added file: http://bugs.python.org/file33067/issue18983_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 21:12:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Dec 2013 20:12:52 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386619972.3.0.814767680687.issue18983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is doubled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 21:14:26 2013
From: report at bugs.python.org (Julian Gindi)
Date: Mon, 09 Dec 2013 20:14:26 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386620066.94.0.336196002049.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Whoops. Sorry about that. Super embarrassing.

----------
Added file: http://bugs.python.org/file33068/issue18983_v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec  9 21:33:01 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Dec 2013 20:33:01 +0000
Subject: [issue19937] IDLE can't be launched
In-Reply-To: <1386596020.76.0.208874282893.issue19937@psf.upfronthosting.co.za>
Message-ID: <1386621181.29.0.897530595929.issue19937@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is a duplicate of 18270.  As explained there, the workaround is to follow the instructions at http://www.python.org/download/mac/tcltk/ and, if possible, install an up-to-date Tcl/Tk 8.5 from ActiveState.  If that is not possible, then launch IDLE from the command line with an initial shell window:

/usr/local/bin/python3.3 -m idlelib -i

and be sure to change the preference to always launch with a shell window.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE on OS X fails with Attribute Error if no initial shell and Tk out-of-date
title: IDLE can't be launch -> IDLE can't be launched
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19937>
_______________________________________

From report at bugs.python.org  Mon Dec  9 22:10:40 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2013 21:10:40 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1386623440.74.0.575446896244.issue19481@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> [2.7] print() implicitly converts str and bytearray subclasses to str and left unicode subclasses as is.

This strikes me as possibly a bug in print, but even if that were changed, there is still the issue of sys.stdout.write and pickle. While the patch is a great improvement, it changes the behavior of sys.stdout.write(s), which acts like it calls str.__str__(s) rather than str(s) == s.__str__

---
class S(str):
    def __str__(self):
        return 'S: ' + str.__str__(self)

s = S('foo')
print(s, str(s), str.__str__(s))

import sys
sys.stdout.write(s)
---
S: foo S: foo foo
foo

on the console (hang after first line on Idle)

I am testing the patch with str(s) changed to str.__str__(s).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19481>
_______________________________________

From report at bugs.python.org  Mon Dec  9 22:29:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Dec 2013 21:29:50 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1386624590.6.0.234962245213.issue19481@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Confirmed that the revised patch for 3.3 fixes the hang and matches the console interpreter output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19481>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:04:38 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Dec 2013 22:04:38 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386626678.58.0.231378603399.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

@anon, sorry, but we can't accept any code from you unless you have a real name and fill out a contributor agreement:

   http://www.python.org/psf/contrib/

This is legal crud, and I'm not a lawyer.  But, in particular, lawyers have told me that - in the USA - an individual cannot meaningfully put anything in "the public domain".  That's what I used to do - until a lawyer strongly advised me to stop that and use an actual license.

In any case, it's most likely that Python developers won't even look at your code in the absence of a contributor agreement.  If we did, the slight chance of Bad Consequences (e.g., someone we only knew as "anon" sues us for stealing their ideas) outweighs the slight benefit we might get from stealing your ideas ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:27:55 2013
From: report at bugs.python.org (HCT)
Date: Mon, 09 Dec 2013 22:27:55 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386628075.3.0.793599888988.issue19915@psf.upfronthosting.co.za>


HCT added the comment:

> I think slicing semantically "seems wrong" but it might be more elegant. It might also make catching errors harder (in the case where an int is sent to a function that does slicing and now won't fail with a TypeError).

not sure what's semantically "seems wrong" with it. not sure why TypeError or any other error catching should come into play for this.

calling a function is way more expensive than doing bit shift and/or AND operation. as a function, you've only hide your code into Python binaries at the expense of performance

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:31:35 2013
From: report at bugs.python.org (HCT)
Date: Mon, 09 Dec 2013 22:31:35 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1386628295.49.0.904976216411.issue9951@psf.upfronthosting.co.za>


HCT added the comment:

would be good if we can specify a optional flag to get all cap hex. currently, I have to do hexlify( some_bytes ).decode( 'UTF-8' ).upper(). would be good to be able to do some_bytes.hex( upper=1 )

----------
nosy: +hct

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:40:19 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 09 Dec 2013 22:40:19 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386628819.38.0.960172055635.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

@HCT, see http://bugs.python.org/issue19915#msg205713 for what's "semantically wrong".  Ints are not arrays - slicing is unnatural.

The point about error checking is that if this were supported via slicing notation, then the _helpful_ exceptions of the form, e.g.,

    TypeError: 'int' object has no attribute '__getitem__'

would no longer occur for code like

    myarray[1:12]

where `myarray` is mistakenly bound to an integer.  We always lose something when assigning a meaning to an operation that formerly raised an exception.

About:

> calling a function is way more expensive than doing
> bit shift and/or AND operation

read the very first message in this issue.  There is no upper bound on how expensive bit shifts and logical operations can be on Python integers:  they can take time proportional to the number of bits.  But a function to extract a bit can be written internally to require small constant time, independent of the number of bits in the integer.  At least that's true for CPython ints >= 0; it may well take longer for negative CPython ints in some cases.

If speed on small ints is your primary concern, by all means continue to fiddle the bits by hand ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:44:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 22:44:38 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1386595244.49.0.635528703671.issue18576@psf.upfronthosting.co.za>
Message-ID: <CADiSq7f1c3HoOYtqLE8X0TEaMk94WgoLB1ZzrL4e-=fGBSfvhA@mail.gmail.com>


Nick Coghlan added the comment:

Note that the test.* namespace has long been declared as unstable, so we
don't worry about breaking third party code when rearranging the test suite
(as far as I am aware, most Linux distros don't even include the test suite
in their Python packages).

I'll see how Mercurial goes tracking the file move when the alias is left
behind, and decide which way to do the initial change based on whether or
not the alias breaks the history tracking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:50:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 22:50:02 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1386585736.77.0.335520394132.issue19846@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dwa=QfcRUcQQtHoNM1uFfc7MdA0t7MQOxs94swdXeHEg@mail.gmail.com>


Nick Coghlan added the comment:

There's a wrong assumption here: glib applications on Linux use UTF-8
regardless of locale. That's the part I have a problem with: the assumption
that the locale will correctly specify the encoding to use for OS APIs on
modern Linux systems.

It's simply not always true: some Linux distros would be better handled
like OS X, where we always use UTF-8, regardless of what the locale says.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Mon Dec  9 23:57:01 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 09 Dec 2013 22:57:01 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386629821.84.0.88785940413.issue19846@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Nick: which glib functions are you specifically referring to? Many of them don't deal with strings at all, and of those that do, many are encoding-agnostic (i.e. it is correct to claim that they operate on UTF-8, but likewise also correct that they operate on Latin-1, simultaneously).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:00:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Dec 2013 23:00:17 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <CADiSq7dwa=QfcRUcQQtHoNM1uFfc7MdA0t7MQOxs94swdXeHEg@mail.gmail.com>
Message-ID: <1386630013.2305.5.camel@fsol>


Antoine Pitrou added the comment:

> It's simply not always true: some Linux distros would be better handled
> like OS X, where we always use UTF-8, regardless of what the locale says.

Perhaps by the 3.5 timeframe we can default to utf-8 on all Unix
systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:06:36 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Dec 2013 23:06:36 +0000
Subject: [issue19938] Re-enable test_bug_1333982 on 3.x
Message-ID: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Here's a pair of patches which re-enable test_bug_1333982 in test_dis on 3.3 and 3.4; the major changes in 3.4 necessitate separate patches.  The patches also replace test_main with unittest.main which made trying to get the test to work much less annoying.

----------
components: Tests
files: test_dis_1333982-3.3.diff
keywords: patch
messages: 205750
nosy: ncoghlan, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Re-enable test_bug_1333982 on 3.x
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33069/test_dis_1333982-3.3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19938>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:06:51 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 09 Dec 2013 23:06:51 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1386629821.84.0.88785940413.issue19846@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fgZRwTADYwxJZGv-_8LHofuecOczaj6TQBWOYZvdrCdA@mail.gmail.com>


Nick Coghlan added the comment:

I confess I didn't independently verify the glib claim in the Stack
Overflow post.

However, Toshio's post covers the specific error case we were discussing at
Flock (and I had misremembered), where the standard streams are classed as
"OS APIs" for the purpose of deciding which encoding to use, but as user
data APIs for the purpose of deciding which error handler to use. So the
standard streams are only "sort of" an OS API, since they don't participate
in the surrogateescape based round tripping guarantee by default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:06:52 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Dec 2013 23:06:52 +0000
Subject: [issue19938] Re-enable test_bug_1333982 on 3.x
In-Reply-To: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>
Message-ID: <1386630412.1.0.624143804328.issue19938@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file33070/test_dis_1333982-3.4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19938>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:13:41 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Dec 2013 23:13:41 +0000
Subject: [issue19928] Implement cell repr test
In-Reply-To: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>
Message-ID: <1386630821.76.0.83030200093.issue19928@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Left a comment on Rietveld; mostly LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19928>
_______________________________________

From report at bugs.python.org  Tue Dec 10 00:55:45 2013
From: report at bugs.python.org (Ziyuan Lin)
Date: Mon, 09 Dec 2013 23:55:45 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386633345.07.0.377239673194.issue19932@psf.upfronthosting.co.za>


Ziyuan Lin added the comment:

Yes, although I left out the space after the third PyAPI_FUNC().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:21:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 00:21:26 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <3ddhlT4NDNz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 7b077c691fef by Victor Stinner in branch '3.3':
Issue #19932: Fix typo in import.h, missing whitespaces in function prototypes.
http://hg.python.org/cpython/rev/7b077c691fef

New changeset e017cd46009a by Victor Stinner in branch 'default':
(Merge 3.3) Issue #19932: Fix typo in import.h, missing whitespaces in function prototypes.
http://hg.python.org/cpython/rev/e017cd46009a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:22:52 2013
From: report at bugs.python.org (Nikolay Bogoychev)
Date: Tue, 10 Dec 2013 00:22:52 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <1386634972.01.0.759679679276.issue16099@psf.upfronthosting.co.za>


Nikolay Bogoychev added the comment:

Thank you for the review!
I have addressed your comments and release a v2 of the patch:
Highlights:
 No longer crashes when provided with malformed crawl-delay/robots.txt parameter.
 Returns None when parameter is missing or syntax is invalid.
 Simplified several functions.
 Extended tests.

http://bugs.python.org/review/16099/diff/6206/Doc/library/urllib.robotparser.rst
File Doc/library/urllib.robotparser.rst (right):

http://bugs.python.org/review/16099/diff/6206/Doc/library/urllib.robotparser....
Doc/library/urllib.robotparser.rst:56: .. method:: crawl_delay(useragent)
On 2013/12/09 03:30:54, berkerpeksag wrote:
> Is crawl_delay used for search engines? Google recommends you to set crawl speed
> via Google Webmaster Tools instead.
> 
> See https://support.google.com/webmasters/answer/48620?hl=en.
 
Crawl delay and request rate parameters are targeted to custom crawlers that many people/companies write for specific tasks. The Google webmaster tools is targeted only to google's crawler and typically web admins have different rates for google/yahoo/bing and all other user agents.

http://bugs.python.org/review/16099/diff/6206/Lib/urllib/robotparser.py
File Lib/urllib/robotparser.py (right):

http://bugs.python.org/review/16099/diff/6206/Lib/urllib/robotparser.py#newco...
Lib/urllib/robotparser.py:168: for entry in self.entries:
On 2013/12/09 03:30:54, berkerpeksag wrote:
> Is there a better way to calculate this? (perhaps O(1)?)

I have followed the model of what was written beforehand. A 0(1) implementation (probably based on dictionaries) would require a complete rewrite of this library, as all previously implemented functions employ the:
for entry in self.entries:
    if entry.applies_to(useragent):

logic. I don't think this matters particularly here, as those two functions in particular need only be called once per domain and robots.txt seldom contains more than 3 entries. This is why I have just followed the design laid out by the original developer.

Thanks

Nick

----------
Added file: http://bugs.python.org/file33071/robotparser_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16099>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:24:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 00:24:04 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <3ddhpX007Bz7LkC@mail.python.org>


Roundup Robot added the comment:

New changeset eb1039fe090c by Victor Stinner in branch '2.7':
Issue #19932: Fix typo in import.h, missing whitespaces in function prototypes.
http://hg.python.org/cpython/rev/eb1039fe090c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:24:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 00:24:13 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386635053.71.0.674744744738.issue19932@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Ziyuan Lin: The issue should now be fixed, can you please confirm?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:29:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 00:29:54 +0000
Subject: [issue14621] Hash function is not randomized properly
In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za>
Message-ID: <1386635394.05.0.984851308278.issue14621@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This issue has belatedly had a CVE assigned: CVE-2013-7040 ("CPython hash secret can be recovered remotely")

3.4 is not affected (due to PEP 456), but 3.3 and 2.7 are still affected.

----------
nosy: +bkabrda
status: pending -> open
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14621>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:34:45 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 10 Dec 2013 00:34:45 +0000
Subject: [issue14621] Hash function is not randomized properly
In-Reply-To: <1334858289.64.0.441945117447.issue14621@psf.upfronthosting.co.za>
Message-ID: <1386635685.21.0.813699607344.issue14621@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think that's just WONTFIX at this point.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14621>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:39:16 2013
From: report at bugs.python.org (anon)
Date: Tue, 10 Dec 2013 00:39:16 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386635956.98.0.731682704252.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Tim, I'm sorry to hear you can't accept my patch. I am afraid I want to stay anonymous.

You have my word that I wrote the two code segments above (based on code already in CPython) and that I put them in the public domain. But I appreciate that the word of `anon` may be worth nothing to you. For what it is worth I could have used a fake name anyway.

If you can't accept them, may I request someone else implement the proposal? This may be for the best anyway since I am unfamiliar with CPython internals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:41:57 2013
From: report at bugs.python.org (Nikolay Bogoychev)
Date: Tue, 10 Dec 2013 00:41:57 +0000
Subject: [issue16099] robotparser doesn't support request rate and crawl delay
 parameters
In-Reply-To: <1349096305.17.0.983395980337.issue16099@psf.upfronthosting.co.za>
Message-ID: <1386636117.9.0.887558558895.issue16099@psf.upfronthosting.co.za>


Nikolay Bogoychev added the comment:

Oh... Sorry for the spam, could you please verify my documentation link syntax. I'm not entirely sure I got it right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16099>
_______________________________________

From report at bugs.python.org  Tue Dec 10 01:55:49 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 10 Dec 2013 00:55:49 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386636949.62.0.0569942666587.issue19915@psf.upfronthosting.co.za>


Tim Peters added the comment:

@anon, not to worry:  someone else will write the code.  Maybe even me ;-)

BTW, "public domain" is not a license.  It's the absence of a license.  Our lawyers would not accept that even if you had a real name ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:14:29 2013
From: report at bugs.python.org (Fil Mackay)
Date: Tue, 10 Dec 2013 01:14:29 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386638069.18.0.275990466564.issue19904@psf.upfronthosting.co.za>


Fil Mackay added the comment:

So where do we go from here - is there enough support for this to proceed, or vote the idea off the island :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:35:39 2013
From: report at bugs.python.org (Ziyuan Lin)
Date: Tue, 10 Dec 2013 01:35:39 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386639339.28.0.599363219047.issue19932@psf.upfronthosting.co.za>


Ziyuan Lin added the comment:

I can't build the cpython with Visual Studio 2012 because of the following errors:


"D:\Repository\cpython\PCbuild\pcbuild.sln" (default target) (1) ->
"D:\Repository\cpython\PCbuild\_msi.vcxproj" (default target) (13) ->
(Link target) ->
  LINK : fatal error LNK1181: cannot open input file 'fci.lib' [D:\Repository\cpython\PCbuild\_ msi.vcxproj]

"D:\Repository\cpython\PCbuild\pcbuild.sln" (default target) (1) ->
"D:\Repository\cpython\PCbuild\_ssl.vcxproj" (default target) (17) ->
"D:\Repository\cpython\PCbuild\ssl.vcxproj" (default target) (18) ->
(Build target) ->
  C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.MakeFile.Targets(38,5): error MSB3073:
 The command "cd "D:\Repository\cpython\PCbuild\" [D:\Repository\cpython\PCbuild\ssl. vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.MakeFile.Targets(38,5): error MSB3073: " D:\Repository\cpython\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a [D:\Rep ository\cpython\PCbuild\ssl.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.MakeFile.Targets(38,5): error MSB3073: "
 exited with code 1. [D:\Repository\cpython\PCbuild\ssl.vcxproj]


Anyway, I replaced Python33/Include/import.h with cpython/Include/import.h directly, and it works well with my sample code. Thank you.


By the way, here's a discussion about the "fci.lib" issue, which suggests replacing fci.lib with cabinet.lib: http://social.msdn.microsoft.com/Forums/vstudio/en-US/3b85f36e-dffe-4589-adc3-13673b349812/missing-fcilib-in-windows-sdk-80?forum=vcgeneral

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:40:40 2013
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 Dec 2013 01:40:40 +0000
Subject: [issue6143] IDLE - an extension to clear the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1386639640.33.0.116119462245.issue6143@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/issue6143>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:43:26 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 10 Dec 2013 01:43:26 +0000
Subject: [issue19904] Add 128-bit integer support to struct
In-Reply-To: <1386295463.1.0.439245102985.issue19904@psf.upfronthosting.co.za>
Message-ID: <1386639806.21.0.173820513467.issue19904@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Pick two suitable letters for the int128 and uint128 cases and create a patch for an implementation with tests (targeting Python 3.5).  The implementation needs to compile and work even when the platform C compiler Python is compiled with does not have a 128-bit integer type (so the struct module always supports this rather than depending upon the platform native support in C).

I wouldn't bother with 256 and 512 bit integer support because I've never seen those used.  If that changes before 3.5 is released (a couple years), they can be added.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19904>
_______________________________________

From report at bugs.python.org  Tue Dec 10 02:55:54 2013
From: report at bugs.python.org (HCT)
Date: Tue, 10 Dec 2013 01:55:54 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386640554.02.0.339108111122.issue19914@psf.upfronthosting.co.za>


HCT added the comment:

verified issue is due to code page was set to 65001, but I set PYTHONIOENCODING to utf-8 (tried UTF-8, utf8, utf-8...etc), so I'm not sure why there is problem with code page 65001

setting code page back to ascii (non-Unicode) fixed the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:05:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 03:05:31 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <3ddmNp3ylBz7Ljq@mail.python.org>


Roundup Robot added the comment:

New changeset 1d67eb1df5a9 by Eric Snow in branch 'default':
Issue 19851: Fix a regression in reloading submodules.
http://hg.python.org/cpython/rev/1d67eb1df5a9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:14:04 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Dec 2013 03:14:04 +0000
Subject: [issue19851] reload problem with submodule
In-Reply-To: <1385907094.98.0.564664253092.issue19851@psf.upfronthosting.co.za>
Message-ID: <1386645244.82.0.350078078436.issue19851@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19851>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:16:23 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Dec 2013 03:16:23 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386645383.65.0.522673602014.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

Good point, Nick.  Here's a patch that follows your recommendation on both points.

----------
Added file: http://bugs.python.org/file33072/issue19927-loader-eq.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:16:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Dec 2013 03:16:39 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1386645399.62.0.741207570818.issue19927@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file33038/issue19927-loader-eq.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Tue Dec 10 04:29:54 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Dec 2013 03:29:54 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386646194.56.0.707076144142.issue18864@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a patch for adding a setter for ModuleSpec.has_location.

----------
Added file: http://bugs.python.org/file33073/issue18864-has-location-setter.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Tue Dec 10 05:42:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Dec 2013 04:42:34 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386650554.86.0.291083993428.issue19933@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

In case we want to add consistency with None ndigits, here is the patch adding support for None value for ndigits parameter.

This one looks like a low-risk addition but since Python 3.4 is in beta phase....

----------
Added file: http://bugs.python.org/file33074/fix_doc_ndigits_round_and_add_None_ndigits.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Tue Dec 10 06:54:41 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 Dec 2013 05:54:41 +0000
Subject: [issue19939] Deprecate portions or all of pkgutil module.
Message-ID: <1386654881.95.0.820542970377.issue19939@psf.upfronthosting.co.za>


New submission from Eric Snow:

In the last Python releases, particularly 3.3 and 3.4, we've made improvements to the import machinery that render (at least) portions of pkgutil obsolete.  Here's a breakdown of the public API of pkgutil:

get_importer() - duplicate of PathFinder._path_importer_cache()
iter_importers() - yields the path entry finder for each path entry
find_loader() - a parent-importing wrapper around (deprecated) importlib.find_loader()
get_loader() - looks at module.__loader__ or calls find_loader()
walk_packages() - loader-focused
iter_modules() - loader-focused
get_data() - a wrapper around the InspectLoader.get_data() API
read_code() - duplicates importlib functionality
extend_path() - no longer needed (namespace packages)
ImpImporter - already deprecated in favor of importlib
ImpLoader - already deprecated in favor of importlib

I would expect that nearly all of the module could be deprecated and any gaps in functionality ported to importlib.util.

Is it worth it to go to the effort?  To me the biggest thing would be identifying what functionality (e.g. locating all packages within a directory) in pkgutil is still relevant and should be distilled into public APIs in importlib.  The job of actually deprecating and porting code would mostly be mechanical and not even a large amount of work.

----------
components: Library (Lib)
messages: 205771
nosy: brett.cannon, eric.snow, ncoghlan, pje
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecate portions or all of pkgutil module.
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19939>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:08:45 2013
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 10 Dec 2013 07:08:45 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386659325.72.0.313292500541.issue19846@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

>From what I read, it appears that the SO posting is plain wrong. Consider, for example,

https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-filename-to-utf8

# Converts a string which is in the encoding used by GLib for filenames 
# into a UTF-8 string. Note that on Windows GLib uses UTF-8 for filenames; 
# on other platforms, this function indirectly depends on the current locale.

The SO author might have misread the part where it says that glib uses UTF-8 *on Windows* (instead of the braindead "ANSI" encoding indirection).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:21:27 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Dec 2013 07:21:27 +0000
Subject: [issue17762] platform.linux_distribution() should honor
 /etc/os-release
In-Reply-To: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za>
Message-ID: <1386660087.13.0.105568210234.issue17762@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

This patch needs to be updated to tip since this commit: http://hg.python.org/cpython/rev/4580976c07cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:29:12 2013
From: report at bugs.python.org (akira)
Date: Tue, 10 Dec 2013 07:29:12 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
Message-ID: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>


New submission from akira:

cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead.

Example from the docs [2] is seven hours off (it shows utc offset of the local timezone of the person who created it):

    >>> import ssl
    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
    1178694000.0

It should be `1178668800`:

    >>> from datetime import datetime
    >>> datetime.utcfromtimestamp(1178668800)
    datetime.datetime(2007, 5, 9, 0, 0)
    >>> import time
    >>> time.gmtime(1178668800)
    time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)


And `calendar.timegm` returns correct result:

    >>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))
    1178668800

[1]: http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849
[2]: http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 205774
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: ssl.cert_time_to_seconds() returns wrong results if local timezone is not UTC
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/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:31:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 07:31:26 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386660686.94.0.783475948254.issue19914@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Windows
nosy: +brian.curtin, haypo, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:44:30 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Dec 2013 07:44:30 +0000
Subject: [issue19939] Deprecate portions or all of pkgutil module.
In-Reply-To: <1386654881.95.0.820542970377.issue19939@psf.upfronthosting.co.za>
Message-ID: <1386661470.53.0.394589498749.issue19939@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/issue19939>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:47:52 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Dec 2013 07:47:52 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1386661672.78.0.414989949497.issue9951@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/issue9951>
_______________________________________

From report at bugs.python.org  Tue Dec 10 08:59:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 07:59:36 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1386662376.6.0.672540049353.issue19481@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good suggestion Terry. And for unicode in 2.7 we can use unicode.__getslice__(s, None, None) (because there is no unicode.__unicode__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19481>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:07:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 08:07:28 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <3ddv5C4tggz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset df9596ca838c by Serhiy Storchaka in branch '2.7':
Issue #19481: print() of unicode, str or bytearray subclass instance in IDLE
http://hg.python.org/cpython/rev/df9596ca838c

New changeset d462b2bf875b by Serhiy Storchaka in branch '3.3':
Issue #19481: print() of string subclass instance in IDLE no more hangs.
http://hg.python.org/cpython/rev/d462b2bf875b

New changeset 1d68ea8148ce by Serhiy Storchaka in branch 'default':
Issue #19481: print() of string subclass instance in IDLE no more hangs.
http://hg.python.org/cpython/rev/1d68ea8148ce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19481>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:25:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 08:25:59 +0000
Subject: [issue19928] Implement cell repr test
In-Reply-To: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>
Message-ID: <3ddvVb01fLz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset d98c5806c33c by Serhiy Storchaka in branch '2.7':
Issue #19928: Implemented a test for repr() of cell objects.
http://hg.python.org/cpython/rev/d98c5806c33c

New changeset 49eb895be796 by Serhiy Storchaka in branch '3.3':
Issue #19928: Implemented a test for repr() of cell objects.
http://hg.python.org/cpython/rev/49eb895be796

New changeset af9f3d737d4a by Serhiy Storchaka in branch 'default':
Issue #19928: Implemented a test for repr() of cell objects.
http://hg.python.org/cpython/rev/af9f3d737d4a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19928>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:27:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 08:27:35 +0000
Subject: [issue19928] Implement cell repr test
In-Reply-To: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>
Message-ID: <1386664055.16.0.315923414683.issue19928@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/issue19928>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:34:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 08:34:56 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1386664496.39.0.443990160756.issue19481@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/issue19481>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:39:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 08:39:14 +0000
Subject: [issue19939] Deprecate portions or all of pkgutil module.
In-Reply-To: <1386654881.95.0.820542970377.issue19939@psf.upfronthosting.co.za>
Message-ID: <1386664754.89.0.888462594113.issue19939@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Programmatic deprecation definitely isn't worth it - setuptools et al need this for cross-version compatibility with 2.x, and packaging tools are hard enough to write without us programatically deprecating things in 3.x releases.

Explicit documented deprecations where appropriate would be good, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19939>
_______________________________________

From report at bugs.python.org  Tue Dec 10 09:58:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Dec 2013 08:58:46 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386665926.05.0.548812691022.issue19717@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Thanks for the review, Antoine! Here is the updated patch. I haven't tested it on Windows yet because I want to clarify one thing.

Let's say we have this valid directory:

/tmp/@test123 <= directory

And this directory only has one valid file:

/tmp/@test123/cutecat <= file

We agree that pathlib.Path('/tmp/@test123/foo').resolve(False) => '/tmp/@test123/foo'.

But what about this case: pathlib.Path('/tmp/@test123/cutecat/foo').resolve(False)?

It should be "/tmp/@test123/cutecat" or "/tmp/@test123/cutecat/foo"?

----------
Added file: http://bugs.python.org/file33075/add_non_strict_resolve_pathlib_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:24:29 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 10 Dec 2013 09:24:29 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386667469.89.0.197190410658.issue19914@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I can confirm that code page 65001 is the problem using 3.3.3 on Windows 7.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Tue Dec 10 10:31:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 10 Dec 2013 09:31:44 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1386667904.58.0.172220311768.issue18996@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Hello, Serhiy. Do you want to remove this debug messaging?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:32:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 10:32:12 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386671532.89.0.262353049287.issue19914@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like the issue comes from the "more" system command, used as a pager for the documentation. When the OEM code page is set to 65001 (ex: type "chcp 65001" in a Windows console), "more document.txt" does nothing (display nothing and exit).

Try commamands:
---
more document.txt
# works fine
chcp 65001
more document.txt
# no output
---

It might be related to this:
http://stackoverflow.com/questions/3401802/codepage-850-works-65001-fails-there-is-no-response-to-call-foo-cmd-interna

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:36:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 10:36:37 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1386659325.72.0.313292500541.issue19846@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYMv5HenLSmsqYFO-bh+EALbhuNsftDHuAvEAxDjf45aA@mail.gmail.com>


STINNER Victor added the comment:

2013/12/10 Martin v. L?wis <report at bugs.python.org>:
> >From what I read, it appears that the SO posting is plain wrong. Consider, for example,
>
> https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#g-filename-to-utf8
>
> # Converts a string which is in the encoding used by GLib for filenames
> # into a UTF-8 string. Note that on Windows GLib uses UTF-8 for filenames;
> # on other platforms, this function indirectly depends on the current locale.
>
> The SO author might have misread the part where it says that glib uses UTF-8 *on Windows* (instead of the braindead "ANSI" encoding indirection).

I wrote some notes about glib here:
http://unicodebook.readthedocs.org/en/latest/libraries.html#the-glib-library

g_filename_from_utf8() uses the g_get_filename_charsets() encoding.
g_get_filename_charsets() is the ANSI code page on Windows and the
locale encoding on Linux, except if G_FILENAME_ENCODING or
G_BROKEN_FILENAMES environment variables are set.

glib has a nice g_filename_display_name() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:47:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 10:47:24 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>
Message-ID: <1386672444.28.0.429942341693.issue19017@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is the status of this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:48:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 10:48:15 +0000
Subject: [issue19017] selectors: towards uniform EBADF handling
In-Reply-To: <1379156518.11.0.97134012587.issue19017@psf.upfronthosting.co.za>
Message-ID: <1386672495.39.0.482028649993.issue19017@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The issue #19876 has been closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19017>
_______________________________________

From report at bugs.python.org  Tue Dec 10 11:49:50 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 10:49:50 +0000
Subject: [issue19407] PEP 453: update the "Installing Python Modules"
 documentation
In-Reply-To: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za>
Message-ID: <1386672590.68.0.417845838972.issue19407@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

After reviewing the Extending & Embedding docs recently, I think a disclaimer/redirect to the tool recommendations in the Python Packaging User Guide is appropriate there as well.

Marcus also added an issue to update the distutils docs themselves: https://bitbucket.org/pypa/python-packaging-user-guide/issue/29/modernize-distutils-docs

(The user guide tracker is currently serving as a metatracker for docs issues for all the core tools)

----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19407>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:04:57 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:04:57 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
Message-ID: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

If you have a non-ASCII .py file without encoding declaration, then you can't normally import it:

$ python --version
Python 2.7.6

$ python -c 'import test'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "test.py", line 1
SyntaxError: Non-ASCII character '\xc2' in file test.py on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details


However, "python -m" happily imports such files:

$ python -m test
?Hello world!

----------
files: test.py
messages: 205787
nosy: jwilk
priority: normal
severity: normal
status: open
title: python -m imports non-ASCII .py file without encoding declaration
versions: Python 2.7
Added file: http://bugs.python.org/file33076/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:06:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 11:06:32 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
In-Reply-To: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>
Message-ID: <1386673592.58.0.366392525142.issue19941@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +brett.cannon, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:07:02 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:07:02 +0000
Subject: [issue17762] platform.linux_distribution() should honor
 /etc/os-release
In-Reply-To: <1366124468.64.0.40642643299.issue17762@psf.upfronthosting.co.za>
Message-ID: <1386673622.9.0.83605450798.issue17762@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17762>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:17:43 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:17:43 +0000
Subject: [issue19907] gettext - Non ascii chars in header
In-Reply-To: <1386328833.52.0.797354581277.issue19907@psf.upfronthosting.co.za>
Message-ID: <1386674263.19.0.0388948459474.issue19907@psf.upfronthosting.co.za>


Jakub Wilk added the comment:

See also issue18128.
Date headers are not only for humans; I've seen software that parses them.

----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19907>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:18:44 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:18:44 +0000
Subject: [issue19783] No SSL match_hostname() in nntplib
In-Reply-To: <1385423208.98.0.59627306788.issue19783@psf.upfronthosting.co.za>
Message-ID: <1386674324.47.0.901663482905.issue19783@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19783>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:19:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 11:19:25 +0000
Subject: [issue19407] PEP 453: update the "Installing Python Modules"
 documentation
In-Reply-To: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za>
Message-ID: <3ddzLh4fs0z7Lk4@mail.python.org>


Roundup Robot added the comment:

New changeset a9f91a38a265 by Nick Coghlan in branch '2.7':
Issue #19407: add Python Packaging User Guide notes
http://hg.python.org/cpython/rev/a9f91a38a265

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19407>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:27:58 2013
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 10 Dec 2013 11:27:58 +0000
Subject: [issue19693] "make altinstall && make install" behaviour differs from
 "make install"
In-Reply-To: <1385131154.65.0.84746252058.issue19693@psf.upfronthosting.co.za>
Message-ID: <1386674878.88.0.687860050047.issue19693@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Making this happen is a non trivial change to pip. Is this *required* for PEP453?

The problem is the pip dependency is already being seen as fulfilled so it's not reinstalling pip again with the new options picked. Likely the actual answer is a command in pip to regenerate the scripts but that will require some engineering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19693>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:30:29 2013
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 10 Dec 2013 11:30:29 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <1386675029.75.0.759748111737.issue19728@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Is there anything left in this ticket to be done?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19728>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:32:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 11:32:38 +0000
Subject: [issue19407] PEP 453: update the "Installing Python Modules"
 documentation
In-Reply-To: <1382791475.83.0.387983167617.issue19407@psf.upfronthosting.co.za>
Message-ID: <3ddzdx6bQNz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 16b7536e418b by Nick Coghlan in branch '3.3':
Issue #19407: add Python Packaging User Guide notes
http://hg.python.org/cpython/rev/16b7536e418b

New changeset bc21da9727ad by Nick Coghlan in branch 'default':
Issue #19407: merge PPUG notes from 3.3
http://hg.python.org/cpython/rev/bc21da9727ad

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19407>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:47:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 11:47:31 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386676051.41.0.597248533587.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch. There is no more overhead in PyLong_As* functions. Simplified PyNumber_Index(). assertWarns() now used instead of support.check_warnings(). Added new tests.

----------
Added file: http://bugs.python.org/file33077/issue17576_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:47:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 11:47:38 +0000
Subject: [issue19693] "make altinstall && make install" behaviour differs from
 "make install"
In-Reply-To: <1385131154.65.0.84746252058.issue19693@psf.upfronthosting.co.za>
Message-ID: <1386676058.44.0.127290278638.issue19693@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Fixing in pip 1.6/CPython 3.4.1 would be fine by me - that's why I only created it as "high" rather than "release blocker"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19693>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:48:59 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:48:59 +0000
Subject: [issue19942] UTF-8 encoding not enforced
Message-ID: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

I created a Python file which contained a non-UTF-8 string literal (but no Unicode literals), and added "UTF-8" encoding declaration to it. I expected that Python will raise SyntaxError when importing such module, but it doesn't:

$ python --version
Python 2.7.6

$ python -c 'import test1' && echo ok
ok


Curiously enough, if I change the declaration to "UTF8", then the exception is raised as expected:

$ sed -e 's/UTF-8/UTF8/' < test1.py > test2.py
$ python -c 'import test2'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "test2.py", line 2
SyntaxError: 'utf8' codec can't decode byte 0xa1 in position 5: invalid start byte

----------
messages: 205795
nosy: jwilk
priority: normal
severity: normal
status: open
title: UTF-8 encoding not enforced
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:49:25 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:49:25 +0000
Subject: [issue19942] UTF-8 encoding not enforced
In-Reply-To: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>
Message-ID: <1386676165.78.0.331653566571.issue19942@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


Added file: http://bugs.python.org/file33078/test1.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:52:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 11:52:54 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <1386676374.43.0.0932157597657.issue19728@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yes, it still needs to be integrated into the installer and the default state of the feature changed.

I expect MvL will look into that before creating the beta 2 installer.

Bumping the priority accordingly, though (I originally set it to high when we weren't sure if we were going to fix it for 3.4)

----------
nosy: +larry
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19728>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:53:30 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Dec 2013 11:53:30 +0000
Subject: [issue19942] UTF-8 encoding not enforced
In-Reply-To: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>
Message-ID: <1386676410.18.0.010896474659.issue19942@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Unicode
nosy: +ezio.melotti, haypo
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:54:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 11:54:21 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <3df0704jm8z7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset a0c687dc0039 by Serhiy Storchaka in branch 'default':
Remove commented out debugging code (remnants of issue #18996).
http://hg.python.org/cpython/rev/a0c687dc0039

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:55:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 11:55:13 +0000
Subject: [issue18996] unittest: more helpful truncating long strings
In-Reply-To: <1378813907.09.0.280972244132.issue18996@psf.upfronthosting.co.za>
Message-ID: <1386676513.07.0.100241553009.issue18996@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, thank you Vajrasky.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18996>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:58:32 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 11:58:32 +0000
Subject: =?utf-8?q?=5Bissue19943=5D_typo=3A_unkown_=E2=86=92_unknown?=
Message-ID: <1386676712.53.0.751027369098.issue19943@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

There's a typo in Lib/lib2to3/fixes/fix_import.py:
unkown ? unknown

----------
components: Library (Lib)
messages: 205799
nosy: jwilk
priority: normal
severity: normal
status: open
title: typo: unkown ? unknown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19943>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:58:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 11:58:43 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
In-Reply-To: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>
Message-ID: <1386676723.39.0.599772140804.issue19941@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +loewis, serhiy.storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Tue Dec 10 12:59:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 11:59:02 +0000
Subject: [issue19942] UTF-8 encoding not enforced
In-Reply-To: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>
Message-ID: <1386676742.21.0.224240019437.issue19942@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +loewis, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:02:03 2013
From: report at bugs.python.org (Tim Golden)
Date: Tue, 10 Dec 2013 12:02:03 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386676923.95.0.752536605241.issue19940@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:06:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 12:06:51 +0000
Subject: =?utf-8?q?=5Bissue19943=5D_typo=3A_unkown_=E2=86=92_unknown?=
In-Reply-To: <1386676712.53.0.751027369098.issue19943@psf.upfronthosting.co.za>
Message-ID: <3df0PQ4KMZz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset b96a6493cecf by Ezio Melotti in branch '2.7':
#19943: fix typo noticed by Jakub Wilk.
http://hg.python.org/cpython/rev/b96a6493cecf

New changeset 9f38bbd4e041 by Ezio Melotti in branch '3.3':
#19943: fix typo noticed by Jakub Wilk.
http://hg.python.org/cpython/rev/9f38bbd4e041

New changeset a3bdbe220f8a by Ezio Melotti in branch 'default':
#19943: merge with 3.3.
http://hg.python.org/cpython/rev/a3bdbe220f8a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19943>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:07:28 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Dec 2013 12:07:28 +0000
Subject: =?utf-8?q?=5Bissue19943=5D_typo=3A_unkown_=E2=86=92_unknown?=
In-Reply-To: <1386676712.53.0.751027369098.issue19943@psf.upfronthosting.co.za>
Message-ID: <1386677248.21.0.0106678642171.issue19943@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> enhancement
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19943>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:07:39 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 12:07:39 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1386677259.91.0.138263865218.issue12029@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:09:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 12:09:03 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386677343.02.0.243206597746.issue17576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Took me a while to figure out that one of the code paths was being deleted as redundant because the type machinery will always fill in nb_int for int subclasses, but Serhiy's patch looks good to me.

----------
assignee: mark.dickinson -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:10:46 2013
From: report at bugs.python.org (gudge)
Date: Tue, 10 Dec 2013 12:10:46 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386677446.28.0.896231579325.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Will work on this.
Please assign the issue to me.

Instructions before proceeding by Tim Golden(python mailing list):

Having just glanced at that issue, I would point out that there's been a
lot of development around the ssl module for the 3.4 release, so you
definitely want to confirm the issue against the hg tip to ensure it
still applies.

----------
nosy: +gudge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:19:04 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 10 Dec 2013 12:19:04 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1386677944.17.0.101582121169.issue5996@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:29:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 12:29:01 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
Message-ID: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In implementing the runpy module updates for PEP 451 I ran into the fact that importlib.find_spec had copied the find_loader behaviour where it doesn't handle dotted names automatically - you have to explicitly pass in the __path__ from the parent module for it to work.

For find_loader, runpy used pkgutil.get_loader instead. The patch on issue 19700 currently includes a runpy._fixed_find_spec function that handles walking the module name components, loading packages as necessary.

I believe it would be better to move the current thin wrapper around importlib._bootstrap._find_spec to importlib.find_spec_on_path (which will only search for the specified module name directly on the given path without breaking it up into components), with find_spec itself changed to *not* take a "path" argument, and instead always doing the full lookup (as implemented in the issue 19700 patch _fixed_find_spec function)

----------
components: Library (Lib)
messages: 205804
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Make importlib.find_spec load packages as needed
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:30:35 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 10 Dec 2013 12:30:35 +0000
Subject: [issue16104] Use multiprocessing in compileall script
In-Reply-To: <1349124414.14.0.0730954283721.issue16104@psf.upfronthosting.co.za>
Message-ID: <1386678635.5.0.676436625385.issue16104@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello!

Here's a draft patch. It adds a new *processes* parameter to *compile_dir* and a new command line parameter as well.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file33079/compileall_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16104>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:30:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 12:30:36 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386678636.78.0.622992279041.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 19944 now covers moving the current importlib.find_spec to importlib.find_spec_on_path and having importlib.find_spec behave like runpy._fixed_find_spec in my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:40:39 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 10 Dec 2013 12:40:39 +0000
Subject: [issue15963] Improve ./configure's support for 32/64-bit
 debug|release|profiled builds w/ vendor (non-gcc) compilers	on
 proprietary UNIX systems (Solaris/HP-UX/AIX et al).
In-Reply-To: <1347975635.66.0.0788814924298.issue15963@psf.upfronthosting.co.za>
Message-ID: <1386679239.67.0.369638550433.issue15963@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Trent, did the HPUX CFLAGS/LDFLAGS change on the buildbots?  I think
_decimal used to compile on the PA-RISC bot, but now there is an error.

Perhaps -AC99 or something like that is missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15963>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:50:42 2013
From: report at bugs.python.org (Toilal)
Date: Tue, 10 Dec 2013 12:50:42 +0000
Subject: [issue19945] os.path.split starting with two slashes
Message-ID: <1386679842.42.0.284091102945.issue19945@psf.upfronthosting.co.za>


New submission from Toilal:

Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import split
>>> split('//computer/share')
('//computer', 'share')


Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from os.path import split
>>> split('//computer/share')
('//computer/share', '')

Result from 2.7.6 and 3.3.3 is different. Is it a bugfix from 2.7.6 to 3.3.3, or a regression in 3.3.3 ?

Same issue occurs with backslashes.

----------
components: Library (Lib)
messages: 205808
nosy: Toilal
priority: normal
severity: normal
status: open
title: os.path.split starting with two slashes
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19945>
_______________________________________

From report at bugs.python.org  Tue Dec 10 13:59:17 2013
From: report at bugs.python.org (Martin Miller)
Date: Tue, 10 Dec 2013 12:59:17 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
 tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1386680357.07.0.180943478379.issue5712@psf.upfronthosting.co.za>


Martin Miller added the comment:

Answering Serhiy Storchaka's question: Yes it's still reproducible with 2.7.6.

----------
nosy: +martinmiller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:08:59 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Tue, 10 Dec 2013 13:08:59 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
Message-ID: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>


New submission from Olivier Grisel:

Here is a simple python program that uses the new forkserver feature introduced in 3.4b1:


name: checkforkserver.py
"""
import multiprocessing
import os


def do(i):
    print(i, os.getpid())


def test_forkserver():
    mp = multiprocessing.get_context('forkserver')
    mp.Pool(2).map(do, range(3))


if __name__ == "__main__":
    test_forkserver()
"""

When running this using the "python check_forkserver.py" command everything works as expected.

When running this using the nosetests launcher ("nosetests -s check_forkserver.py"), I get:

"""
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/forkserver.py", line 141, in main
    spawn.import_main_path(main_path)
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 252, in import_main_path
    methods.init_module_attrs(main_module)
  File "<frozen importlib._bootstrap>", line 1051, in init_module_attrs
AttributeError: 'NoneType' object has no attribute 'loader'
"""

Indeed, the spec variable in multiprocessing/spawn.py's import_main_path
function is None as the nosetests script is not a regular python module: in particular is does not have a ".py" extension.

If I copy or symlink or renamed the "nosetests" script as "nosetests.py" in the same folder, this works as expected. I am not familiar enough with the importlib machinery to suggest a fix for this bug.

Also there is a typo in the comment: "causing a psuedo fork bomb" => "causing a pseudo fork bomb".

Note: I am running CPython head updated today.

----------
components: Library (Lib)
messages: 205810
nosy: Olivier.Grisel
priority: normal
severity: normal
status: open
title: multiprocessing crash with forkserver  or spawn  when run from a non ".py" ending script
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:09:51 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Tue, 10 Dec 2013 13:09:51 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386680991.29.0.391521310528.issue19946@psf.upfronthosting.co.za>


Changes by Olivier Grisel <olivier.grisel at ensta.org>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:36:55 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 13:36:55 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1386682615.82.0.362254555475.issue19828@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The real issue here is that the test used to determine whether -S was passed or not is outdated: instead of checking sys.flags.no_site, it checks whether 'site' is in sys.modules.  This is no longer a valid test, since site's side effects are contained within site.main, which is only run if no_site is False.  In fact, distutils imports symbols from site unconditionally, as do a couple of test modules; hence why test_site currently fails running `python -S Lib/test`: test_distutils (and others) run before test_site and cause site to be present in sys.modules.

I think we should move away from a toplevel SkipTest, though; some of the tests may be applicable whether -S is passed or not, though of course the ImportSideEffectTests would not be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19828>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:41:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 13:41:57 +0000
Subject: [issue19945] os.path.split starting with two slashes
In-Reply-To: <1386679842.42.0.284091102945.issue19945@psf.upfronthosting.co.za>
Message-ID: <1386682917.65.0.466587941345.issue19945@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

ntpath.split() in 2.7 doesn't work with UNC names. This is not a bug, this is just a lack of feature.

Python 3 is correct.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19945>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:42:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:42:55 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386682975.51.0.267881049377.issue19940@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou
versions:  -Python 2.7, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:43:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:43:08 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386682988.19.0.722649964145.issue19940@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: docs at python -> 
components:  -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:46:15 2013
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 10 Dec 2013 13:46:15 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1386683175.79.0.536076465376.issue19766@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Vinay, I've verified that the current default branch of distlib works without threading when vendored in pip and these tests pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:46:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:46:54 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386683214.24.0.565982331159.issue19940@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed the example in the docs is wrong, and so is the current behaviour.

The example shows "round-tripping" using ssl.cert_time_to_seconds() and then time.ctime(), except that it is bogus as it takes a GMT time and ctime() returns a local time ("""Convert a time expressed in seconds since the epoch to a string representing local time""").

Still, we should only fix it in 3.4, as code written for prior versions may rely on the current (bogus) behaviour.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:48:02 2013
From: report at bugs.python.org (Yongzhi Pan)
Date: Tue, 10 Dec 2013 13:48:02 +0000
Subject: [issue18885] handle EINTR in the stdlib
In-Reply-To: <1377874955.28.0.258891288899.issue18885@psf.upfronthosting.co.za>
Message-ID: <1386683282.58.0.248798813616.issue18885@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <fossilet at users.sourceforge.net>:


----------
nosy: +fossilet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18885>
_______________________________________

From report at bugs.python.org  Tue Dec 10 14:48:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 13:48:14 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386683293.99.0.630527206823.issue19940@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

gudge, your contribution is welcome! If you need guidance about how to write a patch, you can read the developer's guide: http://docs.python.org/devguide/

Also you will have to sign a contributor's agreement: http://www.python.org/psf/contrib/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:21:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 14:21:37 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386685297.47.0.370642622103.issue19946@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +pitrou, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:28:08 2013
From: report at bugs.python.org (Toilal)
Date: Tue, 10 Dec 2013 14:28:08 +0000
Subject: [issue19945] os.path.split starting with two slashes
In-Reply-To: <1386679842.42.0.284091102945.issue19945@psf.upfronthosting.co.za>
Message-ID: <1386685688.66.0.0360186014378.issue19945@psf.upfronthosting.co.za>


Changes by Toilal <toilal.dev at gmail.com>:


----------
resolution:  -> remind
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19945>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:37:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 14:37:26 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
 tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1386686246.41.0.281688221435.issue5712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What are values of Tkinter.wantobjects, Tkinter._support_default_root, Tkinter._default_root, Tkinter._default_root.wantobjects()? Before and after calling tkFileDialog.askopenfilenames().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:40:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 14:40:06 +0000
Subject: [issue19945] os.path.split starting with two slashes
In-Reply-To: <1386679842.42.0.284091102945.issue19945@psf.upfronthosting.co.za>
Message-ID: <1386686406.76.0.0882080372148.issue19945@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution: remind -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19945>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:41:42 2013
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 10 Dec 2013 14:41:42 +0000
Subject: [issue19744] test_venv fails if SSL/TLS is not available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <1386686502.88.0.394927208286.issue19744@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Can this be solved in ensurepip for now? I've been banging away at this but it's going to require some refactoring in pip to make it reasonably work. The move to distlib and requests made this harder to do than the old PR against pip could handle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19744>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:49:44 2013
From: report at bugs.python.org (Jimmy Merrild Krag)
Date: Tue, 10 Dec 2013 14:49:44 +0000
Subject: [issue19947] Inspect module broken
Message-ID: <1386686984.53.0.934353446234.issue19947@psf.upfronthosting.co.za>


New submission from Jimmy Merrild Krag:

I have been having issues like the below all day:

C:\JMK\CurrentWork\CPH-3516>python airport_code_downloader.py
Traceback (most recent call last):
  File "airport_code_downloader.py", line 4, in <module>
    import inspect
  File "C:\Python33\lib\inspect.py", line 53, in <module>
    from dis import COMPILER_FLAG_NAMES as _flag_names
  File "C:\Python33\lib\dis.py", line 13, in <module>
    _have_code = (types.MethodType, types.FunctionType, types.CodeType, type)
AttributeError: 'module' object has no attribute 'MethodType'

C:\JMK\CurrentWork\CPH-3516>

It seems to be a problem with the types module. All the types seem non-existing.

----------
messages: 205818
nosy: beruic
priority: normal
severity: normal
status: open
title: Inspect module broken
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19947>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:55:25 2013
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Glondu?=)
Date: Tue, 10 Dec 2013 14:55:25 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
Message-ID: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>


New submission from St?phane Glondu:

Hello,

According to [1],

"In the cases where the other members of the exec family of functions would fail and set errno to [ENOEXEC], the execlp() and execvp() functions shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the sh utility using execl() as follows:

execl(<shell path>, arg0, file, arg1, ..., (char *)0);"

This is not the case with os.execvp which keeps looking in PATH for other executables. To reproduce:

 1. pick some executable that exists in /usr/bin (let's say "curl")
 2. prepend to PATH a directory where you put an executable file with name "curl" and some random shell commands, without the #! line
 3. run os.execvp("curl", ["curl"])

Instead of running the #!-less shell script, /usr/bin/curl is executed. With GNU libc's execvp(), the shell script is executed. According to my interpretation of POSIX, the shell script should be executed.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

Cheers,

-- 
St?phane

----------
components: Library (Lib)
messages: 205819
nosy: glondu
priority: normal
severity: normal
status: open
title: POSIX semantics of PATH search in execvpe is not respected
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:56:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Dec 2013 14:56:00 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
In-Reply-To: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>
Message-ID: <1386687360.46.0.966991503033.issue19941@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, we aren't going to change 2.7 to have this case start throwing an error, since someone may be depending on it.  So I'm not sure there's anything to do here.

----------
nosy: +ncoghlan, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:57:23 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 14:57:23 +0000
Subject: [issue19932] Missing spaces in import.h?
In-Reply-To: <1386536231.5.0.310444534169.issue19932@psf.upfronthosting.co.za>
Message-ID: <1386687443.51.0.851949908785.issue19932@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So it sounds like this specific issue is fixed. If you keep having build issues, Ziyuan, feel free to open another issue with the new problems.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19932>
_______________________________________

From report at bugs.python.org  Tue Dec 10 15:58:09 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 14:58:09 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386687489.21.0.74890064881.issue18864@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:11:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 15:11:15 +0000
Subject: [issue19939] Deprecate portions or all of pkgutil module.
In-Reply-To: <1386654881.95.0.820542970377.issue19939@psf.upfronthosting.co.za>
Message-ID: <1386688275.45.0.272490281564.issue19939@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think programmatic deprecation is actually fine since that only comes up when running under -W which would be a bit odd for any tool to be run under except when testing. E.g. I had no personal issue deprecating imp for Python 3.4 even though that's the only way to do 2/3 programmatic import craziness as its use should be discouraged as much as possible since it's now fundamentally the wrong paradigm. And the tools can simply silence the deprecation if they actually find it noisy.

I do agree it should just be a PendingDeprecationWarning and not expect to remove it until either Python 4 or when the community has heavily shifted to Python 3. But when there are semantic replacements I think not doing a programmatic deprecation with warnings off by default is a disservice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19939>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:16:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 15:16:16 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
In-Reply-To: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>
Message-ID: <1386688576.78.0.550580421716.issue19941@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are several bugs in processing encoding declaration (issue18961, issue18873) and yet several were fixed last time. Perhaps this issue or issue19942 relate to them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:19:43 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 15:19:43 +0000
Subject: [issue19947] Inspect module broken
In-Reply-To: <1386686984.53.0.934353446234.issue19947@psf.upfronthosting.co.za>
Message-ID: <1386688783.26.0.0943223476069.issue19947@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I suspect you may have a file shadowing the standard library's types.py; you can test with the following command:

python -c "import types;print(types.__file__)"

If the output from that is not "C:\Python33\lib\types.py", then you have another file shadowing it, which would best be renamed.

----------
nosy: +zach.ware
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19947>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:21:02 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 15:21:02 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386688862.92.0.780191875027.issue19944@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Another option would be to add a keyword-only use_parent_path flag to importlib.find_spec() which is True by default. If use_parent is True, 'path' is provided, and there is no parent, then 'path' can act as a fallback.

Which makes me wonder if also adding a keyword-only import_parents keyword to implicitly import any parent packages as necessary would be helpful. It would imply use_parent_path as true. Might also be useful to add to import_module() to get rid of that annoyance inherited from __import__.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:24:52 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 10 Dec 2013 15:24:52 +0000
Subject: [issue19942] UTF-8 encoding not enforced
In-Reply-To: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>
Message-ID: <1386689092.65.0.237947775068.issue19942@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Yes, this is a silly bug where we "shortcut" decoding of utf-8 files by not checking if its valid UTF-8. However, this behavior has been around for a long time, so I'm not going to change it in 2.7.x.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:25:41 2013
From: report at bugs.python.org (Jimmy Merrild Krag)
Date: Tue, 10 Dec 2013 15:25:41 +0000
Subject: [issue19947] Inspect module broken
In-Reply-To: <1386686984.53.0.934353446234.issue19947@psf.upfronthosting.co.za>
Message-ID: <1386689141.82.0.317413147849.issue19947@psf.upfronthosting.co.za>


Jimmy Merrild Krag added the comment:

Just figured that out my self. Holy mother of ?%#&%/! I'm stupid!

----------
resolution:  -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19947>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:29:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Dec 2013 15:29:55 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386689395.38.0.994390247714.issue19948@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/issue19948>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:30:46 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 15:30:46 +0000
Subject: [issue19947] Inspect module broken
In-Reply-To: <1386686984.53.0.934353446234.issue19947@psf.upfronthosting.co.za>
Message-ID: <1386689446.84.0.403299734894.issue19947@psf.upfronthosting.co.za>


Zachary Ware added the comment:

People are bitten by this kind of thing all the time, but usually only once ;)

----------
resolution: rejected -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19947>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:44:39 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Dec 2013 15:44:39 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1386690279.01.0.0385436416695.issue12029@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

"I remembered we already run arbitrary code at roughly this point in the eval loop, as we have to invoke __iter__ to get the exceptions to check when an iterable is used in except clause."

Are you sure?  IIRC the except clause only accept exceptions and tuples of exceptions, not iterators.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Tue Dec 10 16:47:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 15:47:51 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386690471.07.0.533862562969.issue19946@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This sounds related to the ModuleSpec changes.

----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:12:37 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 16:12:37 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386691957.13.0.253807972897.issue19946@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The returning of None means that importlib.find_spec() didn't find the spec/loader for the specified module. So the question is exactly what module is being passed to importlib.find_spec() and why isn't it finding a spec/loader for that module.

Did this code work in Python 3.3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:14:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 16:14:10 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386692050.78.0.286885291797.issue19946@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I see Oliver says he is testing a new forkserver feature from 3.4b1, so it might not necessarily be importlib's fault then. Does using the old importlib.find_loader() approach work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:23:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 16:23:19 +0000
Subject: [issue19878] bz2.BZ2File.__init__() cannot be called twice with
 non-existent file
In-Reply-To: <1386096668.93.0.258103858078.issue19878@psf.upfronthosting.co.za>
Message-ID: <3df65L6LCCz7Llx@mail.python.org>


Roundup Robot added the comment:

New changeset 3337298f5c75 by Nadeem Vawda in branch '2.7':
Skip test for #19878 on Windows.
http://hg.python.org/cpython/rev/3337298f5c75

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19878>
_______________________________________

From report at bugs.python.org  Tue Dec 10 17:28:54 2013
From: report at bugs.python.org (Justin Foo)
Date: Tue, 10 Dec 2013 16:28:54 +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: <1386692934.11.0.410489253516.issue7511@psf.upfronthosting.co.za>


Justin Foo added the comment:

The speedups extension for MarkupSafe (which has a pure Python fallback) on Python 3.3.3 64-bit was happily compiled with `pip install markupsafe` after applying Steve's patch and Li Wah's definition for KEY_BASE.

----------
nosy: +jfoo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:25:20 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 17:25:20 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386696320.25.0.326878328933.issue19572@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new 2.7 patch.  It addresses Serhiy's review comments and doesn't change test_xpickle, which I will be opening a new issue for.

----------
Added file: http://bugs.python.org/file33080/skiptest_not_return_or_pass.v5-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:32:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 17:32:05 +0000
Subject: [issue19949] Explicitly skip or mask skipped/disabled tests in
 test_xpickle
Message-ID: <1386696725.08.0.917922388786.issue19949@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch moves test_xpickle away from using alternately defined empty TestCases to skip the backward compatibility tests to using a skip decorator.  Also, several disabled tests are moved from defining empty tests to setting the test name to None.  Also, the have_python_version function's test has its quotes swapped between ' and "; this made it possible to test the changes on Windows.

----------
components: Tests
files: test_xpickle_cleanup.diff
keywords: patch
messages: 205837
nosy: zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Explicitly skip or mask skipped/disabled tests in test_xpickle
versions: Python 2.7
Added file: http://bugs.python.org/file33081/test_xpickle_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19949>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:34:41 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 17:34:41 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386696881.37.0.0253967125538.issue19572@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I missed the comments on test_bsddb; I'll either post a new patch here or open a new issue depending on how big that diff becomes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:46:31 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 17:46:31 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386697591.33.0.350659278346.issue19572@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This patch includes Serhiy's suggestions.  Oops!

----------
Added file: http://bugs.python.org/file33082/skiptest_not_return_or_pass.v6-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:49:41 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 10 Dec 2013 17:49:41 +0000
Subject: [issue18874] Add a new tracemalloc module to trace memory allocations
In-Reply-To: <1377733991.41.0.484218634069.issue18874@psf.upfronthosting.co.za>
Message-ID: <1386697781.76.0.105350768493.issue18874@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/issue18874>
_______________________________________

From report at bugs.python.org  Tue Dec 10 18:55:54 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 10 Dec 2013 17:55:54 +0000
Subject: [issue19818] tracemalloc: comments on the doc
In-Reply-To: <1385590723.56.0.301392704832.issue19818@psf.upfronthosting.co.za>
Message-ID: <1386698154.07.0.467569123414.issue19818@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/issue19818>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:24:30 2013
From: report at bugs.python.org (Martin Miller)
Date: Tue, 10 Dec 2013 18:24:30 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
 tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1386699870.02.0.697538110555.issue5712@psf.upfronthosting.co.za>


Martin Miller added the comment:

Requested information:

Before                                              
Tkinter.wantobjects: 1                              
Tkinter._support_default_root: 1                    
Tkinter._default_root: None                         
Tkinter._default_root has no attribute 'wantobjects'

After                                               
Tkinter.wantobjects: 1                              
Tkinter._support_default_root: 1                    
Tkinter._default_root: .                            
Tkinter._default_root.wantobjects(): True

----------
Added file: http://bugs.python.org/file33083/python_issue_5712.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:24:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Dec 2013 18:24:49 +0000
Subject: [issue504219] locale.resetlocale is broken
Message-ID: <1386699889.41.0.66448074541.issue504219@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/issue504219>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:27:41 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2013 18:27:41 +0000
Subject: [issue16595] Add resource.prlimit
In-Reply-To: <1354446881.9.0.288115855459.issue16595@psf.upfronthosting.co.za>
Message-ID: <1386700061.98.0.127214091699.issue16595@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Just received this report on psutil bug tracker:
https://code.google.com/p/psutil/issues/detail?id=455
It seems os.prlimit() is affected by the same problem:

>>> import resource
>>> resource.RLIM_INFINITY
-1
>>>

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16595>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:28:27 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2013 18:28:27 +0000
Subject: [issue16595] Add resource.prlimit
In-Reply-To: <1354446881.9.0.288115855459.issue16595@psf.upfronthosting.co.za>
Message-ID: <1386700107.87.0.898906622709.issue16595@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

s/os.prlimit/resource.prlimit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16595>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:40:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Dec 2013 18:40:35 +0000
Subject: [issue16595] Add resource.prlimit
In-Reply-To: <1354446881.9.0.288115855459.issue16595@psf.upfronthosting.co.za>
Message-ID: <1386700835.14.0.574565297334.issue16595@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

How is that a problem? In any case, this shouldn't have anything to do with prlimit(), please open another issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16595>
_______________________________________

From report at bugs.python.org  Tue Dec 10 19:55:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 18:55:48 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386701748.72.0.295977669317.issue19572@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

$ ./python -3 -m test.regrtest test_builtin
test_builtin
test test_builtin crashed -- <type 'exceptions.AssertionError'>: filter ('.+ is renamed to imp.reload', DeprecationWarning) did not catch any warning
1 test failed:
    test_builtin

Rest of the skiptest_not_return_or_pass.v6-2.7.diff patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:03:09 2013
From: report at bugs.python.org (dellair jie)
Date: Tue, 10 Dec 2013 19:03:09 +0000
Subject: [issue19661] AIX: Python: RuntimeError "invalid slot offset when
 importing a module" in _ssl module
In-Reply-To: <1384940707.67.0.629503813291.issue19661@psf.upfronthosting.co.za>
Message-ID: <1386702189.08.0.253705646178.issue19661@psf.upfronthosting.co.za>


dellair jie added the comment:

Folks,

I am closing this bug as it seems to be fixed with a with a redownload of original package.

Thanks for sharing the ideas.

Br,
Li

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19661>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:05:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 10 Dec 2013 19:05:29 +0000
Subject: =?utf-8?q?=5Bissue19943=5D_typo=3A_unkown_=E2=86=92_unknown?=
In-Reply-To: <1386676712.53.0.751027369098.issue19943@psf.upfronthosting.co.za>
Message-ID: <1386702329.33.0.115514172262.issue19943@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19943>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:18:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 19:18:07 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1386703087.2.0.675599777707.issue19100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In new patch wrapping stream is moved to PrettyPrinter constructor.

----------
Added file: http://bugs.python.org/file33084/pprint_unencodable_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:18:35 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Tue, 10 Dec 2013 19:18:35 +0000
Subject: [issue19946] multiprocessing crash with forkserver or spawn when run
 from a non ".py" ending script
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386703115.43.0.0554226685601.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

> So the question is exactly what module is being passed to importlib.find_spec() and why isn't it finding a spec/loader for that module.

The module is the `nosetests` python script. module_name == 'nosetests' in this case. However, nosetests is not considered an importable module because of the missing '.py' extension in the filename.

> Did this code work in Python 3.3?

This code did not exist in Python 3.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 20:28:11 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Tue, 10 Dec 2013 19:28:11 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386703691.12.0.697867846929.issue19846@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

Looking at the glib code, this looks like the SO post is closer to the truth.  The API documentation for g_filename_to_utf8() is over-simplified to the point of confusion.  This section of the glib API document is closer to what the code is doing: https://developer.gnome.org/glib/stable/glib-Character-Set-Conversion.html#file-name-encodings

* When encoding matters, glib and gtk functions will assume that char*'s that you pass to them point to strings which are encoded in utf-8.
* When char* are not utf8 you are responsible for converting them to utf8 to be used by the glib functions (if encoding matters).
* glib provides g_filename_to_utf8() for the special case of transforming filenames into the encoding that glib expects.  (Presumably because glib and gtk deal with non-utf8 unicode filenames more often than the equivalent environment variables, command line switches, etc).
* Contrary to the API docs for g_filename_to_utf8(), g_filename_to_utf8() will simply return a copy of the byte string it was passed unless G_FILENAME_ENCODING or G_BROKEN_FILENAMES is set.  If those are set, then the value of G_FILENAME_ENCODING might be used to attempt to decode the filename or the encoding specified in the user's locale might be used.

@haypo, I'm pretty sure from reading the code for g_get_filename_charsets() that you have the conditionals reversed.  What I'm seeing is:

if G_FILENAME_ENCODING:
    charset = the first charset listed in G_FILENAME_ENCODING
    if charset == '@locale':
        charset = charset of user's locale
elif G_BROKEN_FILENAMES:
    charset = charset of user's locale
else:
    charset = 'UTF-8'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:04:07 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 10 Dec 2013 20:04:07 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386705847.65.0.885808609714.issue19940@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/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:09:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 20:09:41 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <3dfC6X4282z7Lk1@mail.python.org>


Roundup Robot added the comment:

New changeset 423e09aedf79 by Zachary Ware in branch '2.7':
Issue #19572: More silently skipped tests explicitly skipped.
http://hg.python.org/cpython/rev/423e09aedf79

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:10:42 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 10 Dec 2013 20:10:42 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386706242.38.0.95778080083.issue19948@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

What platform is this on? Looking quickly through posix.execve (which is what I think gets called), it looks like it just calls C's execve().

Also, what's your use case for this? I realize it might be a standard behavior, but it seems like a bad idea to me. (Not that that's a reason not to be standards compliant: I'm mostly just curious why you'd want this.)

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:11:00 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 20:11:00 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <1386706260.06.0.401081441216.issue19572@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed that last comment in the commit.  Thank you for all the reviews, Serhiy!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:18:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 20:18:55 +0000
Subject: [issue19928] Implement cell repr test
In-Reply-To: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>
Message-ID: <3dfCKB4Ts9z7Lnq@mail.python.org>


Roundup Robot added the comment:

New changeset 21a9abf6d428 by Zachary Ware in branch '2.7':
Issue #19928: Fix test on Windows
http://hg.python.org/cpython/rev/21a9abf6d428

New changeset a0f9f0778ce3 by Zachary Ware in branch '3.3':
Issue #19928: Fix test on Windows
http://hg.python.org/cpython/rev/a0f9f0778ce3

New changeset eb0622dc8376 by Zachary Ware in branch 'default':
Issue #19928: Fix test on Windows
http://hg.python.org/cpython/rev/eb0622dc8376

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19928>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:20:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 10 Dec 2013 20:20:08 +0000
Subject: [issue19928] Implement cell repr test
In-Reply-To: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>
Message-ID: <1386706808.66.0.740629121247.issue19928@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This was failing the Windows buildbots; the object addresses have capital letters instead of lower case.  I'm sorry, I should have caught that at review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19928>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:27:32 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Dec 2013 20:27:32 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386707252.97.0.998240004224.issue19946@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So at the bare minimum, the multiprocessing code should raise an ImportError when it can't find the spec for the module to help debug this kind of thing. Also that typo should get fixed.

Second, there is no way that 'nosetests' will ever succeed as an import since, as Oliver pointed out, it doesn't end in '.py' or any other identifiable way for a finder to know it can handle the file. So this is not a bug and simply a side-effect of how import works. The only way around it would be to symlink nosetests to nosetests.py or to somehow pre-emptively set up 'nosetests' for supported importing.

----------
assignee:  -> brett.cannon
priority: normal -> low
stage:  -> needs patch
title: multiprocessing crash with forkserver  or spawn  when run from a non ".py" ending script -> Have multiprocessing raise ImportError when spawning a process that can't find the "main" module
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:27:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 20:27:49 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1386703691.12.0.697867846929.issue19846@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYnhDJWq4gerqobyr1d4ks+dRqUc=sWD8ndF5Ug36xx_A@mail.gmail.com>


STINNER Victor added the comment:

2013/12/10 Toshio Kuratomi <report at bugs.python.org>:
> if G_FILENAME_ENCODING:
>     charset = the first charset listed in G_FILENAME_ENCODING
>     if charset == '@locale':
>         charset = charset of user's locale
> elif G_BROKEN_FILENAMES:
>     charset = charset of user's locale
> else:
>     charset = 'UTF-8'

g_get_filename_charsets() returns a list of encodings. For the last
case (else:), it uses ['utf-8', local_encoding] on UNIX. It's reliable
because the utf-8 encoding has a nice feature, the utf-8 decoder fails
if the byte string is not a valid utf-8 string.

It would interesting to test this approach (try utf-8 or use the
locale encoding) in
PyUnicode_DecodeFSDefault/PyUnicode_EncodeFSDefault and
_Py_char2wchar/_Py_wchar2char.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:38:04 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 10 Dec 2013 20:38:04 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386707884.63.0.451380427475.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks, Serhiy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:39:39 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 10 Dec 2013 20:39:39 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386707979.6.0.907963286148.issue19946@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I guess this is a case where we should not be trying to import the main module.  The code for determining the path of the main module (if any) is rather crufty.

What is sys.modules['__main__'] and sys.modules['__main__'].__file__ if you run under nose?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 10 21:48:57 2013
From: report at bugs.python.org (Maciej Szulik)
Date: Tue, 10 Dec 2013 20:48:57 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1386708537.45.0.254954616275.issue1100942@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Tue Dec 10 22:00:39 2013
From: report at bugs.python.org (axil)
Date: Tue, 10 Dec 2013 21:00:39 +0000
Subject: [issue16244] TimedRotatingFileHandler forces "write" mode,
 should use "append"
In-Reply-To: <1350363937.05.0.667982982296.issue16244@psf.upfronthosting.co.za>
Message-ID: <1386709239.09.0.98325803849.issue16244@psf.upfronthosting.co.za>


axil added the comment:

This fix breaks the behavior of RotatingFileHandler.

Maxbytes>0 can now be only used with backupCount>0 otherwise it is ignored.

So all programs that are using Maxbytes>0 and backupCount=0 are now facing an infinitely growing logfile.

----------
nosy: +axil
type: behavior -> resource usage
versions: +Python 2.7
Added file: http://bugs.python.org/file33085/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16244>
_______________________________________

From report at bugs.python.org  Tue Dec 10 22:37:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Dec 2013 21:37:27 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <CAMpsgwYnhDJWq4gerqobyr1d4ks+dRqUc=sWD8ndF5Ug36xx_A@mail.gmail.com>
Message-ID: <CAMpsgwYNcvfehVE8wa=01Aut2Dt-qN0Up=OUQOQjivDQvmnfZA@mail.gmail.com>


STINNER Victor added the comment:

> It would interesting to test this approach (try utf-8 or use the locale encoding) ...

Oh, it may be easy to implement it for decoders, but what about
encoders? Should os.fsencode() always use UTF-8??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 10 22:37:28 2013
From: report at bugs.python.org (akira)
Date: Tue, 10 Dec 2013 21:37:28 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1386711448.65.0.591865932318.issue19940@psf.upfronthosting.co.za>


akira added the comment:

gudge,

There is also an issue with the current strptime format [1] (`"%b %d %H:%M:%S %Y GMT"`). It is locale-dependent and it may fail if a non-English locale is in effect. I don't know whether I should open a new issue on this or are you going to fix it too.

`cert_time_to_seconds()` is documented [2] to parse notBefore, notAfter fields from a certificate. As far as I can tell they do not depend on current locale. Thus the following code should not fail:

    >>> timestr = "May  9 00:00:00 2007 GMT"
    >>> import ssl
    >>> ssl.cert_time_to_seconds(timestr)
    1178661600.0
    >>> import locale
    >>> locale.setlocale(locale.LC_TIME, 'pl_PL.utf8')
    'pl_PL.utf8'
    >>> ssl.cert_time_to_seconds(timestr)
    Traceback (most recent call last):
    ...[snip]...
    ValueError: time data 'May  9 00:00:00 2007 GMT' does not match format '%b %d %H:%M:%S %Y GMT'


[1]: http://hg.python.org/cpython/file/96a68e369d13/Lib/ssl.py#l849
[2]: http://hg.python.org/cpython/file/96a68e369d13/Doc/library/ssl.rst#l359

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Tue Dec 10 22:40:27 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 10 Dec 2013 21:40:27 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386711627.16.0.929740908563.issue19944@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/issue19944>
_______________________________________

From report at bugs.python.org  Tue Dec 10 22:41:09 2013
From: report at bugs.python.org (HCT)
Date: Tue, 10 Dec 2013 21:41:09 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386711669.03.0.05744070383.issue19914@psf.upfronthosting.co.za>


HCT added the comment:

the other issue I'm also seeing is that help() doesn't seem to take exactly an object as an optional argument. perhaps Python manual for help() should be updated according to the actual implementation?

>>> help('hello')
no Python documentation found for 'hello'

>>> type('hello')
<class 'str'>
>>> a='hello'
>>> help(a)
no Python documentation found for 'hello'

>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Tue Dec 10 22:53:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Dec 2013 21:53:32 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386712412.3.0.864751342793.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about PyLong_AsSsize_t(), PyLong_AsUnsignedLong(), and PyLong_AsSize_t()? They are ignore __int__().

PyLong_AsVoidPtr() calls PyLong_AsLong(), PyLong_AsUnsignedLong(), PyLong_AsLongLong(), or PyLong_AsUnsignedLongLong() (depending on pointer's size and it's sign) and therefore can call or not call __int__, can raise or not raise TypeError on non-int subclasses with defined __int__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:06:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Dec 2013 22:06:59 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <3dfFjt7207z7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset ca9bca7aecda by Zachary Ware in branch '2.7':
Issue #19572: Replace a return that shouldn't have been removed from test_os.
http://hg.python.org/cpython/rev/ca9bca7aecda

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:34:18 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 10 Dec 2013 22:34:18 +0000
Subject: [issue19950] Document that unittest.TestCase.__init__ is called once
 per test
Message-ID: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

I was surprised that in the following __init__ is actually called once per test function, although nothing in documentation implied so.

a.py
------

import unittest

class A(unittest.TestCase):
   def __init__(self, *args, **kwargs):
       print('called only once!')
       super().__init__(*args, **kwargs)

   def test(self):
       self.assertEqual(1, 1)
 
   def test2(self):
       self.assertEqual(2, 2)

if __name__ == '__main__':
   unittest.main()

$ python a.py
called only once!
called only once!
..
----------------------------------------------------------------------
Ran 2 tests in 0.001s

OK



The attached patch adds a note regarding this behaviour for the TestCase class.

----------
assignee: docs at python
components: Documentation
files: unittest_init.patch
keywords: patch
messages: 205864
nosy: Claudiu.Popa, docs at python, michael.foord
priority: normal
severity: normal
status: open
title: Document that unittest.TestCase.__init__ is called once per test
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33086/unittest_init.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19950>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:49:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 22:49:46 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
In-Reply-To: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>
Message-ID: <1386715786.76.0.928084511344.issue19941@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Quite plausibly a bug in the pkgutil import system emulation. Does the same inconsistency appear in 3.3 with non-UTF8 bytes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Tue Dec 10 23:51:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 Dec 2013 22:51:06 +0000
Subject: [issue19950] Document that unittest.TestCase.__init__ is called once
 per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386715866.35.0.843697996352.issue19950@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm guessing it is that a new TestCase instance is instantiated each time an individual test is run.  I don't know that this is part of the API, though, so I'm not sure how it should be documented.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19950>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:00:59 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 10 Dec 2013 23:00:59 +0000
Subject: [issue19950] Document that unittest.TestCase.__init__ is called once
 per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386716459.39.0.138488876572.issue19950@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

This sentence seems to cover it: "Each instance of the TestCase will only be used to run a single test method, so a new fixture is created for each test."  from http://docs.python.org/2/library/unittest.html

The word "fixture" here is being used oddly, but that's the sentence.

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19950>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:07:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 23:07:05 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386688862.92.0.780191875027.issue19944@psf.upfronthosting.co.za>
Message-ID: <CADiSq7e47x_9qzkMUqp4ReSxqgtJ=FNFNY42HnxCkFGddfQWEA@mail.gmail.com>


Nick Coghlan added the comment:

They're fundamentally different operations though, with one being a single
step of the other. I just think "do the full lookup" should have the more
obvious name, with the "do a single level lookup" still as a public API,
but with the less obvious name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:07:40 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 10 Dec 2013 23:07:40 +0000
Subject: [issue19950] Document that unittest.TestCase.__init__ is called once
 per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386716860.57.0.0674795974148.issue19950@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

"Each instance of the TestCase will only be used to run a single test method, so a new fixture is created for each test."

Yes, this seems to be, but it is not clear what fixture means in this context (as in "the preparation needed to perform one or *more* tests"?). Perhaps enhancing the message a little will suffice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19950>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:11:10 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Dec 2013 23:11:10 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1386712412.3.0.864751342793.issue17576@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cNFAJLC_sFHrHw3ueb6_HzX_FXL3q=4jnFN5jScL455A@mail.gmail.com>


Nick Coghlan added the comment:

The ssize_t functions deliberately ignore lossy int conversions (e.g. from
floats) - that's why they only work on types that implement __index__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:30:43 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Tue, 10 Dec 2013 23:30:43 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386718243.11.0.395842172955.issue19846@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

Yes, it returns a list but unless I'm missing something in the general case it's the caller's responsibility to loop through the charsets to test for failure and try again.  This is not done automatically.

In the specific case we're talking about, first get_filename_charset() decides to only return the first entry in the list of charsets: list.https://git.gnome.org/browse/glib/tree/glib/gconvert.c#n1118

and then g_filename_to_utf8() disregards the charsets altogether because it sees that the filename is supposed to be utf-8 https://git.gnome.org/browse/glib/tree/glib/gconvert.c#n1160

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Wed Dec 11 00:49:35 2013
From: report at bugs.python.org (Michael Foord)
Date: Tue, 10 Dec 2013 23:49:35 +0000
Subject: [issue19950] Document that unittest.TestCase.__init__ is called once
 per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386719375.49.0.891723459818.issue19950@psf.upfronthosting.co.za>


Michael Foord added the comment:

I'd be happy with a doc change from "fixture" to instance (or maybe add instance in parentheses). I'd rather a simple change than making the documentation much longer.

The reason for a separate instance per test is for test isolation. Each test can create and modify instance attributes without them affecting other tests from the same class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19950>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:33:45 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 00:33:45 +0000
Subject: [issue18270] IDLE on OS X fails with Attribute Error if no initial
 shell and Tk out-of-date
In-Reply-To: <1371739202.98.0.896833417364.issue18270@psf.upfronthosting.co.za>
Message-ID: <3dfJzD5vqmz7Lk2@mail.python.org>


Roundup Robot added the comment:

New changeset 5becf8b612ee by Ned Deily in branch '2.7':
Issue #18270: Prevent possible IDLE AttributeError on OS X when no initial
http://hg.python.org/cpython/rev/5becf8b612ee

New changeset 016c64e66a9e by Ned Deily in branch '3.3':
Issue #18270: Prevent possible IDLE AttributeError on OS X when no initial
http://hg.python.org/cpython/rev/016c64e66a9e

New changeset 9d1fb265b88a by Ned Deily in branch 'default':
Issue #18270: merge from 3.3
http://hg.python.org/cpython/rev/9d1fb265b88a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18270>
_______________________________________

From report at bugs.python.org  Wed Dec 11 01:56:56 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2013 00:56:56 +0000
Subject: [issue18270] IDLE on OS X fails with Attribute Error if no initial
 shell and Tk out-of-date
In-Reply-To: <1371739202.98.0.896833417364.issue18270@psf.upfronthosting.co.za>
Message-ID: <1386723416.8.0.390589597936.issue18270@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the patch, Terry.  I've pushed a slightly modified version for release in 2.7.7, 3.3.4, and 3.4.0.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18270>
_______________________________________

From report at bugs.python.org  Wed Dec 11 03:09:20 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Dec 2013 02:09:20 +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: <1386727760.8.0.510071400806.issue17200@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Review comments added.  I don't really see why the fix should not be as trivial as:

diff -r ca9bca7aecda Lib/telnetlib.py
--- a/Lib/telnetlib.py  Tue Dec 10 16:06:46 2013 -0600
+++ b/Lib/telnetlib.py  Tue Dec 10 18:08:37 2013 -0800
@@ -312,7 +312,9 @@
             poller.register(self, poll_in_or_priority_flags)
             while i < 0 and not self.eof:
                 try:
-                    ready = poller.poll(call_timeout)
+                    # Poll takes its timeout in milliseconds.
+                    ready = poller.poll(None if timeout is None
+                                        else 1000 * call_timeout)
                 except select.error as e:
                     if e.errno == errno.EINTR:
                         if timeout is not None:
@@ -682,7 +684,8 @@
             poller.register(self, poll_in_or_priority_flags)
             while not m and not self.eof:
                 try:
-                    ready = poller.poll(call_timeout)
+                    ready = poller.poll(None if timeout is None
+                                        else 1000 * call_timeout)
                 except select.error as e:
                     if e.errno == errno.EINTR:
                         if timeout is not None:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Dec 11 03:10:31 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Dec 2013 02:10: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: <1386727831.59.0.23378803137.issue17200@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Dec 11 03:26:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 02:26:26 +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: <3dfMTF1GcXz7Lkt@mail.python.org>


Roundup Robot added the comment:

New changeset d61e8050b7d7 by Gregory P. Smith in branch '2.7':
Fixes Issue #17200: telnetlib's read_until and expect timeout was broken by the
http://hg.python.org/cpython/rev/d61e8050b7d7

New changeset 46186736e91c by Gregory P. Smith in branch '3.3':
Fixes Issue #17200: telnetlib's read_until and expect timeout was broken by the
http://hg.python.org/cpython/rev/46186736e91c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Dec 11 03:26:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 02:26:26 +0000
Subject: [issue14635] telnetlib uses select instead of poll - limited to
 FD_SETSIZE fds
In-Reply-To: <1334949623.77.0.295518189269.issue14635@psf.upfronthosting.co.za>
Message-ID: <3dfMTF6fG7z7Lkt@mail.python.org>


Roundup Robot added the comment:

New changeset d61e8050b7d7 by Gregory P. Smith in branch '2.7':
Fixes Issue #17200: telnetlib's read_until and expect timeout was broken by the
http://hg.python.org/cpython/rev/d61e8050b7d7

New changeset 46186736e91c by Gregory P. Smith in branch '3.3':
Fixes Issue #17200: telnetlib's read_until and expect timeout was broken by the
http://hg.python.org/cpython/rev/46186736e91c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14635>
_______________________________________

From report at bugs.python.org  Wed Dec 11 03:33:44 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 11 Dec 2013 02:33:44 +0000
Subject: [issue19941] python -m imports non-ASCII .py file without encoding
 declaration
In-Reply-To: <1386673497.85.0.313178291575.issue19941@psf.upfronthosting.co.za>
Message-ID: <1386729224.98.0.621184146529.issue19941@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

3.x is afflicted.

----------
nosy: +benjamin.peterson
versions: +Python 3.3, Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19941>
_______________________________________

From report at bugs.python.org  Wed Dec 11 04:09:13 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 Dec 2013 03:09:13 +0000
Subject: [issue15032] Provide a select.select implemented using select.poll
In-Reply-To: <1339102803.48.0.0979109123526.issue15032@psf.upfronthosting.co.za>
Message-ID: <1386731353.4.0.00435438893572.issue15032@psf.upfronthosting.co.za>


?ric Araujo added the comment:

This may be obsoleted by the new selectors module.

----------
nosy: +eric.araujo, neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15032>
_______________________________________

From report at bugs.python.org  Wed Dec 11 05:35:31 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Dec 2013 04:35:31 +0000
Subject: [issue15032] Provide a select.select implemented using select.poll
In-Reply-To: <1339102803.48.0.0979109123526.issue15032@psf.upfronthosting.co.za>
Message-ID: <1386736531.84.0.180456460808.issue15032@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15032>
_______________________________________

From report at bugs.python.org  Wed Dec 11 05:37:45 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Dec 2013 04:37:45 +0000
Subject: [issue12029] Catching virtual subclasses in except clauses
In-Reply-To: <1304844823.89.0.48444500115.issue12029@psf.upfronthosting.co.za>
Message-ID: <1386736665.99.0.348645555785.issue12029@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, you're right - I found the example I was thinking of (Richard Jones's "Don't do this!" talk), and it was just demonstrating that the except clause accepts any expressions producing a tuple or BaseException instance, not that we call __iter__ at that point.

And since we do identity checks for the exception type matching (rather than equality checks), it looks like all the avenues for arbitrary code execution while checking if an exception handler matches a thrown an exception are closed off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12029>
_______________________________________

From report at bugs.python.org  Wed Dec 11 06:17:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 05:17:20 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <3dfRGR49LWz7Lkn@mail.python.org>


Roundup Robot added the comment:

New changeset e961a166dc70 by Eric Snow in branch 'default':
Issue #18864: Add a setter for ModuleSpec.has_location.
http://hg.python.org/cpython/rev/e961a166dc70

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Wed Dec 11 06:27:52 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 05:27:52 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1386739672.93.0.453525053373.issue19700@psf.upfronthosting.co.za>


Eric Snow added the comment:

patch LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Wed Dec 11 06:59:24 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 05:59:24 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386741564.68.0.728669153183.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

As a testament to counter-intuitive API, I did not even realize this about either find_loader() or find_spec() until the bug the other day with reloading submodules.  So I'm on board!

As to the best approach, I'll argue for keeping just 1 function.  I tried out both ways and in the 2 function approach they simply didn't seem different enough.  I've attached a patch (w/o tests, etc.) to show what I'm thinking.

Basically, let's make the "path" parameter keyword-only and rename it to "parent_path" (maybe even "precomputed_parent_path").  The patch takes cues from pkgutil.find_loader().

----------
keywords: +patch
nosy: +eric.snow
Added file: http://bugs.python.org/file33087/issue19944-find-spec-parent-module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:02:59 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 06:02:59 +0000
Subject: [issue19701] Update multiprocessing for PEP 451
In-Reply-To: <1385138043.59.0.905087765846.issue19701@psf.upfronthosting.co.za>
Message-ID: <1386741779.59.0.257505057671.issue19701@psf.upfronthosting.co.za>


Eric Snow added the comment:

This came up in issue19946.

----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19701>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:06:10 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 06:06:10 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386741970.53.0.812080019396.issue19946@psf.upfronthosting.co.za>


Eric Snow added the comment:

There is definitely room for improvement relative to module specs and __main__ (that's the topic of issue #19701).  That issue is waiting for __main__ to get a proper spec (see issues #19700 and #19697).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:35:57 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 06:35:57 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1386743757.69.0.198332860965.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a patch for the deprecations (and API additions) in the importlib docs.

----------
keywords: +patch
Added file: http://bugs.python.org/file33088/issue19713-importlib-docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Wed Dec 11 07:38:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 06:38:39 +0000
Subject: [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1386743919.6.0.699477720859.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've attached a patch to issue19713 (file33088) that adds documentation for the new APIs.  Also, there were some good reviews in issue18864 (especially for file32381) that never got fully addressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19710>
_______________________________________

From report at bugs.python.org  Wed Dec 11 08:18:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 07:18:14 +0000
Subject: [issue17200] telnetlib.read_until() timeout uses the wrong units
In-Reply-To: <1386727760.8.0.510071400806.issue17200@psf.upfronthosting.co.za>
Message-ID: <7351013.Q6oZsJTtFY@raxxla>


Serhiy Storchaka added the comment:

> Review comments added.

Only original author can answer your questions.

>  I don't really see why the fix should not be as trivial as:

Yes, these are simple and obvious, and only changes which I understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Dec 11 08:34:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 07:34:48 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386747288.28.0.756541927862.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The ssize_t functions deliberately ignore lossy int conversions (e.g. from
> floats) - that's why they only work on types that implement __index__.

They ignore __index__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 08:37:09 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 Dec 2013 07:37:09 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386747429.05.0.533730294119.issue17576@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Yes, the PyLong_As... conversions are a mess.  In theory, they should all use __index__ if available, and ignore __int__.  In practice, it's a mess that's difficult to change without breaking things.  I think there are already some other issues open on this subject.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:08:24 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 11 Dec 2013 08:08:24 +0000
Subject: [issue19950] Document that unittest.TestCase.__init__ is called once
 per test
In-Reply-To: <1386714858.72.0.878231586551.issue19950@psf.upfronthosting.co.za>
Message-ID: <1386749304.46.0.237838847029.issue19950@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

How about the following:

"Each instance of the TestCase will only be used to run a single test method from it, so a new instance is created for each test method."


It replaces `fixture` with `instance` and it emphasizes that the called method belongs to that particular TestCase instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19950>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:22:56 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 11 Dec 2013 08:22:56 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386750176.75.0.373702338596.issue19717@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch with Windows support. I notice there is difference regarding resolving symbolic link with parent dir (linkA/..) between Posix and Windows.

On Windows, if linkY points to dirB, 'dirA\linkY\..' resolves to 'dirA' without resolving linkY first. It means, Windows resolves parent dir first before symbolic link.

C:\Users\vajrasky\Code\playplay\pycode>mkdir dirA

C:\Users\vajrasky\Code\playplay\pycode>mkdir dirB

C:\Users\vajrasky\Code\playplay\pycode>cd dirA

C:\Users\vajrasky\Code\playplay\pycode\dirA>mklink /D linkC ..\dirB
symbolic link created for linkC <<===>> ..\dirB

C:\Users\vajrasky\Code\playplay\pycode\dirA>cd ..\

C:\Users\vajrasky\Code\playplay\pycode>cd dirA\linkC\..

C:\Users\vajrasky\Code\playplay\pycode\dirA>

But on Posix, if linkY points to dirB, 'dirA\linkY\..' resolves to 'dirB\..' then to the parent dir of dirB. It means, Posix resolves symbolic link first before parent dir.

$ mkdir dirA
$ mkdir dirB
$ cd dirA
$ ln -s ../dirB linkC
$ cd ..
$ ls dirA/linkC/..
dirA    dirB

----------
Added file: http://bugs.python.org/file33089/add_non_strict_resolve_pathlib_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:23:36 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 11 Dec 2013 08:23:36 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386750216.02.0.590650291967.issue19717@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33089/add_non_strict_resolve_pathlib_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:23:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 11 Dec 2013 08:23:44 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386750224.31.0.578416469504.issue19717@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33090/add_non_strict_resolve_pathlib_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:33:17 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Wed, 11 Dec 2013 08:33:17 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386750797.57.0.0628890943333.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

I agree that a failure to lookup the module should raise an explicit exception.

> Second, there is no way that 'nosetests' will ever succeed as an import since, as Oliver pointed out, it doesn't end in '.py' or any other identifiable way for a finder to know it can handle the file. So this is not a bug and simply a side-effect of how import works. The only way around it would be to symlink nosetests to nosetests.py or to somehow pre-emptively set up 'nosetests' for supported importing.

I don't agree that (unix) Python programs that don't end with ".py" should be modified to have multiprocessing work correctly. I think it should be the multiprocessing responsibility to transparently find out how to spawn the new process independently of the fact that the program ends in '.py' or not.

Note: the fork mode works always under unix (with or without the ".py" extension). The spawn mode always work under windows as AFAIK there is no way to have Python programs that don't end in .py under windows and furthermore I think multiprocessing does execute the __main__ under windows (but I haven't tested if it's still the case in Python HEAD).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:41:19 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Wed, 11 Dec 2013 08:41:19 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386751279.06.0.98550313741.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

> what is sys.modules['__main__'] and sys.modules['__main__'].__file__ if you run under nose?

$ cat check_stuff.py 
import sys

def test_main():
    print("sys.modules['__main__']=%r"
          % sys.modules['__main__'])
    print("sys.modules['__main__'].__file__=%r"
          % sys.modules['__main__'].__file__)


if __name__ == '__main__':
    test_main()
(pyhead) ogrisel at is146148:~/tmp$ python check_stuff.py 
sys.modules['__main__']=<module '__main__' from 'check_stuff.py'>
sys.modules['__main__'].__file__='check_stuff.py'
(pyhead) ogrisel at is146148:~/tmp$ nosetests -s check_stuff.py 
sys.modules['__main__']=<module '__main__' from '/volatile/ogrisel/envs/pyhead/bin/nosetests'>
sys.modules['__main__'].__file__='/volatile/ogrisel/envs/pyhead/bin/nosetests'
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:44:37 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Wed, 11 Dec 2013 08:44:37 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386751477.72.0.180159545098.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

Note however that the problem is not specific to nose. If I rename my initial 'check_forserver.py' script to 'check_forserver', add the '#!/usr/bin/env python' header and make it 'chmod +x' I get the same crash.

So the problem is related to the fact that under posix, valid Python programs can be executable scripts without the '.py' extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Wed Dec 11 09:59:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 08:59:39 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386752379.75.0.81517086335.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyLong_AsUnsignedLong() and PyLong_AsLong() can return different values for same object. Why __int__ and __index__ should be used for int subclasses at all? I'm not sure this is right solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:03:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 09:03:43 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1386752623.83.0.811986554104.issue19717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think a patch in issue19887 first should be committed. It totally rewrites resolve().

----------
dependencies: +Path.resolve() fails on complex symlinks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Wed Dec 11 10:52:56 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Wed, 11 Dec 2013 09:52:56 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386755576.26.0.691843445998.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

Here is a patch that uses `imp.load_source` when the first importlib name-based lookup fails.

Apparently it fixes the issue on my box but I am not sure whether this is the correct way to do it.

----------
keywords: +patch
Added file: http://bugs.python.org/file33091/issue19946.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:13:05 2013
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Glondu?=)
Date: Wed, 11 Dec 2013 10:13:05 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386756785.72.0.216789392807.issue19948@psf.upfronthosting.co.za>


St?phane Glondu added the comment:

> What platform is this on?

I'm on Linux (Debian testing).

> Looking quickly through posix.execve (which is what I think gets called), it looks like it just calls C's execve().

Yes, but I'm talking about os.execvp, here. With the search in PATH.

> Also, what's your use case for this?

I discovered that by accident while investigating another bug...

> I realize it might be a standard behavior, but it seems like a bad idea to me.

What is the bad idea? Keep looking in subsequent directories in PATH when you find a candidate for which execve() fails? Sorry, but I beg to differ, and POSIX is on my side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:14:42 2013
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Glondu?=)
Date: Wed, 11 Dec 2013 10:14:42 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386756882.54.0.708584488934.issue19948@psf.upfronthosting.co.za>


St?phane Glondu added the comment:

> What is the bad idea? Keep looking in subsequent directories in PATH when you find a candidate for which execve() fails? Sorry, but I beg to differ, and POSIX is on my side.

Sorry, I meant "Stop looking in subsequent [..]".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Wed Dec 11 11:42:12 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 11 Dec 2013 10:42:12 +0000
Subject: [issue19942] UTF-8 encoding not enforced
In-Reply-To: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>
Message-ID: <1386758532.74.0.1709983981.issue19942@psf.upfronthosting.co.za>


Jakub Wilk added the comment:

With a slightly adapted test case, I see the same behavior in Python 3.3.3. Perhaps it would be worth fixing the bug in Python 3.4?

----------
Added file: http://bugs.python.org/file33092/test3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Wed Dec 11 12:42:35 2013
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 11 Dec 2013 11:42:35 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1386762155.1.0.0809981516537.issue19100@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

This is not the fault of pprint. IMHO it doesn't make sense to fix anything here, at least not for pprint specifically. print() has the same "problem":

   $ LANG= ./python -c "print('\u20ac')"                                                                                                                     
   Traceback (most recent call last):
     File "<string>", line 1, in <module>
   UnicodeEncodeError: 'ascii' codec can't encode character '\u20ac' in position 0: ordinal not in range(128)

----------
nosy: +doerwalter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Wed Dec 11 13:27:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Dec 2013 12:27:37 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386741564.68.0.728669153183.issue19944@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eG+0E8p6DPxo1e_KbLm6=ckfuUUVg1W=VG+=Jzauyn1w@mail.gmail.com>


Nick Coghlan added the comment:

One function (the current one) promises not to import anything. The other
(the new one) may have side effects, even if it fails to find the module
(any successfully imported parent modules will remain imported).

IIRC, that "no side effects" guarantee was the original reason for the
find_loader/get_loader split and it's a distinction I think is worth
preserving. I just think the obvious name should be closer to
importlib.import_module in semantics, with the "no side effects" version
being the more obscure one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Wed Dec 11 13:34:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Dec 2013 12:34:41 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386755576.26.0.691843445998.issue19946@psf.upfronthosting.co.za>
Message-ID: <CADiSq7euwR5P3=xEEe5S1eF0=d7CkLBWkWxyaUn--V1iyCuidg@mail.gmail.com>


Nick Coghlan added the comment:

Rerunning main in the subprocess has always been a slightly dubious feature
of multiprocessing, but IIRC it's a necessary hack to ensure pickle
compatibility for things defined in __main__. Using "runpy.run_path" would
be a better solution, but we'll need to add the "target" parameter that
missed the beta1 deadline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Wed Dec 11 14:25:49 2013
From: report at bugs.python.org (Filip Zyzniewski)
Date: Wed, 11 Dec 2013 13:25:49 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
 inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1386768349.32.0.164713986829.issue4037@psf.upfronthosting.co.za>


Filip Zyzniewski added the comment:

It seems like there is also an issue with property classes defined in a different module.

In the example below Foo.x uses standard property, and Foo.y uses prop imported from the prop module.

This results in docstring for Foo.y to be missed:

filip at klocek:~/test$ cat prop.py
class prop(property):
    pass
filip at klocek:~/test$ cat foo.py
from prop import prop

class Foo(object):

    @property
    def x(self):
        """
        >>> Foo().x
        'x'
        """
        return 'x'

    @prop
    def y(self):
        """
        >>> Foo().y
        'y'
        """
        return 'y'
filip at klocek:~/test$ python --version
Python 2.7.3
filip at klocek:~/test$ python -m doctest foo.py -v
Trying:
    Foo().x
Expecting:
    'x'
ok
2 items had no tests:
    foo
    foo.Foo
1 items passed all tests:
   1 tests in foo.Foo.x
1 tests in 3 items.
1 passed and 0 failed.
Test passed.
filip at klocek:~/test$ python3 --version
Python 3.2.3
filip at klocek:~/test$ python3 -m doctest foo.py -v
Trying:
    Foo().x
Expecting:
    'x'
ok
2 items had no tests:
    foo
    foo.Foo
1 items passed all tests:
   1 tests in foo.Foo.x
1 tests in 3 items.
1 passed and 0 failed.
Test passed.
filip at klocek:~/test$

----------
nosy: +filip.zyzniewski

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4037>
_______________________________________

From report at bugs.python.org  Wed Dec 11 15:02:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Dec 2013 14:02:17 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
 inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1386770537.82.0.985028017228.issue4037@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/issue4037>
_______________________________________

From report at bugs.python.org  Wed Dec 11 15:17:06 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 11 Dec 2013 14:17:06 +0000
Subject: [issue19942] UTF-8 encoding not enforced
In-Reply-To: <1386676139.88.0.227932494666.issue19942@psf.upfronthosting.co.za>
Message-ID: <1386771426.43.0.937660582997.issue19942@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution: wont fix -> 
status: closed -> open
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19942>
_______________________________________

From report at bugs.python.org  Wed Dec 11 15:40:50 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 11 Dec 2013 14:40:50 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386772850.53.0.934686698105.issue19944@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm not saying get rid of the ability to guarantee no side-effects. All I'm saying is that the point of the function is to find a spec, whether that includes importing or implicitly using a parent package from sys.modules is just technical detail (and thus flags on the function). Put another way, the return value is no different and the basic arguments are the same, it's just internal details of how that return value is found that shifts. For me that's enough to control with keyword-only arguments instead of uniquely named functions.

And I'm willing to argue that import_module() not importing parent packages is annoying and should be controlled with a flag to make life easier since chances are you will want to import the parent packages anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:07:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 15:07:02 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1386774422.0.0.170498744043.issue19100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

pprint is not print.

>>> print('\u20ac')
?
>>> import pprint; pprint.pprint('\u20ac')
'?'

Default sys.displayhook doesn't fail on unencodable output.

$ LANG=C ./python
Python 3.4.0b1 (default:e961a166dc70+, Dec 11 2013, 13:57:17) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> '\u20ac'
'\u20ac'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:10:37 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 11 Dec 2013 15:10:37 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386774637.38.0.0728456734232.issue19948@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

os.execvp calls os._execvpe which calls posix.execv which calls execv. At least that's how I think it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:23:52 2013
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Glondu?=)
Date: Wed, 11 Dec 2013 15:23:52 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386775432.65.0.104974096397.issue19948@psf.upfronthosting.co.za>


St?phane Glondu added the comment:

> os.execvp calls os._execvpe which calls posix.execv which calls execv. At least that's how I think it works.

I am not contesting that. This bug is about the "search the command in PATH" part. More precisely, the fact that os.execvp continues the search after execv fails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Wed Dec 11 16:26:00 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 11 Dec 2013 15:26:00 +0000
Subject: [issue19948] POSIX semantics of PATH search in execvpe is not
 respected
In-Reply-To: <1386687325.82.0.275504904763.issue19948@psf.upfronthosting.co.za>
Message-ID: <1386775560.21.0.416830523039.issue19948@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I know that. This is mostly just a note to myself so I can remember what I've looked at the next time I have a few moments to look at the bug. Or, anyone else who wants to track it down.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19948>
_______________________________________

From report at bugs.python.org  Wed Dec 11 17:14:48 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 11 Dec 2013 16:14:48 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1386778488.1.0.43774223217.issue19100@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at gmail.com>:


----------
assignee:  -> fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Wed Dec 11 18:16:19 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 17:16:19 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1386782179.0.0.610171128004.issue18864@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
dependencies:  -Implement _imp.exec_builtin and exec_dynamic

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Wed Dec 11 18:21:21 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 17:21:21 +0000
Subject: [issue19714] Add tests for importlib.machinery.WindowsRegistryFinder
In-Reply-To: <1385139731.13.0.379714643713.issue19714@psf.upfronthosting.co.za>
Message-ID: <1386782481.39.0.0860539512357.issue19714@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19714>
_______________________________________

From report at bugs.python.org  Wed Dec 11 19:11:45 2013
From: report at bugs.python.org (David Pizzuto)
Date: Wed, 11 Dec 2013 18:11:45 +0000
Subject: [issue19951] parse_qsl fails on empty query argument without =
Message-ID: <1386785505.13.0.692994563437.issue19951@psf.upfronthosting.co.za>


New submission from David Pizzuto:

Using an empty query argument with no = fails in urlparse.parse_qsl. Chrome and Firefox accept it without the =, so a navigation to google.com/search?q=foo&bar appears in the address bar as google.com/search?q=foo&bar=. Neither RFC 1738 nor RFC 3986 define the format of query strings. Wikipedia is similarly silent.

I can reproduce in 2.7.3 and 3.2.3, as shown below. I'm told this is also true of 3.3 but don't have easy access to a 3.3 interpreter to confirm.

The obvious workaround is to simply set strict_parsing=False, but I don't know what other checks that's disabling. Would it be reasonable to change parse_qsl to add the = if it's not present?

$ python
Python 2.7.3 (default, Sep 26 2013, 20:03:06) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlparse
>>> query = 'foo&bar=baz'
>>> urlparse.parse_qs(query, strict_parsing=True, keep_blank_values=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urlparse.py", line 353, in parse_qs
    for name, value in parse_qsl(qs, keep_blank_values, strict_parsing):
  File "/usr/lib/python2.7/urlparse.py", line 387, in parse_qsl
    raise ValueError, "bad query field: %r" % (name_value,)
ValueError: bad query field: 'foo'

$ python3
Python 3.2.3 (default, Sep 25 2013, 18:22:43) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.parse
>>> query = 'foo&bar=baz'
>>> urllib.parse.parse_qs(query, strict_parsing=True, keep_blank_values=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/urllib/parse.py", line 556, in parse_qs
    encoding=encoding, errors=errors)
  File "/usr/lib/python3.2/urllib/parse.py", line 596, in parse_qsl
    raise ValueError("bad query field: %r" % (name_value,))
ValueError: bad query field: 'foo'

----------
messages: 205911
nosy: David.Pizzuto
priority: normal
severity: normal
status: open
title: parse_qsl fails on empty query argument without =
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19951>
_______________________________________

From report at bugs.python.org  Wed Dec 11 19:28:29 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 11 Dec 2013 18:28:29 +0000
Subject: [issue15027] Faster UTF-32 encoding
In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za>
Message-ID: <1386786508.99.0.732136988499.issue15027@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

>From http://kmike.ru/python-data-structures/ under heading DATrie "Python wrapper uses utf_32_le codec internally; this codec is currently slow and it is the bottleneck for datrie. There is a ticket with a patch in the CPython bug tracker (http://bugs.python.org/issue15027) that should make this codec fast, so there is a hope datrie will become faster with future Pythons."

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15027>
_______________________________________

From report at bugs.python.org  Wed Dec 11 19:43:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Dec 2013 18:43:06 +0000
Subject: [issue19951] parse_qsl fails on empty query argument without =
In-Reply-To: <1386785505.13.0.692994563437.issue19951@psf.upfronthosting.co.za>
Message-ID: <1386787386.37.0.743445385754.issue19951@psf.upfronthosting.co.za>


R. David Murray added the comment:

I did some research on this for a previous issue, and every description of query strings I could find agreed that the format was '<name>=<value>'.  That is, that the '=' is not optional, even though some servers (note, *not* browsers, they just transmit or display the URI provided by the user or server) will accept parameters without the '=' and treat them as if they had one.

So I think this being rejected by strict_parsing is correct.  I'm closing this as invalid.

As for what strict_parsing, controls, you can check the source.  It looks like this and empty arguments (ie: &&) are the only things it controls.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19951>
_______________________________________

From report at bugs.python.org  Wed Dec 11 19:57:12 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 11 Dec 2013 18:57:12 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386788232.59.0.0828260401165.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Re-uploaded the patch to remove duplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Wed Dec 11 20:26:25 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 Dec 2013 19:26:25 +0000
Subject: [issue19732] python fails to build when configured with
 --with-system-libmpdec
In-Reply-To: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za>
Message-ID: <1386789985.5.0.927606482142.issue19732@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Antoine, could you add --with-system-libmpdec to my FreeBSD and Fedora
bots? Sorry for bothering you with all these obscure options. :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19732>
_______________________________________

From report at bugs.python.org  Wed Dec 11 20:28:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 19:28:18 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <3dfp8L02D1z7Llb@mail.python.org>


Roundup Robot added the comment:

New changeset 618cca51a27e by Serhiy Storchaka in branch '3.3':
Issue #17576: Deprecation warning emitted now when __int__() or __index__()
http://hg.python.org/cpython/rev/618cca51a27e

New changeset 59fb79d0411e by Serhiy Storchaka in branch 'default':
Issue #17576: Deprecation warning emitted now when __int__() or __index__()
http://hg.python.org/cpython/rev/59fb79d0411e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 20:42:22 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Dec 2013 19:42:22 +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: <1386790942.62.0.476580241999.issue17200@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

anyways, i went with just the simple fix and no specific test for this issue as the tests were painful and questionable reliability.

i appreciate the other refactoring suggestion within the code but for 2.7 and 3.3 bugfixes where no significant changes are ever likely within telnetlib.py they didn't seem warranted.  3.4's code is cleaner thanks to the new selector stuff.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17200>
_______________________________________

From report at bugs.python.org  Wed Dec 11 20:55:13 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 Dec 2013 19:55:13 +0000
Subject: [issue19952] asyncio: test_wait_for_handle failure
Message-ID: <1386791713.28.0.425891775188.issue19952@psf.upfronthosting.co.za>


New submission from Stefan Krah:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/3601/steps/test/logs/stdio


======================================================================
FAIL: test_wait_for_handle (test.test_asyncio.test_windows_events.ProactorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_asyncio\test_windows_events.py", line 123, in test_wait_for_handle
    self.assertTrue(0 <= elapsed < 0.02, elapsed)
AssertionError: False is not true : 0.09299999999348074

----------
components: Tests
messages: 205918
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: asyncio: test_wait_for_handle failure
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19952>
_______________________________________

From report at bugs.python.org  Wed Dec 11 20:56:25 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 Dec 2013 19:56:25 +0000
Subject: [issue19952] asyncio: test_wait_for_handle failure
In-Reply-To: <1386791713.28.0.425891775188.issue19952@psf.upfronthosting.co.za>
Message-ID: <1386791785.42.0.846954787234.issue19952@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19952>
_______________________________________

From report at bugs.python.org  Wed Dec 11 21:02:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 20:02:12 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386792132.28.0.121459857512.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I first committed safe part of patch, which doesn't change behavior, only adds warnings and tests. Here is other part (very simple), which change behavior (in sum they are equal to issue17576_v3.patch with minor changes).

* PyNumber_Index() now calls __index__() for int subclasses.

>>> class A(int):
...     def __index__(self): return 1
... 
>>> import operator
>>> operator.index(A())

Returns 0 without patch and 1 with patch.

* PyNumber_Long() now calls __int__() on result of __trunc__() if it is int subclass instance.

>>> class A:
...     def __trunc__(self): return True
... 
>>> int(A())

Returns True without patch and 1 with patch.

* PyLong_As*() functions (but not all) call __int__() for int subclasses (I'm not sure this is right).

>>> class A(int):
...     def __int__(self): return 42
... 
>>> chr(A(43))

Returns '+' without patch and '*' with patch.

----------
Added file: http://bugs.python.org/file33093/issue17576_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 21:13:08 2013
From: report at bugs.python.org (ferno)
Date: Wed, 11 Dec 2013 20:13:08 +0000
Subject: [issue19953] __iadd__() doc not strictly correct
Message-ID: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za>


New submission from ferno:

Document in question is:

    http://docs.python.org/3.3/reference/datamodel.html#object.__iadd__

The documentation states,

    to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x.__iadd__(y) is called.

However, this doesn't appear to be strictly true. According to this, the following well-known example:

    >>> a = (1, [2, 3])
    >>> a[1] += [4, 5]
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a
    (1, [2, 3, 4, 5])

should give the same behaviour as:

    >>> a = (1, [2, 3])
    >>> a[1].__iadd__([4, 5])
    [2, 3, 4, 5]
    >>> a
    (1, [2, 3, 4, 5])

However, this snippet DOES give the identical behaviour:

    >>> a = (1, [2, 3])
    >>> a[1] = a[1].__iadd__([4, 5])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'tuple' object does not support item assignment
    >>> a
    (1, [2, 3, 4, 5])

which leads me to suggest that this line of the documentation should be adjusted to read:

    to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x = x.__iadd__(y) is called.

This fix would incidentally harmonise with the documentation for operator.iadd() et al., (http://docs.python.org/3.3/library/operator.html#operator.iadd), which had a similar problem but was corrected following issue 7259 (http://bugs.python.org/issue7259), now reading:

    a = iadd(a, b) is equivalent to a += b.

----------
assignee: docs at python
components: Documentation
messages: 205920
nosy: docs at python, ferno
priority: normal
severity: normal
status: open
title: __iadd__() doc not strictly correct
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/issue19953>
_______________________________________

From report at bugs.python.org  Wed Dec 11 21:20:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 20:20:57 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1386793257.06.0.346996576714.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Even with last patch int() can return non-int:

>>> class A(int):
...     def __int__(self): return True
...     def __repr__(self): return '<A>'
... 
>>> class B:
...     def __int__(self): return A()
... 
>>> class C:
...     def __trunc__(self): return A()
... 
>>> int(B())
<A>
>>> int(C())
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Wed Dec 11 21:28:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 20:28:05 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386793685.98.0.404639809481.issue18983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Besides too long line with sys.stderr.write last patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Wed Dec 11 21:29:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 20:29:34 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386793774.49.0.649127571575.issue18983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, I forgot. This feature should be documented in Doc/library/timeit.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Wed Dec 11 21:35:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 Dec 2013 20:35:28 +0000
Subject: [issue19732] python fails to build when configured with
 --with-system-libmpdec
In-Reply-To: <1386789985.5.0.927606482142.issue19732@psf.upfronthosting.co.za>
Message-ID: <1386794125.2323.0.camel@fsol>


Antoine Pitrou added the comment:

> Antoine, could you add --with-system-libmpdec to my FreeBSD and Fedora
> bots? Sorry for bothering you with all these obscure options. :)

Should be done now. Can you check they work fine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19732>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:26:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Dec 2013 21:26:19 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
Message-ID: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>


New submission from R. David Murray:

A while ago I started getting a floating point exception from test_tk in the tip in all active versions, but I'm only now getting around to reporting it.  I've tracked this down to the tests introduced in issue 19085, which it looks like revealed some other tk issues.

Gentoo has some patches against stock 8.6.1; I don't know if they are the source of the failure or not.  I haven't updated the gentoo buildbots for a while, and since they are passing the tests it could well be that it was my upgrade from tk 8.6.0 to 8.6.1 on my dev box that triggered the failures.  The timing of that upgrade is somewhat after the patch was committed, but I hadn't been running the test suite regularly during that interval so I can't pinpoint it to one or the other.

There are also other test failures, by the way, but I'm not seeing the tracebacks because python crashes.

Here is the faulthandler traceback from 3.3:

test_indicatoron (tkinter.test.test_tkinter.test_widgets.MenubuttonTest) ... Fatal Python error: Floating point exception

Current thread 0xb75416c0:
  File "/home/rdmurray/python/p33/Lib/tkinter/__init__.py", line 1257 in _configure
  File "/home/rdmurray/python/p33/Lib/tkinter/__init__.py", line 1266 in configure
  File "/home/rdmurray/python/p33/Lib/tkinter/__init__.py", line 1273 in __setitem__
  File "/home/rdmurray/python/p33/Lib/tkinter/test/widget_tests.py", line 47 in checkParam
  File "/home/rdmurray/python/p33/Lib/tkinter/test/widget_tests.py", line 116 in checkBooleanParam
  File "/home/rdmurray/python/p33/Lib/tkinter/test/widget_tests.py", line 422 in test_indicatoron
  File "/home/rdmurray/python/p33/Lib/unittest/case.py", line 384 in _executeTestPart
  File "/home/rdmurray/python/p33/Lib/unittest/case.py", line 439 in run
  File "/home/rdmurray/python/p33/Lib/unittest/case.py", line 491 in __call__
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 105 in run
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 67 in __call__
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 105 in run
  File "/home/rdmurray/python/p33/Lib/unittest/suite.py", line 67 in __call__
  File "/home/rdmurray/python/p33/Lib/test/support/__init__.py", line 1560 in run
  File "/home/rdmurray/python/p33/Lib/test/support/__init__.py", line 1661 in _run_suite
  File "/home/rdmurray/python/p33/Lib/test/support/__init__.py", line 1695 in run_unittest
  File "/home/rdmurray/python/p33/Lib/test/test_tk.py", line 22 in test_main
  File "/home/rdmurray/python/p33/Lib/test/regrtest.py", line 1222 in runtest_inner
  File "/home/rdmurray/python/p33/Lib/test/regrtest.py", line 944 in runtest
  File "/home/rdmurray/python/p33/Lib/test/regrtest.py", line 717 in main
  File "/home/rdmurray/python/p33/Lib/test/__main__.py", line 13 in <module>
  File "/home/rdmurray/python/p33/Lib/runpy.py", line 73 in _run_code
  File "/home/rdmurray/python/p33/Lib/runpy.py", line 160 in _run_module_as_main
zsh: floating point exception  ./python -m test -uall test_tk

----------
components: Tests, Tkinter
messages: 205925
nosy: Arfrever, r.david.murray, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: test_tk floating point exception on my gentoo box running tk 8.6.1
type: crash
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:30:46 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 11 Dec 2013 21:30:46 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1386797446.82.0.295858431485.issue19828@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Looking more closely, there's not much that looks like it really should be tested if explicitly called with -S, so perhaps the toplevel skip is still best after all.  Any other thoughts?

Attached patch fixes `python -S Lib/test` and cleans up an unused import. I'm a bit iffy on the added comment.

----------
Added file: http://bugs.python.org/file33094/issue19828.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19828>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:31:09 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Dec 2013 21:31:09 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386772850.53.0.934686698105.issue19944@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dya0+dqrDNvqQaP03fNEh1m-A5AkBe+Am8ehTFkmCwpw@mail.gmail.com>


Nick Coghlan added the comment:

Look at it from a conceptual point of view, though, there are two quite
different operations:

- find a spec at the current level, using the specified path (which may be
empty, implying a top level import)
- find a spec according to the full import cycle, including any parent
module imports

When you call it, you're going to want one behaviour or the other, since
the two operations are not slight variants, they have major conceptual
differences (with one being a substep of the other).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:43:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Dec 2013 21:43:47 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1386798227.65.0.0299972177988.issue19828@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would just change the comment to "it is not useful to run the tests if we were called with -S".  Otherwise it looks fine.

If someone adds tests that are meaningful with -S is specified, we can put them in a different class, and move the skip to the class level.  You could mention that in the comment as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19828>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:48:04 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Dec 2013 21:48:04 +0000
Subject: [issue19934] collections.Counter.most_common does not document `None`
 as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1386798484.58.0.648030597758.issue19934@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19934>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:52:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 21:52:36 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <3dfsLr100yz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset d842bc07d30b by R David Murray in branch '3.3':
#19063: partially fix set_payload handling of non-ASCII string input.
http://hg.python.org/cpython/rev/d842bc07d30b

New changeset 02cb48459b58 by R David Murray in branch 'default':
Null merge for #19063 (3.4 fix is different).
http://hg.python.org/cpython/rev/02cb48459b58

New changeset e20f98a8ed71 by R David Murray in branch 'default':
#19063: fix set_payload handling of non-ASCII string input.
http://hg.python.org/cpython/rev/e20f98a8ed71

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:54:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 Dec 2013 21:54:34 +0000
Subject: [issue19063] Python 3.3.3 encodes emails containing non-ascii data as
 7bit
In-Reply-To: <1379791348.59.0.547034800598.issue19063@psf.upfronthosting.co.za>
Message-ID: <1386798874.12.0.726231034152.issue19063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, it's a fair while after "tomorrow", but now it is committed.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19063>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:56:36 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 11 Dec 2013 21:56:36 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1386798996.92.0.587383149498.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Updated documentation and fixed a few lines that were too long.

----------
Added file: http://bugs.python.org/file33095/issue18983_v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:57:34 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 Dec 2013 21:57:34 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386799054.95.0.365973611595.issue16669@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16669>
_______________________________________

From report at bugs.python.org  Wed Dec 11 22:58:59 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 Dec 2013 21:58:59 +0000
Subject: [issue19732] python fails to build when configured with
 --with-system-libmpdec
In-Reply-To: <1386794125.2323.0.camel@fsol>
Message-ID: <20131211215859.GA10179@sleipnir.bytereef.org>


Stefan Krah added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> Should be done now. Can you check they work fine?

Thank you! Works OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19732>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:09:12 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 Dec 2013 22:09:12 +0000
Subject: [issue19732] python fails to build when configured with
 --with-system-libmpdec
In-Reply-To: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za>
Message-ID: <1386799752.74.0.0778358827107.issue19732@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Matthias, my target is to release mpdecimal-2.4 on January 9th 2014.
I saw that you started to package mpdecimal-2.3:

    http://packages.debian.org/pt/source/sid/misc/mpdecimal

I hope that it can be changed to 2.4:  Packaging 2.3 would create
some confusion, since one or two functions are not binary compatible
with 2.4 and of course 2.3 cannot be used for Python.

Starting from 2.4, the remainder of the 2.x.y series will stay
binary (and decimal.py) compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19732>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:17:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 22:17:02 +0000
Subject: [issue15027] Faster UTF-32 encoding
In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za>
Message-ID: <1386800222.06.0.983066228127.issue15027@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch, synchronized with trunk. UTF-32 encoder now checks surrogates and therefore speedup is less (only up to 5 times). But this compensates regression in 3.4.

On 32-bit Linux, Intel Atom N570 @ 1.66GHz:

Py3.3        Py3.4        patched

531 (+245%)  489 (+274%)  1831   encode  utf-32le  'A'*10000
383 (+158%)  223 (+344%)  990    encode  utf-32le  '\u0100'*10000
325 (+262%)  229 (+414%)  1177   encode  utf-32le  '\U00010000'*10000

544 (+166%)  494 (+193%)  1448   encode  utf-32be  'A'*10000
384 (+67%)   223 (+188%)  642    encode  utf-32be  '\u0100'*10000
323 (+108%)  229 (+193%)  671    encode  utf-32be  '\U00010000'*10000

----------
Added file: http://bugs.python.org/file33096/encode_utf32_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15027>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:28:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 22:28:14 +0000
Subject: [issue19928] Implement cell repr test
In-Reply-To: <1386492520.71.0.633651431528.issue19928@psf.upfronthosting.co.za>
Message-ID: <1386800894.74.0.491218276332.issue19928@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Zachary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19928>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:30:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 22:30:47 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1386801047.95.0.529827286726.issue19887@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:31:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 22:31:28 +0000
Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive
In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>
Message-ID: <1386801088.06.0.768279508875.issue19918@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19918>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:31:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Dec 2013 22:31:39 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1386801099.06.0.659851371428.issue19921@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:32:20 2013
From: report at bugs.python.org (Doug Hellmann)
Date: Wed, 11 Dec 2013 22:32:20 +0000
Subject: [issue19570] distutils' Command.ensure_dirname fails on Unicode
In-Reply-To: <1384348317.37.0.567121673163.issue19570@psf.upfronthosting.co.za>
Message-ID: <1386801140.28.0.961670417746.issue19570@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19570>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:42:05 2013
From: report at bugs.python.org (anon)
Date: Wed, 11 Dec 2013 22:42:05 +0000
Subject: [issue19915] int.bit_at(n) - Accessing a single bit in O(1)
In-Reply-To: <1386376026.32.0.661343465084.issue19915@psf.upfronthosting.co.za>
Message-ID: <1386801725.26.0.702722052728.issue19915@psf.upfronthosting.co.za>


anon added the comment:

Thank you! I will try to help in ways that I can such as testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19915>
_______________________________________

From report at bugs.python.org  Wed Dec 11 23:42:05 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 11 Dec 2013 22:42:05 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386801725.54.0.249024980997.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

It looks like there are two concepts at play though:

1. side-effect-free vs. may-have-side-effects
2. just-find-the-spec-dangit vs. find-the-spec-relative-to-submodule-search-locations-I-already-know

In the case of #1, providing the path is just a means to an end.  In contrast, for #2 providing the path is the whole point and side effects are something to which you may not have given any thought (but you probably aren't expecting them).

In both cases, it still boils down to (module name -> module spec).  To me, handling both with a single function and a keyword-only "path" parameter seems sufficient, as long as people don't miss the fact that there are side effects in the default case.

The tricky part is that this is not a high-use API, so I'm trying not to think in terms of common case.  (I'm tempted to say things like "in the common case you just want the spec and you don't care about that other stuff".)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:01:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Dec 2013 23:01:34 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <3dfttP6rm6z7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 40884256f8dd by Zachary Ware in branch '3.3':
Issue #19828: Fixed test_site when the whole suite is run with -S.
http://hg.python.org/cpython/rev/40884256f8dd

New changeset 90834ad91d56 by Zachary Ware in branch 'default':
Issue #19828: Merge with 3.3
http://hg.python.org/cpython/rev/90834ad91d56

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19828>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:03:35 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 11 Dec 2013 23:03:35 +0000
Subject: [issue19828] test_site fails with -S flag
In-Reply-To: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>
Message-ID: <1386803015.6.0.415538777824.issue19828@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed.  Thank you Vajrasky for raising the issue, and David for the much better wording.

----------
assignee:  -> zach.ware
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19828>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:05:08 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 11 Dec 2013 23:05:08 +0000
Subject: [issue15027] Faster UTF-32 encoding
In-Reply-To: <1339077451.46.0.686170991807.issue15027@psf.upfronthosting.co.za>
Message-ID: <1386803108.46.0.857694984351.issue15027@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

one comment to address on the review, otherwise after addressing that I believe this is ready to go in for 3.4.

----------
nosy: +gregory.p.smith
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15027>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:07:27 2013
From: report at bugs.python.org (nickhil rokkam)
Date: Wed, 11 Dec 2013 23:07:27 +0000
Subject: [issue19955] When adding .PY and .PYW to PATHEXT,
 it replaced string instead of appending
Message-ID: <1386803247.34.0.411424382912.issue19955@psf.upfronthosting.co.za>


New submission from nickhil rokkam:

Following installer overwrote the PATHEXT string after selecting the "add to path" installation option.
http://www.python.org/ftp/python/3.3.3/python-3.3.3.amd64.msi

----------
components: Installation
files: python-3.3.3.amd64.msi
messages: 205941
nosy: nickhil.rokkam
priority: normal
severity: normal
status: open
title: When adding .PY and .PYW to PATHEXT, it replaced string instead of appending
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file33097/python-3.3.3.amd64.msi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19955>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:27:20 2013
From: report at bugs.python.org (Muhammad Tauqir Ahmad)
Date: Wed, 11 Dec 2013 23:27:20 +0000
Subject: [issue19956] inspect.getsource(obj.foo) fails when foo is an injected
 method constructed from another method
Message-ID: <1386804440.21.0.0153040236788.issue19956@psf.upfronthosting.co.za>


New submission from Muhammad Tauqir Ahmad:

If a method `foo` of object instance `obj` is injected into it using a method from a different object instance, `inspect.getsource(obj.foo)` fails with the error message:

TypeError: <bound method Foo.say of <__main__.Foo object at 0x7fd348662cd0>> is not a module, class, method, function, traceback, frame, or code object

in inspect.py:getfile()

What basically is happening is that if you have `obj1`, `obj2` and `obj2` has method `foo`, setting `obj1.foo = types.MethodType(obj2.foo, obj1)` succeeds but is "double-bound-method" if that's a term. So during `getsource()`, it fails because `obj1.foo.__func__` is a method not a function as is expected.

Possible solutions:
1. Error message should be more clear if this is the intended behavior - right now it claims it's not a method,function etc. when it is indeed a method.
2. MethodType() should fail if the first argument is not a function.
3. inspect.getsource() should recursively keep "unpacking" till it finds an object that it can get the source for. 

Reproducer attached.

----------
components: Library (Lib)
files: reproducer.py
messages: 205942
nosy: mtahmed
priority: normal
severity: normal
status: open
title: inspect.getsource(obj.foo) fails when foo is an injected method constructed from another method
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file33098/reproducer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19956>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:37:45 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Dec 2013 23:37:45 +0000
Subject: [issue19955] When adding .PY and .PYW to PATHEXT,
 it replaced string instead of appending
In-Reply-To: <1386803247.34.0.411424382912.issue19955@psf.upfronthosting.co.za>
Message-ID: <1386805065.56.0.305910180691.issue19955@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
components: +Windows
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19955>
_______________________________________

From report at bugs.python.org  Thu Dec 12 00:41:59 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 Dec 2013 23:41:59 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386801725.54.0.249024980997.issue19944@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eGeEmUhgxSX6kBvivVMO60Rpv-mHAa9AHiM0=uv43oMg@mail.gmail.com>


Nick Coghlan added the comment:

Actually, I think you make a good point. importlib.find_spec should use the
*import_module* signature (no path parameter, but with support for relative
imports). If it is exposed at all, the "one level only" single step version
should appear in importlib.machinery, not at the top level.

The current API exposes an implementation detail most users aren't going to
care about, but a "let me know if it exists but don't import it yet" API
that parallels the full dynamic import API is far more intuitive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Thu Dec 12 07:21:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 12 Dec 2013 06:21:19 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
Message-ID: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/email/encoders.py:

def encode_7or8bit(msg):
    """Set the Content-Transfer-Encoding header to 7bit or 8bit."""
    orig = msg.get_payload(decode=True)
    if orig is None:
        # There's no payload.  For backwards compatibility we use 7bit
        msg['Content-Transfer-Encoding'] = '7bit'
        return
    # We play a trick to make this go fast.  If encoding/decode to ASCII
    # succeeds, we know the data must be 7bit, otherwise treat it as 8bit.
    try:
        if isinstance(orig, str):
            orig.encode('ascii')
        else:
            orig.decode('ascii')
    except UnicodeError:
        charset = msg.get_charset()


msg.get_payload(decode=True) always return bytes so there is no point of these lines:

        if isinstance(orig, str):
            orig.encode('ascii')
        else:
            orig.decode('ascii')

Attached the patch to refactor this function.

----------
components: email
files: minor_refactor_encoders_in_email_lib.patch
keywords: patch
messages: 205944
nosy: barry, r.david.murray, vajrasky
priority: normal
severity: normal
status: open
title: Minor refactor of Lib/email/encoders.py
versions: Python 3.4
Added file: http://bugs.python.org/file33099/minor_refactor_encoders_in_email_lib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Thu Dec 12 09:37:00 2013
From: report at bugs.python.org (Dmitrii Dimandt)
Date: Thu, 12 Dec 2013 08:37:00 +0000
Subject: [issue19958] Assignment success despite TypeError exception
Message-ID: <1386837420.1.0.0855964875306.issue19958@psf.upfronthosting.co.za>


New submission from Dmitrii Dimandt:

Observed behaviour:

Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
>>> a = (1, [2,3])
>>> a[1] += [4,5]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> a
(1, [2, 3, 4, 5])


Expected behaviour: tuple remains unchanged

----------
components: Interpreter Core
messages: 205945
nosy: Dmitrii.Dimandt
priority: normal
severity: normal
status: open
title: Assignment success despite TypeError exception
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19958>
_______________________________________

From report at bugs.python.org  Thu Dec 12 09:43:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 08:43:42 +0000
Subject: [issue19958] Assignment success despite TypeError exception
In-Reply-To: <1386837420.1.0.0855964875306.issue19958@psf.upfronthosting.co.za>
Message-ID: <1386837822.55.0.699989130197.issue19958@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, this behaviour is really weird. It can probably be explained by the fact that the INPLACE_ADD operator is used. See the bytecode for an explanation.

I don't know if it's possible to workaround this issue.

$ python3
Python 3.3.2 (default, Nov  8 2013, 13:38:57) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a=(1,[])
>>> a[1].append(2)
>>> a
(1, [2])
>>> a[1]+=[3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> a
(1, [2, 3])
>>> def bug(a):
...  a[1] += [4]
... 
>>> import dis
>>> dis.dis(bug)
  2           0 LOAD_FAST                0 (a) 
              3 LOAD_CONST               1 (1) 
              6 DUP_TOP_TWO          
              7 BINARY_SUBSCR        
              8 LOAD_CONST               2 (4) 
             11 BUILD_LIST               1 
             14 INPLACE_ADD          
             15 ROT_THREE            
             16 STORE_SUBSCR         
             17 LOAD_CONST               0 (None) 
             20 RETURN_VALUE         
>>> a
(1, [2, 3])
>>> bug(a)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in bug
TypeError: 'tuple' object does not support item assignment
>>> a
(1, [2, 3, 4])

----------
nosy: +haypo, rhettinger, serhiy.storchaka
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19958>
_______________________________________

From report at bugs.python.org  Thu Dec 12 09:54:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 12 Dec 2013 08:54:46 +0000
Subject: [issue19958] Assignment success despite TypeError exception
In-Reply-To: <1386837420.1.0.0855964875306.issue19958@psf.upfronthosting.co.za>
Message-ID: <1386838486.81.0.8619305954.issue19958@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19958>
_______________________________________

From report at bugs.python.org  Thu Dec 12 10:58:03 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 12 Dec 2013 09:58:03 +0000
Subject: [issue19956] inspect.getsource(obj.foo) fails when foo is an injected
 method constructed from another method
In-Reply-To: <1386804440.21.0.0153040236788.issue19956@psf.upfronthosting.co.za>
Message-ID: <1386842283.29.0.977571518004.issue19956@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

FYI, if you change:

setattr(b, 'say', types.MethodType(f.say, b))

to:

setattr(b, 'say', types.MethodType(Foo.say, b))

it will print the source correctly.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19956>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:31:03 2013
From: report at bugs.python.org (Garth Bushell)
Date: Thu, 12 Dec 2013 10:31:03 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
Message-ID: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>


New submission from Garth Bushell:

argparse.FileType does not expand tilde "~". 

This would be useful to take file parameters beginning with "~" and use os.path.expanduser to expand this.

----------
components: Library (Lib)
messages: 205949
nosy: garthy
priority: normal
severity: normal
status: open
title: argparse.FileType does not expand tilde "~"
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:33:42 2013
From: report at bugs.python.org (Garth Bushell)
Date: Thu, 12 Dec 2013 10:33:42 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1386844422.82.0.0718016166858.issue19959@psf.upfronthosting.co.za>


Garth Bushell added the comment:

Add patch to add an option to argparse.FileType to enable expanduser.

----------
keywords: +patch
Added file: http://bugs.python.org/file33100/19959-argparse_filetype_expanduser.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:34:14 2013
From: report at bugs.python.org (Garth Bushell)
Date: Thu, 12 Dec 2013 10:34:14 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1386844454.15.0.793854393111.issue19959@psf.upfronthosting.co.za>


Changes by Garth Bushell <garth at garthy.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:44:58 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Thu, 12 Dec 2013 10:44:58 +0000
Subject: [issue5305] imaplib should support international mailbox names
In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za>
Message-ID: <1386845098.48.0.0885155611015.issue5305@psf.upfronthosting.co.za>


Changes by Dani?l van Eeden <launchpad at myname.nl>:


----------
nosy: +dveeden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5305>
_______________________________________

From report at bugs.python.org  Thu Dec 12 11:45:35 2013
From: report at bugs.python.org (Wim)
Date: Thu, 12 Dec 2013 10:45:35 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1386845135.74.0.993401368666.issue17088@psf.upfronthosting.co.za>


Wim added the comment:

FWIW: I noticed that my patch has a bug due to sharing the cache dict between element names and attribute names, although I think this is unlikely to crop up very often in practice. I'll submit a better patch if/when I get the time to put one together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17088>
_______________________________________

From report at bugs.python.org  Thu Dec 12 13:07:05 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Dec 2013 12:07:05 +0000
Subject: [issue19960] MacOSX: Building 2.7 without the xcode command line
 tools installed
Message-ID: <1386850025.77.0.292014271005.issue19960@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

When you build python 2.7 on an OSX 10.9 machine with Xcode but without the command-line tools installed that build mostly succeeds, but doesn't detect a number of dependencies (in particular zlib).

The attached patch teaches "add_dir_to_list" about the SDK sysroot on OSX and with that the build succeeds.

Aside: I also noticed problems with build tinter, with 2.7 but also with 3.3 and 3.4. I'll file a separate issue about that.

----------
assignee: ronaldoussoren
components: Build
files: python2.7-alternative-sdk.txt
keywords: needs review, patch
messages: 205952
nosy: hynek, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: MacOSX: Building 2.7 without the xcode command line  tools installed
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file33101/python2.7-alternative-sdk.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19960>
_______________________________________

From report at bugs.python.org  Thu Dec 12 13:11:26 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 12 Dec 2013 12:11:26 +0000
Subject: [issue19961] MacOSX: Tkinter build failure when building without
 command-line tools
Message-ID: <1386850286.1.0.287048995559.issue19961@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

When you build python on an OSX 10.9 machine with Xcode but without the command-line tools installed that build mostly succeeds, but Tkinter fails to build.

The following error message is from a 2.7 build, but the same problem occurs when building 3.3 and 3.4:

clang -fno-strict-aliasing -fno-common -dynamic -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -fexceptions -g -O0 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/System/Library/Frameworks/Tcl.framework/Headers -I/System/Library/Frameworks/Tcl.framework/Versions/Current/PrivateHeaders -I/System/Library/Frameworks/Tk.framework/Headers -I/System/Library/Frameworks/Tk.framework/Versions/Current/PrivateHeaders -I/usr/X11R6/include -I/Users/ronald/Projects/python/rw/2.7/Mac/Include -I. -IInclude -I../Include -I/Users/ronald/Projects/python/rw/2.7/Include -I/Users/ronald/Projects/python/rw/2.7/build -c /Users/ronald/Projects/python/rw/2.7/Modules/_tkinter.c -o build/temp.macosx-10.8-intel-2.7-pydebug/Users/ronald/Projects/python/rw/2.7/Modules/_tkinter.o -framework Tk -arch x86_64 -arch i386
clang: warning: -framework Tk: 'linker' input unused
In file included from /Users/ronald/Projects/python/rw/2.7/Modules/_tkinter.c:71:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/tk.h:78:11: fatal error: 
      'X11/Xlib.h' file not found
#       include <X11/Xlib.h>
                ^
1 error generated.


NOTE: I haven't tried building with the command-line tools for xcode installed, I have a freshly installed system and want to try to live without these tools because that makes it easier to upgrade xcode.

----------
components: Build
messages: 205953
nosy: hynek, ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: MacOSX: Tkinter build failure when building without command-line tools
type: compile error
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19961>
_______________________________________

From report at bugs.python.org  Thu Dec 12 14:33:06 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Dec 2013 13:33:06 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1386855186.04.0.30332777258.issue19959@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Thu Dec 12 14:55:19 2013
From: report at bugs.python.org (Garth Bushell)
Date: Thu, 12 Dec 2013 13:55:19 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1386856519.19.0.424270139074.issue19959@psf.upfronthosting.co.za>


Garth Bushell added the comment:

Update patch to include docs.

----------
Added file: http://bugs.python.org/file33102/19959-argparse_filetype_expanduser_plus_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Thu Dec 12 15:26:39 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 12 Dec 2013 14:26:39 +0000
Subject: [issue12836] ctypes.cast() creates circular reference in original
 object
In-Reply-To: <1314222835.27.0.518600149254.issue12836@psf.upfronthosting.co.za>
Message-ID: <1386858399.41.0.853773727101.issue12836@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Possibly, the result's b_objects needs to be a copy of the src's b_objects

That sounds right to me.  I can't really believe that the current behaviour is intentional.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12836>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:24:55 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Dec 2013 15:24:55 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
In-Reply-To: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>
Message-ID: <1386861895.39.0.259791171392.issue19957@psf.upfronthosting.co.za>


R. David Murray added the comment:

Good point, thanks for the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:33:49 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 12 Dec 2013 15:33:49 +0000
Subject: [issue19962] Create a 'python.bat' script to invoke interpreter from
 source root
Message-ID: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch adds a CustomBuildStep to python.vcxproj which creates a 'python.bat' script in the root of the source tree for quicker and easier invocation for testing purposes, and to make the Windows Python developer experience a little closer to the UNIX experience.  Sample output:

"""
C:\path\to\cpython>type python.bat
@rem This script invokes the most recently built Python with all arguments
@rem passed through to the interpreter.  This file is generated by the
@rem build process and any changes *will* be thrown away by the next
@rem rebuild.
@rem This is only meant as a convenience for developing CPython
@rem and using it outside of that context is ill-advised.
@echo Running Debug^|Win32 interpreter...
@"C:\path\to\cpython\PCbuild\python_d.exe" %*

C:\path\to\cpython>python -c "import sys;print(sys.version)"
Running Debug|Win32 interpreter...
3.4.0b1 (default:6864abd8e83a+, Dec 12 2013, 08:35:32) [MSC v.1600 32 bit (Intel
)]
"""

As the commentary (which can likely be improved) states, the script is re-created by every rebuild, so it always points to the most recently built interpreter.  Also, being a CustomBuildStep, it is cleaned up automatically by the Clean build target.

I'm not sure whether echoing the interpreter configuration is the best idea, but I personally prefer that over echoing the full command which has the potential to be very long.  I think that the Configuration/Platform should be displayed somehow to reduce confusion since there could be up to 8 different interpreters living together in PCbuild (not to mention PC/VS10.0, when it exists someday) and python.bat will only point to one of them.

Note that the x64 changes are done by hand and untested; I don't have the ability to do so just yet.

----------
assignee: zach.ware
components: Build, Windows
files: python.bat.diff
keywords: patch
messages: 205957
nosy: brian.curtin, loewis, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Create a 'python.bat' script to invoke interpreter from source root
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33103/python.bat.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19962>
_______________________________________

From report at bugs.python.org  Thu Dec 12 16:51:28 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Dec 2013 15:51:28 +0000
Subject: [issue19963] Update docs for importlib.import_module()
Message-ID: <1386863488.66.0.95075387915.issue19963@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The docs for importlib.import_module() say that you need to import parent packages first, but this is actually no longer the case (thankfully):

Python 3.4.0b1 (default:a3bdbe220f8a, Dec 10 2013, 11:07:04) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 'test' in sys.modules
False
>>> import importlib
>>> importlib.import_module('test.test_importlib.source')
<module 'test.test_importlib.source' from '/usr/local/google/home/bcannon/Repos/cpython/default/Lib/test/test_importlib/source/__init__.py'>


Also need to check if this is false in Python 3.3 (or wherever the change occurred) to update the docs there and to add a versionchanged flag.

----------
assignee: brett.cannon
components: Documentation
messages: 205958
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Update docs for importlib.import_module()
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19963>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:33:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Dec 2013 16:33:38 +0000
Subject: [issue19572] Report more silently skipped tests as skipped
In-Reply-To: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>
Message-ID: <3dgLDK3Sw0z7Ljs@mail.python.org>


Roundup Robot added the comment:

New changeset 1ad2ff119356 by Zachary Ware in branch '3.3':
Avoid UnicodeEncodeError by only printing ASCII.
http://hg.python.org/cpython/rev/1ad2ff119356

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19572>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:46:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 16:46:31 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
In-Reply-To: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>
Message-ID: <1386866791.58.0.46866116023.issue19957@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then special case for iso-2022-* is not needed too.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Thu Dec 12 17:47:59 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 12 Dec 2013 16:47:59 +0000
Subject: [issue12836] ctypes.cast() creates circular reference in original
 object
In-Reply-To: <1314222835.27.0.518600149254.issue12836@psf.upfronthosting.co.za>
Message-ID: <1386866879.85.0.566634358829.issue12836@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Adding Thomas Heller to nosy to see if he can shed any light on this.

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12836>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:07:47 2013
From: report at bugs.python.org (Sworddragon)
Date: Thu, 12 Dec 2013 17:07:47 +0000
Subject: [issue19964] '?' is always non-greedy
Message-ID: <1386868067.16.0.771792818941.issue19964@psf.upfronthosting.co.za>


New submission from Sworddragon:

>From the documentation: "The '*', '+', and '?' qualifiers are all greedy;"

But this is not the case for '?'. In the attachments is an example which shows this: re.search(r'1?', '01') should find '1' but it doesn't find anything.

----------
components: Library (Lib)
files: test.py
messages: 205962
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: '?' is always non-greedy
type: behavior
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33104/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19964>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:19:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 17:19:17 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386868757.38.0.213400625932.issue19954@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does separated test crash?

./python -m test -v -uall -m test_indicatoron test_tk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:20:10 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Dec 2013 17:20:10 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
Message-ID: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

A user reported this error with `make -j${high_value}`:

========================
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/_warnings.o Python/_warnings.c
/bin/mkdir -p Include
python3.3 ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/asdl.o Python/asdl.c
make Parser/pgen
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/bltinmodule.o Python/bltinmodule.c
make[1]: Entering directory '/var/tmp/portage/dev-lang/python-3.3.3-r1000/work/Python-3.3.3'
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/dynamic_annotations.o Python/dynamic_annotations.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/mysnprintf.o Python/mysnprintf.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/ceval.o Python/ceval.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/pyctype.o Python/pyctype.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/codecs.o Python/codecs.c
Python/bltinmodule.c:4:24: warning: Include/Python-ast.h is shorter than expected [enabled by default]
 #include "Python-ast.h"
                        ^
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/errors.o Python/errors.c
In file included from Python/bltinmodule.c:10:0:
Include/ast.h:7:1: warning: parameter names (without types) in function declaration [enabled by default]
 PyAPI_FUNC(int) PyAST_Validate(mod_ty);
 ^
In file included from Include/Python.h:50:0,
                 from Python/bltinmodule.c:3:
Include/ast.h:8:12: error: unknown type name ?mod_ty?
 PyAPI_FUNC(mod_ty) PyAST_FromNode(
            ^
Include/pyport.h:777:34: note: in definition of macro ?PyAPI_FUNC?
 #       define PyAPI_FUNC(RTYPE) RTYPE
                                  ^
Python/bltinmodule.c: In function ?builtin_compile?:
Python/bltinmodule.c:641:13: error: unknown type name ?mod_ty?
             mod_ty mod;
             ^
Python/bltinmodule.c:647:21: warning: comparison between pointer and integer [enabled by default]
             if (mod == NULL) {
                     ^
Python/bltinmodule.c:656:49: warning: passing argument 1 of ?PyAST_CompileEx? makes pointer from integer without a cast [enabled by default]
                                                 &cf, optimize, arena);
                                                 ^
In file included from Include/Python.h:122:0,
                 from Python/bltinmodule.c:3:
Include/compile.h:33:28: note: expected ?struct _mod *? but argument is of type ?int?
 PyAPI_FUNC(PyCodeObject *) PyAST_CompileEx(
                            ^
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Python/frozenmain.o Python/frozenmain.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c
Makefile:1362: recipe for target 'Python/bltinmodule.o' failed
make: *** [Python/bltinmodule.o] Error 1
make: *** Waiting for unfinished jobs....
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/parsetok_pgen.o Parser/parsetok_pgen.c
x86_64-pc-linux-gnu-gcc -pthread -c -Wno-unused-result -DNDEBUG  -O2 -march=atom -pipe -fwrapv    -I. -IInclude -I./Include   -fPIC -DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c
x86_64-pc-linux-gnu-gcc -pthread -DNDEBUG  -Wl,-O1 -Wl,--sort-common -Wl,--as-needed  Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen
make[1]: Leaving directory '/tmp/Python-3.3.3'
Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c
========================

I attach a patch (for default branch). This bug should be also fixed in 2.7 and 3.3 branches.

----------
components: Build
files: asdl_c.py.patch
keywords: easy, patch
messages: 205964
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Non-atomic generation of Include/Python-ast.h and Python/Python-ast.c
type: compile error
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33105/asdl_c.py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:29:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 17:29:31 +0000
Subject: [issue19964] '?' is always non-greedy
In-Reply-To: <1386868067.16.0.771792818941.issue19964@psf.upfronthosting.co.za>
Message-ID: <1386869371.35.0.65962663973.issue19964@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think the documentation is wrong. re.search() returns first match, and this is empty string at position 0.

>>> import re
>>> re.search('1?', '01')
<_sre.SRE_Match object; span=(0, 0), match=''>

All matches:

>>> list(re.findall('1?', '01'))
['', '1', '']
>>> list(re.finditer('1?', '01'))
[<_sre.SRE_Match object; span=(0, 0), match=''>, <_sre.SRE_Match object; span=(1, 2), match='1'>, <_sre.SRE_Match object; span=(2, 2), match=''>]

----------
nosy: +ezio.melotti, pitrou, serhiy.storchaka
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19964>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:32:10 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 12 Dec 2013 17:32:10 +0000
Subject: [issue19964] '?' is always non-greedy
In-Reply-To: <1386868067.16.0.771792818941.issue19964@psf.upfronthosting.co.za>
Message-ID: <1386869530.28.0.859981427906.issue19964@psf.upfronthosting.co.za>


Tim Peters added the comment:

It's working fine.  `.search()` always finds the leftmost position at which the pattern matches.  In your example, the pattern '1?' does match at index 0:  it first tries to match `1' at index 0.  That's the greedy part.  The attempt fails, so it next tries to match the empty string at index 0.  That succeeds, which you can see by printing search.span(0) (which displays (0, 0)).

Of course you'd get exactly the same result if you tried matching `1*` instead.  But you'd get a different result from matching '1+', because that pattern does _not_ match at index 0.  In that case the engine has to move to index 1 to get a match.

And if you search the string '11' with the pattern '1?`, you'll see that it does match the slice 0:1.  If, as you claimed, ? were not greedy, it would match the empty string 0:0 instead.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19964>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:32:25 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 12 Dec 2013 17:32:25 +0000
Subject: [issue19964] '?' is always non-greedy
In-Reply-To: <1386868067.16.0.771792818941.issue19964@psf.upfronthosting.co.za>
Message-ID: <1386869545.08.0.716744104605.issue19964@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19964>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:32:32 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 12 Dec 2013 17:32:32 +0000
Subject: [issue19964] '?' is always non-greedy
In-Reply-To: <1386868067.16.0.771792818941.issue19964@psf.upfronthosting.co.za>
Message-ID: <1386869552.94.0.990924577849.issue19964@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19964>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:33:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 17:33:09 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386869589.84.0.272646320251.issue19965@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:37:02 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Dec 2013 17:37:02 +0000
Subject: [issue19966] Wrong mtimes of files in 3.3.3 tarballs
Message-ID: <1386869822.97.0.610221510269.issue19966@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

This bug is present in 3.3.3 tarballs (Python-3.3.3.tar.bz2, Python-3.3.3.tar.xz, Python-3.3.3.tgz). This bug is absent in 3.3.2 tarballs.

In unpacked 3.3.2:

$ ./configure
...
$ make Include/Python-ast.h
make: 'Include/Python-ast.h' is up to date.
$ make Python/Python-ast.c
make: 'Python/Python-ast.c' is up to date.


In unpacked 3.3.3:

$ ./configure
...
$ make Include/Python-ast.h
/bin/mkdir -p Include
python3.3 ./Parser/asdl_c.py -h Include ./Parser/Python.asdl
$ make Python/Python-ast.c
/bin/mkdir -p Python
python3.3 ./Parser/asdl_c.py -c Python ./Parser/Python.asdl


At least please fix the script used to generate tarballs, to ensure that this bug will not occur with future tarballs.

----------
components: Build
messages: 205967
nosy: Arfrever, georg.brandl
priority: normal
severity: normal
status: open
title: Wrong mtimes of files in 3.3.3 tarballs
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19966>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:42:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 17:42:44 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386870164.3.0.950265144743.issue19965@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think os.replace() should be used instead os.rename(). Or pair os.unlink()/os.rename().

And perhaps for decreasing chance of race between creating .c and .h files, both renames should be done after writing both files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:49:28 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Dec 2013 17:49:28 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386870568.09.0.834414087329.issue19965@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

'p' variable in one part of code has different value than in other part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 18:52:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 17:52:02 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386870722.56.0.195917047693.issue19965@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can save them in a list of created files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 19:33:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Dec 2013 18:33:23 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
In-Reply-To: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>
Message-ID: <1386873203.3.0.127634129702.issue19957@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, in theory that should be true at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Thu Dec 12 19:33:35 2013
From: report at bugs.python.org (Muhammad Tauqir Ahmad)
Date: Thu, 12 Dec 2013 18:33:35 +0000
Subject: [issue19956] inspect.getsource(obj.foo) fails when foo is an injected
 method constructed from another method
In-Reply-To: <1386804440.21.0.0153040236788.issue19956@psf.upfronthosting.co.za>
Message-ID: <1386873215.41.0.648744294845.issue19956@psf.upfronthosting.co.za>


Muhammad Tauqir Ahmad added the comment:

Yes I understand your change and other possible changes will fix the reproducer. I am already using a different workaround in my code.

The issue is about `inspect.getsource()` having incorrect behavior (or at least inaccurate error message) and MethodType able to be constructed from another method leading to strange undocumented behavior (as far as I can tell).

I do not know what the correct resolution is to this issue which is why I posted this here so someone can suggest/approve a resolution and I can submit a patch once something is decided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19956>
_______________________________________

From report at bugs.python.org  Thu Dec 12 19:36:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Dec 2013 18:36:47 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386873407.65.0.383244546524.issue19954@psf.upfronthosting.co.za>


R. David Murray added the comment:

rdmurray at hey:~/python/p34>./python -m test -v -uall -m test_indicatoron test_tk
== CPython 3.4.0b1 (default:59fb79d0411e, Dec 11 2013, 16:39:28) [GCC 4.7.2]
==   Linux-3.10.6-gentoo-i686-Intel-R-_Core-TM-_i5_CPU_M_450_ at _2.40GHz-with-gentoo-2.2 little-endian
==   hash algorithm: siphash24 32bit
==   /home/rdmurray/python/p34/build/test_python_4151
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_tk
patchlevel = 8.6.1
test_indicatoron (tkinter.test.test_tkinter.test_widgets.CheckbuttonTest) ... ok
test_indicatoron (tkinter.test.test_tkinter.test_widgets.MenubuttonTest) ... Fatal Python error: Floating point exception

Current thread 0xb74f76c0 (most recent call first):
  File "/home/rdmurray/python/p34/Lib/tkinter/__init__.py", line 1254 in _configure
  File "/home/rdmurray/python/p34/Lib/tkinter/__init__.py", line 1263 in configure
  File "/home/rdmurray/python/p34/Lib/tkinter/__init__.py", line 1270 in __setitem__
  File "/home/rdmurray/python/p34/Lib/tkinter/test/widget_tests.py", line 47 in checkParam
  File "/home/rdmurray/python/p34/Lib/tkinter/test/widget_tests.py", line 116 in checkBooleanParam
  File "/home/rdmurray/python/p34/Lib/tkinter/test/widget_tests.py", line 422 in test_indicatoron
  File "/home/rdmurray/python/p34/Lib/unittest/case.py", line 574 in run
  File "/home/rdmurray/python/p34/Lib/unittest/case.py", line 622 in __call__
  File "/home/rdmurray/python/p34/Lib/unittest/suite.py", line 117 in run
  File "/home/rdmurray/python/p34/Lib/unittest/suite.py", line 79 in __call__
  File "/home/rdmurray/python/p34/Lib/unittest/suite.py", line 117 in run
  File "/home/rdmurray/python/p34/Lib/unittest/suite.py", line 79 in __call__
  File "/home/rdmurray/python/p34/Lib/unittest/runner.py", line 168 in run
  File "/home/rdmurray/python/p34/Lib/test/support/__init__.py", line 1685 in _run_suite
  File "/home/rdmurray/python/p34/Lib/test/support/__init__.py", line 1719 in run_unittest
  File "/home/rdmurray/python/p34/Lib/test/test_tk.py", line 22 in test_main
  File "/home/rdmurray/python/p34/Lib/test/regrtest.py", line 1278 in runtest_inner
  File "/home/rdmurray/python/p34/Lib/test/regrtest.py", line 978 in runtest
  File "/home/rdmurray/python/p34/Lib/test/regrtest.py", line 763 in main
  File "/home/rdmurray/python/p34/Lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "/home/rdmurray/python/p34/Lib/test/__main__.py", line 3 in <module>
  File "/home/rdmurray/python/p34/Lib/runpy.py", line 73 in _run_code
  File "/home/rdmurray/python/p34/Lib/runpy.py", line 160 in _run_module_as_main
zsh: floating point exception  ./python -m test -v -uall -m test_indicatoron test_tk

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 19:59:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 18:59:22 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386874762.66.0.845985287483.issue19954@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What if run following code?

import tkinter
root = tkinter.Tk()
widget = tkinter.Menubutton(root)
for value in (True, 1, 'true', 'yes', 'on'):
    print(value, flush=True)
    widget['indicatoron'] = value

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 20:15:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 Dec 2013 19:15:47 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386875747.82.0.169042185891.issue19965@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Since the patch doesn't use O_EXCL for the temporary file, it suffers
from the exact same race condition as the current code. It should be
using the "x" open mode.

----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 20:37:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 19:37:56 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386877076.71.0.341627498601.issue19965@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Since the patch doesn't use O_EXCL for the temporary file, it suffers
> from the exact same race condition as the current code.

This does not make race condition. Only one thread writes .tmp files.

The problem is that other threads can read *-ast.[ch] files while they are written.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 20:43:45 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 Dec 2013 19:43:45 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386877076.71.0.341627498601.issue19965@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2ECck8u7PX9-yf+-SYNsMWut_L+M1ak1DmnDd1_s1gVw@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

>
>
> > Since the patch doesn't use O_EXCL for the temporary file, it suffers
> > from the exact same race condition as the current code.
>
> This does not make race condition. Only one thread writes .tmp files.
>
> The problem is that other threads can read *-ast.[ch] files while they are
> written.
>

Ah, I thought it was written by several processes. It's OK then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Thu Dec 12 21:28:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 20:28:41 +0000
Subject: [issue19623] Support for writing aifc to unseekable file
In-Reply-To: <1384602280.29.0.166311165953.issue19623@psf.upfronthosting.co.za>
Message-ID: <1386880121.66.0.294931478737.issue19623@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/issue19623>
_______________________________________

From report at bugs.python.org  Thu Dec 12 21:29:58 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Dec 2013 20:29:58 +0000
Subject: [issue16669] Docstrings for namedtuple
In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za>
Message-ID: <1386880198.7.0.856902114828.issue16669@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

A few quick thoughts:

* Everyone can agree "docstrings are good".
* I disagree with Ned that the current docstrings
  are ugly or not useful.  The class docstring is
  shown by tooltips and is immediately useful to
  someone making a instance.  The attribute docstrings
  add value by indicating position (named tuples are
  fundamentally sequences, so the position matters).
* Unlike method docstrings, the attribute docstrings
  are only visible in help().  As TJR noted, most
  users will never see them or expect them.
* That said, tuples are like records in a database
  and it is common in the database world to have a
  data dictionary that provides more detail than 
  the field name.
* In general, I'm unsympathetic to "my automatically
  generated docs aren't pretty".  My experience with
  auto-generated docs suggests that you almost always
  have to manually make improvements.  The nature of
  auto-generated code or docs is that the output is
  usable but not pretty.
* I am very sympathetic to how difficult it is to add
  or modify property docstrings after the fact.  This
  isn't unique to named tuples but the problem is felt
  more acutely.
* The intended ways to extend named tuples is to either
  1) subclass the NT and change anything that doesn't
  suit your needs, or 2) use the generated source as
  a starting point and edit it directly.  In the case
  of a module docstring, either method works fine. In
  the case of attribute docstrings, the first method is
  a PITA because you have to recreate the whole property
  definition.
* To me, that is the only point in favor of the feature
  request.  Where the implementation currently makes
  something difficult, it would be nice to provide a
  smoother, standardized solution.
* That said, there are downsides to make the patch.
  It complicates the API, making named tuples harder
  to teach, to learn, or to remember.  The docs for
  named tuples are turning into a book.  Factories
  that provide too many options are harder to use.
  In addition, the patch further complicates the
  named tuple implementation.  And to the extent that
  users provide multi-line docstrings for the attributes,
  the visual appearance of the generated code gets ugly
  and the visual appearance of the call to named tuple
  factory becomes somewhat awkward.
* There is no question about whether the functionality
  might occassionally be useful and whether it is currently
  hard to implement using subclassing.  The question boils
  down to balancing aesthetics trade-offs (i.e. improving
  the aesthetic of automated generated docs versus hurting
  the aesthetics of 1) the factory function signature,
  2) the generated code (which is intende to be viewed,
  studied, cut-and-pasted, exec'ed, etc), and complexity
  of the collections module code for named tuples.
* Since 2.7 was long since released, the earliest anyone
  would see a change in Python 3.5.  The other ships have
  already sailed.
* One last thought.  I worry about over-parameterizing
  named tuples.  If I had it to do over again, I wouldn't
  have added the *rename* option.  The *verbose* option
  is no longer necessary because of the *_source* attribute.
  There is a *module* parameter being added that will only
  be used in rare cases.  There was a requests for a
  *type_specifiers* parameter to type check all of the 
  arguments (similar to the functionality in argparse).
  There was a request for *format_specfiers* to control
  how the named tuple display (this is mainly useful
  for printing a list of named tuples in the form of
  a table with nicely aligned columns).
* Individually, those parameter requests sound reasonable
  (i.e. they have legitimate use cases).  Collectively,
  they are an API train wreck.  It doesn't pay to try
  to please all of the people, all of the time.
* I'm inclined to say that most or of these aren't
  worth it and simply acknowledge that "once in a while
  some aspect of named tuples isn't a convenient as you
  would like, but that there are other compensating
  aesthetics."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16669>
_______________________________________

From report at bugs.python.org  Thu Dec 12 21:34:01 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 12 Dec 2013 20:34:01 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1386880441.59.0.58701433172.issue18986@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

+1 for this (for Python 3.5, now, I guess). I've just found another place where I'd use it.

Looking at the implementation, one thing surprises me a bit:  I'd expect the KeyError from a 'del' or 'pop' operation to have the untransformed key rather than the transformed key in its .args.

How about '_keys' and '_values' for the slot names, in place of '_original' and '_data'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Thu Dec 12 21:58:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 20:58:10 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386881890.84.0.721274359416.issue19954@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please run following commands in wish:

$ wish
% menubutton .mb
.mb
% .mb configure -indicatoron 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:00:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Dec 2013 21:00:05 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386882005.43.0.802629907519.issue19954@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah.  That produces the floating point exception as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:16:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 21:16:13 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386882973.1.0.580949130324.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #19846.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19847>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:19:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Dec 2013 21:19:13 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386883153.04.0.265056211046.issue19954@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What with such example?

$ wish
% menubutton .mb -text "Test"
.mb
% pack .mb
% update
% .mb configure -indicatoron 1

Try also without pack and update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:22:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Dec 2013 21:22:18 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box
 running tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386883338.18.0.780790243284.issue19954@psf.upfronthosting.co.za>


R. David Murray added the comment:

floating point exception with or without the pack/update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:59:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 21:59:23 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386885563.72.0.372138036129.issue19787@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If I understand correctly, there is probably only one application (mod_python) which might be broken by fix_set_key_value.patch.

If an application is broken by fix_set_key_value.patch, it can get the old behaviour using:

int
PyThread_set_key_value33(int key, void *value)
{
#if PY_VERSION_HEX >= 0x03040000
    void *oldValue = PyThread_get_key_value(key);
    if (oldValue != NULL)
        return 0;
#endif
    return PyThread_set_key_value(key, value);
}

So are you ok to apply the bugfix in Python 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Thu Dec 12 22:59:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 21:59:31 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386885571.83.0.521958388527.issue19787@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Thu Dec 12 23:00:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Dec 2013 22:00:04 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1386885563.72.0.372138036129.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386885602.2305.18.camel@fsol>


Antoine Pitrou added the comment:

On jeu., 2013-12-12 at 21:59 +0000, STINNER Victor wrote:
> So are you ok to apply the bugfix in Python 3.4?

I'm ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Thu Dec 12 23:13:25 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Dec 2013 22:13:25 +0000
Subject: [issue19751] test_sys: sys.hash_info.algorithm failure on SPARC
 Solaris buildbot
In-Reply-To: <1385297187.74.0.693847111414.issue19751@psf.upfronthosting.co.za>
Message-ID: <3dgTmN5p0pz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 7c116d7c6c65 by Victor Stinner in branch 'default':
Issue #19751: Fix typo in configuration option
http://hg.python.org/cpython/rev/7c116d7c6c65

New changeset c1a7ba57b4ff by Victor Stinner in branch 'default':
Issue #19751: Fix hash_info test of test_sys on SPARC Solaris
http://hg.python.org/cpython/rev/c1a7ba57b4ff

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19751>
_______________________________________

From report at bugs.python.org  Fri Dec 13 00:02:49 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 23:02:49 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
Message-ID: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Thanks to the PEP 442 (Safe object finalization), _TracebackLogger helper of asyncio.Futures becomes useless.

Attached patch removes it.

--

If you agree to diverge code with Tulip project, the Python 3.3 code of WriteTransport.writelines can also be removed:

        if not PY34:
            # In Python 3.3, bytes.join() doesn't handle memoryview.
            list_of_data = (
                bytes(data) if isinstance(data, memoryview) else data
                for data in list_of_data)

----------
files: asyncio_log_traceback.patch
keywords: patch
messages: 205988
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio: remove _TracebackLogger
versions: Python 3.4
Added file: http://bugs.python.org/file33106/asyncio_log_traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Fri Dec 13 00:20:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 23:20:06 +0000
Subject: [issue19750] test_asyncio.test_unix_events constructor failures on AIX
In-Reply-To: <1385296950.99.0.982628682855.issue19750@psf.upfronthosting.co.za>
Message-ID: <1386890406.16.0.331684569307.issue19750@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The initial test failure have been fixed, so I'm closing the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19750>
_______________________________________

From report at bugs.python.org  Fri Dec 13 00:45:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 23:45:14 +0000
Subject: [issue19636] Fix usage of MAX_PATH in posixmodule.c
In-Reply-To: <1384731950.1.0.229673291292.issue19636@psf.upfronthosting.co.za>
Message-ID: <1386891914.12.0.159671514434.issue19636@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19636>
_______________________________________

From report at bugs.python.org  Fri Dec 13 00:46:41 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 12 Dec 2013 23:46:41 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1386892001.28.0.256974255904.issue19967@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm sorry, I really don't want the asyncio code for 3.3 and 3.4 to diverge just yet. It would make keeping the two versions in sync just so much harder.

I'm happy with something that checks for the version and either adds the __del__ method (for 3.4) or uses the _TracebackLogger (for 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Fri Dec 13 00:50:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Dec 2013 23:50:54 +0000
Subject: [issue19635] asyncio should not depend on concurrent.futures,
 it is not always available
In-Reply-To: <1384728802.8.0.137912295354.issue19635@psf.upfronthosting.co.za>
Message-ID: <1386892254.0.0.107696147594.issue19635@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Guido: If you write "issue #xxx" in your commit message, the changeset will be mentionned in the related issue.

---
changeset:   87237:0031ac40806a
user:        Guido van Rossum <guido at dropbox.com>
date:        Sun Nov 17 17:00:21 2013 -0800
files:       Lib/test/test_asyncio/__init__.py
description:
Skip test_asyncio if concurrent.futures can't be imported. Hopeful fix for issue 19645.
---

The changeset fixed the issue: the test is now skipped on "x86 FreeBSD 6.4 3.x" buildbot.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19635>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:15:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:15:20 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1386893720.66.0.803622897791.issue19967@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I'm happy with something that checks for the version and either adds the __del__ method (for 3.4) or uses the _TracebackLogger (for 3.3).

Ok. Here is a patch. The class is still defined on Python 3.4. You may move the definition of the class in a "if not PY34:" class. I did not the change to have a shorter patch.

----------
Added file: http://bugs.python.org/file33107/asyncio_log_traceback-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:15:44 2013
From: report at bugs.python.org (Quanah Gibson-Mount)
Date: Fri, 13 Dec 2013 00:15:44 +0000
Subject: [issue19968] Using DESTDIR breaks sys.path
Message-ID: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>


New submission from Quanah Gibson-Mount:

I found that when trying to use Python with the "stow" utility, that it incorrectly hard codes the full DESTDIR path into python, instead of the relative portion of the DESTDIR path.  As a result, DESTDIR usage is fundamentally broken in relation to all other software packages I've ever built.  For example:

make install DESTDIR=/usr/local/stow/python-3.3.2

results in a sys.path that includes /usr/local/stow/python-3.3.2, when instead what is desired is just "/usr/local", so you can properly stow the package:

[quanah at git Python-3.3.2]$ python3
Python 3.3.2 (default, Dec 12 2013, 17:18:31)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.path)
['', '/usr/local/stow/python-3.3.2/lib/python33.zip', '/usr/local/stow/python-3.3.2/lib/python3.3', '/usr/local/stow/python-3.3.2/lib/python3.3/plat-linux', '/usr/local/stow/python-3.3.2/lib/python3.3/lib-dynload', '/usr/local/stow/python-3.3.2/lib/python3.3/site-packages']

Python itself was correctly built with --prefix=/usr/local, as that is the desired prefix.

----------
components: Build
messages: 205993
nosy: mishikal
priority: normal
severity: normal
status: open
title: Using DESTDIR breaks sys.path
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:20:30 2013
From: report at bugs.python.org (Quanah Gibson-Mount)
Date: Fri, 13 Dec 2013 00:20:30 +0000
Subject: [issue19968] Using DESTDIR breaks sys.path
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386894030.99.0.378262721584.issue19968@psf.upfronthosting.co.za>


Quanah Gibson-Mount added the comment:

Or to summarize a bit differently --

the point of DESTDIR is to allow you to install your software in some location other than what was specified with --prefix, without losing the --prefix settings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:22:21 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 13 Dec 2013 00:22:21 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1386894141.8.0.0324506177954.issue18986@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Mark, what was the use case you found?

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:29:48 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:29:48 +0000
Subject: [issue19969] PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c")
 don't check for character min/max value
Message-ID: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>


New submission from STINNER Victor:

PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c") overflow if the parameter is not in range [0; 255].

If nobody complained before, it's maybe not worth to fix the bug in Python 2.7 or 3.3.

----------
components: Interpreter Core
messages: 205996
nosy: haypo
priority: normal
severity: normal
status: open
title: PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c") don't check for character min/max value

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19969>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:30:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:30:45 +0000
Subject: [issue19969] PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c")
 don't check for character min/max value
In-Reply-To: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>
Message-ID: <1386894645.92.0.78758680249.issue19969@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a patch for Python 3.4.

----------
keywords: +patch
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file33108/bytes_fromformat_c.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19969>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:35:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:35:00 +0000
Subject: [issue19579] test_asyncio: test__run_once timings should be relaxed
In-Reply-To: <1384390800.99.0.143827109941.issue19579@psf.upfronthosting.co.za>
Message-ID: <1386894900.17.0.662537629158.issue19579@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't see the failure recently, thanks.

----------
components: +Tests
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19579>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:35:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:35:36 +0000
Subject: [issue19576] "Non-Python created threads" documentation doesn't
 mention PyEval_InitThreads()
In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>
Message-ID: <1386894936.2.0.972877939514.issue19576@psf.upfronthosting.co.za>


STINNER Victor added the comment:

So Antoine, what do you think of the fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19576>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:36:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 00:36:30 +0000
Subject: [issue19576] "Non-Python created threads" documentation doesn't
 mention PyEval_InitThreads()
In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>
Message-ID: <1386894990.27.0.974825151213.issue19576@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19576>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:36:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 00:36:41 +0000
Subject: [issue19566] ERROR: test_close
 (test.test_asyncio.test_unix_events.FastChildWatcherTests)
In-Reply-To: <1384301977.23.0.703867213373.issue19566@psf.upfronthosting.co.za>
Message-ID: <1386895001.38.0.352383486114.issue19566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I think the issue has been fixed, thanks.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19566>
_______________________________________

From report at bugs.python.org  Fri Dec 13 01:48:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 00:48:00 +0000
Subject: [issue19576] "Non-Python created threads" documentation doesn't
 mention PyEval_InitThreads()
In-Reply-To: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>
Message-ID: <3dgYBl2WqSz7LlP@mail.python.org>


Roundup Robot added the comment:

New changeset dc4e805ec68a by Victor Stinner in branch 'default':
Close #19576: PyGILState_Ensure() now initializes threads. At startup, Python
http://hg.python.org/cpython/rev/dc4e805ec68a

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19576>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:08:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 01:08:42 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <3dgYfd29dwz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset d2560fd8a008 by Victor Stinner in branch 'default':
Issue #14432: Remove the thread state field from the frame structure. Fix a
http://hg.python.org/cpython/rev/d2560fd8a008

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:16:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2013 01:16:25 +0000
Subject: [issue19968] Using DESTDIR breaks sys.path
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386897385.83.0.868136250973.issue19968@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:19:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 01:19:34 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <3dgYv82NdSz7LlB@mail.python.org>


Roundup Robot added the comment:

New changeset 0875e5bbe5f0 by Victor Stinner in branch '3.3':
Issue #14432: Generator now clears the borrowed reference to the thread state
http://hg.python.org/cpython/rev/0875e5bbe5f0

New changeset 55dd094a2b01 by Victor Stinner in branch 'default':
Issue #14432: Null merge 3.3, Python 3.4 has a different fix
http://hg.python.org/cpython/rev/55dd094a2b01

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:33:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 01:33:14 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <3dgZBw4scMz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 2f975036cf39 by Victor Stinner in branch '3.3':
Issue #14432: Fix compilation when thread support is disabled
http://hg.python.org/cpython/rev/2f975036cf39

New changeset 9852637f05c3 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #14432: Fix compilation when thread support is disabled
http://hg.python.org/cpython/rev/9852637f05c3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:39:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 01:39:39 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <3dgZLL3NW7z7LlB@mail.python.org>


Roundup Robot added the comment:

New changeset aa324af42c0e by Victor Stinner in branch '2.7':
Issue #14432: Generator now clears the borrowed reference to the thread state
http://hg.python.org/cpython/rev/aa324af42c0e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:41:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 01:41:54 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <1386898914.24.0.566551731073.issue14432@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks Mark Shannon for your patch. Sorry, I forgot to mention your name if the changesets :-/ I didn't remember the whole story of this issue.

It should now be fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:45:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 01:45:30 +0000
Subject: [issue19952] asyncio: test_wait_for_handle failure
In-Reply-To: <1386791713.28.0.425891775188.issue19952@psf.upfronthosting.co.za>
Message-ID: <3dgZT53k2lz7LlR@mail.python.org>


Roundup Robot added the comment:

New changeset a35b2d652449 by Victor Stinner in branch 'default':
Issue #19952: test_asyncio: relax timings of Windows events, buildbots are
http://hg.python.org/cpython/rev/a35b2d652449

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19952>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:45:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 01:45:50 +0000
Subject: [issue19952] asyncio: test_wait_for_handle failure
In-Reply-To: <1386791713.28.0.425891775188.issue19952@psf.upfronthosting.co.za>
Message-ID: <1386899150.6.0.370763540856.issue19952@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19952>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:46:56 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 01:46:56 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za>
Message-ID: <1386899216.0.0.991542732442.issue19619@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/issue19619>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:47:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 01:47:42 +0000
Subject: [issue19466] Clear state of threads earlier in Python shutdown
In-Reply-To: <1383262786.4.0.00831923947445.issue19466@psf.upfronthosting.co.za>
Message-ID: <1386899262.28.0.636212785227.issue19466@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm unable to reproduce the test_4_daemon_threads failure, can anyone try on Windows?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19466>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:49:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 01:49:43 +0000
Subject: [issue17786] Crash in test_ctypes.test_callbacks() on AMD64 NetBSD
 5.1.2 [SB] 3.x
In-Reply-To: <1366272232.44.0.752593622389.issue17786@psf.upfronthosting.co.za>
Message-ID: <1386899383.68.0.488883171605.issue17786@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is no more NetBSD buildbot, so I'm closing the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17786>
_______________________________________

From report at bugs.python.org  Fri Dec 13 02:54:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 01:54:54 +0000
Subject: [issue18746] test_threading.test_finalize_with_trace() fails on
 FreeBSD buildbot
In-Reply-To: <1376561660.51.0.498019291184.issue18746@psf.upfronthosting.co.za>
Message-ID: <1386899694.21.0.313222646457.issue18746@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't see this issue anymore on FreeBSD buildbots. It was probably fixed. The issue #19466 changed also the Python shutdown procedure.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18746>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:06:30 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 02:06:30 +0000
Subject: [issue19968] Using DESTDIR breaks sys.path
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386900390.01.0.469910658857.issue19968@psf.upfronthosting.co.za>


R. David Murray added the comment:

sys.path is computed dynamically at run time.  Try moving the install directory around on your filesystem, and you'll see.

I'm not familiar with stow, and I don't know if anyone else on the team is either, so you may have to explain your issue in more detail.  If there is a real issue here, my guess would be that the solution will be based on the new venv support.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:09:58 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 02:09:58 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
In-Reply-To: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>
Message-ID: <1386900598.7.0.487847037669.issue19957@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, here is the patch on which we removed checking of special case for iso-2022-*.

----------
Added file: http://bugs.python.org/file33109/minor_refactor_encoders_in_email_lib_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:32:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 02:32:05 +0000
Subject: [issue19787] tracemalloc: set_reentrant() should not have to call
 PyThread_delete_key()
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <3dgbVs0cltz7Llv@mail.python.org>


Roundup Robot added the comment:

New changeset 46393019b650 by Victor Stinner in branch 'default':
Close #19787: PyThread_set_key_value() now always set the value. In Python 3.3,
http://hg.python.org/cpython/rev/46393019b650

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:32:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:32:23 +0000
Subject: [issue19787] Fix PyThread_set_key_value() strange behaviour
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386901943.46.0.894420181593.issue19787@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: tracemalloc: set_reentrant() should not have to call PyThread_delete_key() -> Fix PyThread_set_key_value() strange behaviour

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:35:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:35:29 +0000
Subject: [issue19787] Fix PyThread_set_key_value() strange behaviour
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386902129.56.0.139496860392.issue19787@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, my change on PyThread_set_key_value() has an unexpected effect on _testcapi.run_in_subinterp(): it now fixes the Python thread state. Py_NewInterpreter() creates a second Python thread state for the current thread, but PyThread_set_key_value() ignored the second call setting the new thread state.

It's a little bit strange that nobody noticed this bug before. It doesn't fix issue #10915: test_threading still hangs when tracemalloc is enabled (I modified manually test.support.run_in_subinterp() for a manual test).

This issue should now be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:38:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:38:23 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1386902303.85.0.360511215512.issue15751@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI I fixed a weird behaviour of the PyThread_set_key_value() function. The change has indirectly on impact on test.support.run_in_subinterp():
http://bugs.python.org/issue19787#msg206015

So my change might have an effect on this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:40:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:40:26 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1386902426.38.0.97277665856.issue15751@psf.upfronthosting.co.za>


STINNER Victor added the comment:

They are now two issues (#10915 and this one) with many messages. Both issues are open. Can someone please make a summary? How can we fix the GIL/subinterpreter issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:41:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 02:41:18 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
In-Reply-To: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>
Message-ID: <3dgbjT5Y7fz7LpS@mail.python.org>


Roundup Robot added the comment:

New changeset 29e5dd1f608a by R David Murray in branch 'default':
#19957: Simplify encode_7or8bit now that _payload is always str.
http://hg.python.org/cpython/rev/29e5dd1f608a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:42:41 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 02:42:41 +0000
Subject: [issue19957] Minor refactor of Lib/email/encoders.py
In-Reply-To: <1386829279.51.0.373470600297.issue19957@psf.upfronthosting.co.za>
Message-ID: <1386902561.91.0.821993914483.issue19957@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Vajrasky and Serhiy.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19957>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:50:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:50:22 +0000
Subject: [issue19437] More failures found by pyfailmalloc
In-Reply-To: <1383071047.38.0.937526854844.issue19437@psf.upfronthosting.co.za>
Message-ID: <1386903022.15.0.39161149204.issue19437@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is no more pending patches nor known issues, so I'm closing this issue. I will open a new issue if I find new bugs.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19437>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:53:03 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:53:03 +0000
Subject: [issue19230] Reimplement the keyword module in C
In-Reply-To: <1381537991.31.0.762180400628.issue19230@psf.upfronthosting.co.za>
Message-ID: <1386903183.77.0.00295846909206.issue19230@psf.upfronthosting.co.za>


STINNER Victor added the comment:

So what? Do you want faster Python startup?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19230>
_______________________________________

From report at bugs.python.org  Fri Dec 13 03:57:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 02:57:07 +0000
Subject: [issue19229] operator.py: move the Python implementation in the else
 block of try/except ImportError
In-Reply-To: <1381535351.94.0.0685942795619.issue19229@psf.upfronthosting.co.za>
Message-ID: <1386903427.24.0.908369773333.issue19229@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"The real question for me is: why are you interested in speeding up the
import of the operator module? 200 ?s won't make a visible difference."

Alone, the gain is useless, but it's like the work done in Python 3.4 to avoid loading some modules at startup. The overall idea is to have a fast startup time.

I heard that Python 3 startup time is a major blocker point for Mercurial for example.

But maybe this specific issue is not worth the trouble. (Other parts should be optimized.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19229>
_______________________________________

From report at bugs.python.org  Fri Dec 13 04:17:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 03:17:45 +0000
Subject: [issue19787] Fix PyThread_set_key_value() strange behaviour
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386904665.75.0.134915138043.issue19787@psf.upfronthosting.co.za>


STINNER Victor added the comment:

My commit broke test_capi, so I revert it. Here is the commit as a patch.

The impact on subinterpreters is more complex than what I expected. A decision should be take on what to do: mimic behaviour of Python 3.3 for subinterpreters (don't replace the Python thread state when a new subinterpreter is created), or fix code using subinterpreters.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file33110/pythread_set_key_value-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Fri Dec 13 08:30:20 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2013 07:30:20 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386919820.52.0.37464318801.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

Nick: that sounds good to me.  I like the idea of find_spec() being the same as import_module(), minus actually loading the module.

In that spirit, here's a rough patch that accomplishes that.  It refactors things a bit to get there.  Considering where we are in the release cycle, I'd rather punt on a proper rendition like this this until 3.5.  In the meantime we could duplicate some code for the sake of find_spec() in the 3.4 timeframe.

----------
Added file: http://bugs.python.org/file33111/issue19944-find-spec-mirror-import-module.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Fri Dec 13 08:35:45 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 Dec 2013 07:35:45 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <CAH_1eM2ECck8u7PX9-yf+-SYNsMWut_L+M1ak1DmnDd1_s1gVw@mail.gmail.com>
Message-ID: <CAH_1eM1g8td3T5Ju9+y2o==5mo3vFOk0YrHJDB99bZJBW=Ls5w@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Actually no, I don't understand this patch: if the makefile was correct, C
files depending on Include/Python-ast.h and Python/Python-ast.c shouldn't
be built before those files have been generated by asdl_c.py.
The problem doesn't lie in the non-atomicity, but in the make file
dependency graph.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Fri Dec 13 08:49:14 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 Dec 2013 07:49:14 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1386920954.34.0.891412033107.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a version that I'd feel more comfortable with for 3.4 (with the intent of refactoring in 3.5).

----------
Added file: http://bugs.python.org/file33112/issue19944-find-spec-mirror-import-module-simple.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Fri Dec 13 09:12:25 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 13 Dec 2013 08:12:25 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1386922345.4.0.596950588157.issue18986@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Mark, what was the use case you found?

It's essentially an IdentityDict, though I've found other more specific transforms useful.

I was writing a tool to find reference cycles between Python objects (we have a customer application that's working in a multithreaded COM environment and has to ensure that COM objects are released on the same types of threads they were created on, so we have to be careful about cyclic garbage and delayed garbage collection).

The graph of Python objects (class 'ObjectGraph') is modelled as a fairly standard directed graph (set of vertices, set of edges, two dictionaries mapping each edge to its head and tail), but of course for this application the dict and set have to be based on object identity rather than normal equality.  Using a TransformDict (and an IdentitySet) lets me write the standard graph algorithms (e.g., for finding strongly connected components) in a natural way, leaving it to the TransformDict and IdentitySet to do the necessary id() conversions under the hood.)

I also have a similar AnnotatedGraph object (a sort of offline version of the ObjectGraph), where the edges and vertices carry additional information and it's convenient to be able to use a lightweight ID rather than an entire vertex or edge as a dictionary key.  Again, using a TransformDict lets one hide the details and present the graph manipulation code readably and naturally.

Some code here, if you're interested:

https://github.com/mdickinson/refcycle/blob/refactor/refcycle/object_graph.py

Caveat: it's work in progress.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Dec 13 09:30:38 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 Dec 2013 08:30:38 +0000
Subject: [issue19466] Clear state of threads earlier in Python shutdown
In-Reply-To: <1386899262.28.0.636212785227.issue19466@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2ovq3e9KbYW1R85dZcBMdbjrz02EwaLbKLtP+Tx70-FA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Hum...
Correct me if I'm wrong, but destroying the thread state of daemon threads
while they're running is really a bad idea in fact: for example, if
warnings are now emitted for unclosed file objects, this means that the
file object, and all associated buffers, are destroyed.
But even though the daemon thread doesn't hold the GIL, he might still be
using this object.

For example, if we have:
daemon thread:
readinto:
    release_gil
    read(fd, fileobj->buffer, fileobj->size)
    acquire_gil

and the main thread exits, then fileobj will be deallocated.

It's actually fairly easy to write a short crasher launching a deamon
thread reading from e.g. /dev/zero in loop, with the main thread exiting
right in the middle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19466>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:03:13 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 13 Dec 2013 09:03:13 +0000
Subject: [issue19230] Reimplement the keyword module in C
In-Reply-To: <1381537991.31.0.762180400628.issue19230@psf.upfronthosting.co.za>
Message-ID: <1386925393.5.0.472806828526.issue19230@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I still like the idea, too. It's more elegant, easier to maintain and gives a speedup, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19230>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:19:26 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 13 Dec 2013 09:19:26 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386926366.47.0.175246552342.issue19965@psf.upfronthosting.co.za>


Charles-Fran?ois Natali added the comment:

Here's a patch.

----------
Added file: http://bugs.python.org/file33113/makefile_ast_h.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:28:46 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:28:46 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
Message-ID: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

ethan at amiau:~/Documents/code/python/cpython3.4$ grep -R immediatly *
Doc/library/asyncio-protocol.rst::meth:`Transport.close` can be called immediatly after
Lib/test/test_signal.py:            # unblock the pending signal calls immediatly the signal handler
Modules/faulthandler.c:    /* call the previous signal handler: it is called immediatly if we use
ethan at amiau:~/Documents/code/python/cpython3.4$ grep -R " agin " *
Modules/posixmodule.c:           the symlink path agin and not the actual final path. */
Modules/posixmodule.c:           the symlink path agin and not the actual final path. */

----------
assignee: docs at python
components: Documentation, Extension Modules, Library (Lib)
files: fix_typo_agin_and_immediatly_python34.patch
keywords: patch
messages: 206031
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Typo of `immediatly` and `agin` words
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33114/fix_typo_agin_and_immediatly_python34.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:28:57 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:28:57 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1386926937.7.0.311603712462.issue19970@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33115/fix_typo_agin_and_immediatly_python33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:35:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 09:35:20 +0000
Subject: [issue19466] Clear state of threads earlier in Python shutdown
In-Reply-To: <1383262786.4.0.00831923947445.issue19466@psf.upfronthosting.co.za>
Message-ID: <1386927320.06.0.243682782508.issue19466@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"It's actually fairly easy to write a short crasher launching a deamon
thread reading from e.g. /dev/zero in loop, with the main thread exiting
right in the middle."

I'm unable to write such crasher, can you please give an example? Are you able to crash Python on Linux or on Python 3.3?

Does the threading test makes sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19466>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:38:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 09:38:38 +0000
Subject: [issue19969] PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c")
 don't check for character min/max value
In-Reply-To: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>
Message-ID: <1386927518.79.0.43386935681.issue19969@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch for Serhiy's remark (replace ValueError with OverflowError).

----------
Added file: http://bugs.python.org/file33116/bytes_fromformat_c-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19969>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:40:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 09:40:52 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <1386927652.26.0.620077815049.issue19965@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> neologix
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:49:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 09:49:55 +0000
Subject: [issue19969] PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c")
 don't check for character min/max value
In-Reply-To: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>
Message-ID: <1386928195.41.0.265887913822.issue19969@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> haypo
stage:  -> commit review
type:  -> behavior
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19969>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:54:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 13 Dec 2013 09:54:50 +0000
Subject: [issue19971] Remove Tulip words from asyncio documentation/code
Message-ID: <1386928490.02.0.72947185095.issue19971@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

I was reading the documentation about asyncio. Here is the introduction paragraph:

Doc/library/asyncio.rst
=======================

This module provides infrastructure for writing single-threaded concurrent
code using coroutines, multiplexing I/O access over sockets and other
resources, running network clients and servers, and other related primitives.
Here is a more detailed list of the package contents:

Then I read it like a novel. Then somewhere out of the blue, the Tulip word shows up.

Doc/library/asyncio-sync.rst
============================

Unlike the standard library :mod:`queue`, you can reliably know this Queue's
   size with :meth:`qsize`, since your single-threaded Tulip application won't
   be interrupted between calling :meth:`qsize` and doing an operation on the
   Queue.

The Tulip word breaks the flow of the story because we never introduce the Tulip word previously. There are two ways to handle this situation:
1. Introduce the Tulip word in the introduction and other parts consistently,
2. Remove the references to Tulip.

I suggest we take option 2 (users of Python 3.4 asyncio stdlib have no reason to know the word Tulip). Here is the patch.

----------
assignee: docs at python
components: Documentation
files: remove_Tulip.patch
keywords: patch
messages: 206036
nosy: docs at python, gvanrossum, vajrasky
priority: normal
severity: normal
status: open
title: Remove Tulip words from asyncio documentation/code
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33117/remove_Tulip.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19971>
_______________________________________

From report at bugs.python.org  Fri Dec 13 10:59:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 09:59:19 +0000
Subject: [issue19971] Remove Tulip words from asyncio documentation/code
In-Reply-To: <1386928490.02.0.72947185095.issue19971@psf.upfronthosting.co.za>
Message-ID: <1386928759.1.0.159179341652.issue19971@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I agree to drop references to the Tulip name. Thanks for your patch.

changeset:   87927:10378199e37b
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Fri Dec 13 10:57:04 2013 +0100
files:       Doc/library/asyncio-sync.rst Doc/whatsnew/3.4.rst Lib/asyncio/queues.py Lib/asyncio/test_utils.py
description:
asyncio: remove references to the Tulip project, rename Tulip to asyncio.
Patch written by Vajrasky Kok.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19971>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:00:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 10:00:33 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1386928833.69.0.876582139262.issue17919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The disadvantage of 'H' is that it never raises OverflowError.

The simplest solution is just revert a part of the patch for issue15989.

----------
assignee:  -> serhiy.storchaka
versions:  -Python 3.2, Python 3.3, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:12:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 10:12:08 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <3dgnjh1WK7z7M16@mail.python.org>


Roundup Robot added the comment:

New changeset 08c95dd68cfc by Serhiy Storchaka in branch '3.3':
Issue #17919: select.poll.poll() again works with poll.POLLNVAL on AIX.
http://hg.python.org/cpython/rev/08c95dd68cfc

New changeset e78743e03c8f by Serhiy Storchaka in branch 'default':
Issue #17919: select.poll.poll() again works with poll.POLLNVAL on AIX.
http://hg.python.org/cpython/rev/e78743e03c8f

New changeset 64f32a31cd49 by Serhiy Storchaka in branch '2.7':
Issue #17919: select.poll.poll() again works with poll.POLLNVAL on AIX.
http://hg.python.org/cpython/rev/64f32a31cd49

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:13:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:13:02 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1386929582.81.0.395382067417.issue17919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The disadvantage of 'H' is that it never raises OverflowError.

The correct fix is to write a new parser just for this function.

See for example uint_converter() in Modules/zlibmodule.c. I would prefer to add such new parser to Python/getargs.c directly, but I was not motivated when I fixed #18294 (integer overflow in the zlib module).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:14:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 10:14:19 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <3dgnmC2754z7LlF@mail.python.org>


Roundup Robot added the comment:

New changeset 5d078b0bae75 by Victor Stinner in branch 'default':
Issue #19787: PyThread_set_key_value() now always set the value
http://hg.python.org/cpython/rev/5d078b0bae75

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:14:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 10:14:20 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <3dgnmD0dwwz7LkG@mail.python.org>


Roundup Robot added the comment:

New changeset 5d078b0bae75 by Victor Stinner in branch 'default':
Issue #19787: PyThread_set_key_value() now always set the value
http://hg.python.org/cpython/rev/5d078b0bae75

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:14:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 10:14:21 +0000
Subject: [issue19787] Fix PyThread_set_key_value() strange behaviour
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <3dgnmD60GRz7LlP@mail.python.org>


Roundup Robot added the comment:

New changeset 5d078b0bae75 by Victor Stinner in branch 'default':
Issue #19787: PyThread_set_key_value() now always set the value
http://hg.python.org/cpython/rev/5d078b0bae75

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:14:34 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 10:14:34 +0000
Subject: [issue19972] Leak in pickle (?)
Message-ID: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Hi Alexandre, the following leaks appear after 64c6d52793be. I'm
not sure yet if they're caused or just exposed by the changeset.


Code:
==============
import sys
import pickle
sys.exit(0)
==============


==8118== 864 (192 direct, 672 indirect) bytes in 3 blocks are definitely lost in loss record 2,198 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x534092: _PyObject_GC_New (gcmodule.c:1749)
==8118==    by 0x450CDF: new_dict (dictobject.c:391)
==8118==    by 0x4527BB: _PyDict_NewPresized (dictobject.c:1043)
==8118==    by 0x4DCAFD: PyEval_EvalFrameEx (ceval.c:2366)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)


==8118== 2,112 (128 direct, 1,984 indirect) bytes in 2 blocks are definitely lost in loss record 2,301 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x4734D9: PyType_GenericAlloc (typeobject.c:784)
==8118==    by 0x456438: dict_new (dictobject.c:2604)
==8118==    by 0x473355: type_call (typeobject.c:751)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E6313: do_call (ceval.c:4454)
==8118==    by 0x4E57B5: call_function (ceval.c:4252)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118== 


==8118== 2,402 (64 direct, 2,338 indirect) bytes in 1 blocks are definitely lost in loss record 2,304 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x534092: _PyObject_GC_New (gcmodule.c:1749)
==8118==    by 0x450CDF: new_dict (dictobject.c:391)
==8118==    by 0x450E4C: PyDict_New (dictobject.c:429)
==8118==    by 0x45F97D: module_init (moduleobject.c:372)
==8118==    by 0x47342B: type_call (typeobject.c:766)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E6313: do_call (ceval.c:4454)
==8118==    by 0x4E57B5: call_function (ceval.c:4252)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E5ACA: fast_function (ceval.c:4322)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118== 

==8118== 4,919 (64 direct, 4,855 indirect) bytes in 1 blocks are definitely lost in loss record 2,347 of 2,365
==8118==    at 0x4C28B8C: malloc (vg_replace_malloc.c:270)
==8118==    by 0x41D12A: _PyMem_RawMalloc (obmalloc.c:60)
==8118==    by 0x41D5E9: PyObject_Malloc (obmalloc.c:351)
==8118==    by 0x533FC9: _PyObject_GC_Malloc (gcmodule.c:1726)
==8118==    by 0x534092: _PyObject_GC_New (gcmodule.c:1749)
==8118==    by 0x450CDF: new_dict (dictobject.c:391)
==8118==    by 0x450E15: new_dict_with_shared_keys (dictobject.c:420)
==8118==    by 0x458477: _PyObjectDict_SetItem (dictobject.c:3746)
==8118==    by 0x46215A: _PyObject_GenericSetAttrWithDict (object.c:1143)
==8118==    by 0x462394: PyObject_GenericSetAttr (object.c:1185)
==8118==    by 0x4618E4: PyObject_SetAttr (object.c:914)
==8118==    by 0x4DABEB: PyEval_EvalFrameEx (ceval.c:2111)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x5A1348: method_call (classobject.c:347)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x482B2A: slot_tp_init (typeobject.c:5895)
==8118==    by 0x47342B: type_call (typeobject.c:766)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E6313: do_call (ceval.c:4454)
==8118==    by 0x4E57B5: call_function (ceval.c:4252)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4E5BF7: fast_function (ceval.c:4332)
==8118==    by 0x4E5796: call_function (ceval.c:4250)
==8118==    by 0x4DF8C7: PyEval_EvalFrameEx (ceval.c:2826)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x5A1348: method_call (classobject.c:347)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42632D: PyObject_CallFunctionObjArgs (abstract.c:2381)
==8118==    by 0x4DF288: PyEval_EvalFrameEx (ceval.c:2711)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x5B05F2: function_call (funcobject.c:632)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x42619E: _PyObject_CallMethodIdObjArgs (abstract.c:2359)
==8118==    by 0x502FBE: PyImport_ImportModuleLevelObject (import.c:1473)
==8118==    by 0x4CC3EC: builtin___import__ (bltinmodule.c:210)
==8118==    by 0x5B11D5: PyCFunction_Call (methodobject.c:99)
==8118==    by 0x4252E7: PyObject_Call (abstract.c:2087)
==8118==    by 0x4E4E01: PyEval_CallObjectWithKeywords (ceval.c:4101)
==8118==    by 0x4DD718: PyEval_EvalFrameEx (ceval.c:2466)
==8118==    by 0x4E3340: PyEval_EvalCodeEx (ceval.c:3576)
==8118==    by 0x4D3A59: PyEval_EvalCode (ceval.c:770)
==8118==    by 0x4CD6BE: builtin_exec (bltinmodule.c:876)
==8118==    by 0x5B11B3: PyCFunction_Call (methodobject.c:93)
==8118==    by 0x4E6946: ext_do_call (ceval.c:4546)
==8118==    by 0x4DFC60: PyEval_EvalFrameEx (ceval.c:2866)
==8118==

----------
components: Extension Modules
messages: 206044
nosy: alexandre.vassalotti, skrah
priority: normal
severity: normal
status: open
title: Leak in pickle (?)
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:20:38 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Dec 2013 10:20:38 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1386930038.48.0.254699789255.issue15582@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hello!

Here's a patch. Currently it lacks doc updates, but if the solution is okay, then I could provide them.

----------
keywords: +patch
nosy: +Claudiu.Popa
Added file: http://bugs.python.org/file33118/inspect_getdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15582>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:21:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:21:23 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1386930083.62.0.255853577592.issue17919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The simplest solution is just revert a part of the patch for issue15989.

The revert reintroduced the integer overflow:

         self->ufds[i].events = (short)PyLong_AsLong(value);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:22:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:22:06 +0000
Subject: [issue10915] Make the PyGILState API compatible with multiple
 interpreters
In-Reply-To: <1295103161.75.0.771875465176.issue10915@psf.upfronthosting.co.za>
Message-ID: <1386930126.62.0.44451041768.issue10915@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #15751.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10915>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:23:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:23:22 +0000
Subject: [issue15751] Support subinterpreters in the GIL state API
In-Reply-To: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>
Message-ID: <1386930202.39.0.103788711926.issue15751@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> FYI I fixed a weird behaviour of the PyThread_set_key_value() function. > The change has indirectly on impact on test.support.run_in_subinterp():

The impact was a bug. I reverted my changeset and pushed a new changeset which leaves _PyGILState_NoteThreadState() unchanged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15751>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:24:56 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:24:56 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386930296.94.0.238992952844.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm closing this issue as invalid for the same reason than I closed the issue #19846:
http://bugs.python.org/issue19846#msg205675

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19847>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:34:28 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Dec 2013 10:34:28 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1386930868.02.0.740334272262.issue19385@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Serhiy, what's the status for this? Should this be targeted for 3.5?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:40:43 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 10:40:43 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386931243.91.0.233381021738.issue19972@psf.upfronthosting.co.za>


Stefan Krah added the comment:

This patch fixes the leak, but needs review (I do not know the _pickle module
very well).

----------
keywords: +patch
Added file: http://bugs.python.org/file33119/issue19972.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:45:33 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 10:45:33 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386931533.33.0.397840921474.issue19972@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:56:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 10:56:30 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1386932190.79.0.109065320116.issue17919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which uses special converter.

----------
versions: +Python 3.3
Added file: http://bugs.python.org/file33120/poll_events_mask_overflow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 11:58:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 10:58:17 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386932297.45.0.761314106061.issue19972@psf.upfronthosting.co.za>


STINNER Victor added the comment:

According to the example in the PEP 3121, issue19972.patch is not needed.

In practice, I don't see in PyImport_Cleanup() where tp_clear is called. This function calls:

   _PyModule_Clear(mod);
   Py_DECREF(mod);

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:00:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 11:00:32 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1386932432.69.0.459565736266.issue17919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+    if (uval > USHRT_MAX) {
+        PyErr_SetString(PyExc_OverflowError,
+                        "Python int too large for C unsigned int");

The message should be "C unsigned short".

The unit tests don't check that USHRT_MAX value is accepted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:01:31 2013
From: report at bugs.python.org (Sworddragon)
Date: Fri, 13 Dec 2013 11:01:31 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386932491.59.0.654504019093.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

>> The fact that write() uses sys.getfilesystemencoding() is either
>> a defect or a bad design (I leave the decision to you).

> I have good news for you.  write() does not cal sys.getfilesystemencoding(), because the encoding is set at the time the > file is opened.

Now after some researching I see I wasn't wrong at all. I should've been sayed:

"The fact that write() -> open() relies on sys.getfilesystemencoding() (respectively locale.getpreferredencoding()) at default as encoding is either a defect or a bad design (I leave the decision to you)."

Or am I overlooking something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:04:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 11:04:18 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1386932658.87.0.00226540158814.issue17919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

With  poll_events_mask_overflow.patch, the following hack can maybe be removed?

            /* The &0xffff is a workaround for AIX.  'revents'
               is a 16-bit short, and IBM assigned POLLNVAL
               to be 0x8000, so the conversion to int results
               in a negative number. See SF bug #923315. */
            num = PyLong_FromLong(self->ufds[i].revents & 0xffff);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:04:45 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 11:04:45 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386932685.74.0.423094560463.issue19972@psf.upfronthosting.co.za>


Stefan Krah added the comment:

See #11826 for more details where the freefunc is called.  Perhaps the.
docs or the PEP need an update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:09:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 11:09:14 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1386932954.66.0.850059540228.issue19385@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Regarding the first issue, I don't believe that the result will be as readable (but I agree with you that it will be better).

Yes, perhaps performance of the dbm.dumb module is not worst this cost. Are you have any benchmarking results?

The patch LGTM.

> Should this be targeted for 3.5?

I think yes.

----------
stage:  -> commit review
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:11:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 11:11:50 +0000
Subject: [issue19787] Fix PyThread_set_key_value() strange behaviour
In-Reply-To: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>
Message-ID: <1386933110.51.0.219843951183.issue19787@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19787>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:18:17 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 11:18:17 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386932297.45.0.761314106061.issue19972@psf.upfronthosting.co.za>
Message-ID: <20131213111816.GA8842@sleipnir.bytereef.org>


Stefan Krah added the comment:

The docs say:

inquiry m_clear

    A clear function to call during GC clearing of the module object, or NULL if not needed.

freefunc m_free

    A function to call during deallocation of the module object, or NULL if not needed.

So I assume that GC clearing is not happening if sys.exit() is called.  Note that
the leak only occurs with sys.exit().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:41:24 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 11:41:24 +0000
Subject: [issue19973] Deprecate pyio
Message-ID: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Does it make sense to finally deprecate pyio, so we can eventually delete it?

----------
messages: 206060
nosy: larry
priority: normal
severity: normal
status: open
title: Deprecate pyio
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:41:35 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 11:41:35 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386934895.32.0.385857857685.issue19973@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:44:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 11:44:45 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386935085.36.0.0315975040461.issue19973@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I like the _pyio module! It's useful to test some new features.

For example, I'm using it to identify where a file is destroyed without being closed (get where the object was created):
https://bitbucket.org/haypo/misc/src/tip/python/res_warn.py

I didn't find how to implement that using the C module.

It's name is "_pyio", not "pyio". It is a private module.

It was also written to provide a working and well tested pure Python implementation for other Python virtual machines like PyPy, IronPython and Jython.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:47:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 11:47:51 +0000
Subject: [issue19969] PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c")
 don't check for character min/max value
In-Reply-To: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>
Message-ID: <3dgqr659W5zSsf@mail.python.org>


Roundup Robot added the comment:

New changeset 68e0dbc492de by Victor Stinner in branch '3.3':
Issue #19969: PyBytes_FromFormatV() now raises an OverflowError if "%c"
http://hg.python.org/cpython/rev/68e0dbc492de

New changeset 969e38b2f336 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #19969: PyBytes_FromFormatV() now raises an OverflowError if
http://hg.python.org/cpython/rev/969e38b2f336

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19969>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:49:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 11:49:32 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386935372.94.0.713280361349.issue19973@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Larry, I think Brett won't like you.
(have you read PEP 399?)

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:51:56 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 11:51:56 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386935516.6.0.0363791551589.issue19973@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I hadn't!  I guess we're signed up to maintain two implementations of a bunch of things for eternity, then.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:58:51 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 11:58:51 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386935931.95.0.013903044656.issue19846@psf.upfronthosting.co.za>


Larry Hastings added the comment:

> "The fact that write() -> open() relies on sys.getfilesystemencoding()
> (respectively locale.getpreferredencoding()) at default as encoding is
> either a defect or a bad design (I leave the decision to you)."
>
> Or am I overlooking something?

First, you should probably just drop mentioning write() or print() or any of the functions that actually perform I/O.  The crucial decisions about decoding are made inside open().

Second, open() is implemented in C.  It cannot "rely on sys.getfilesystemencoding()" as it never calls it.  Internally, sys.getfilesystemencoding() simply returns a C global called Py_FileSystemDefaultEncoding.  But open() doesn't examine that, either.

Instead, open() determines the default encoding by calling the same function that's used to initialize Py_FileSystemDefaultEncoding: get_locale_encoding() in Python/pythonrun.c.  Which on POSIX systems calls the POSIX function nl_langinfo().

If you want to see the actual mechanisms involved, you should read the C source code in Modules/_io in the Python trunk.  open() is implemented as the C function io_open() in _iomodule.c.  When it opens a file in text mode without an explicit encoding, it wraps it in a TextIOWrapper object; the __init__ function for this class is the C function textiowrapper_init() in textio.c.

As for your assertion that this is "either a defect or a bad design": I leave the critique of that to others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:59:08 2013
From: report at bugs.python.org (Antony Mayi)
Date: Fri, 13 Dec 2013 11:59:08 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
Message-ID: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>


New submission from Antony Mayi:

tarfile.py compared to GNU tar doesn't overwrite existing symlink with directory of same name if such directory exists in the extracted tarball.

----------
components: Library (Lib)
messages: 206066
nosy: antonymayi
priority: normal
severity: normal
status: open
title: tarfile doesn't overwrite symlink by directory
type: behavior
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19974>
_______________________________________

From report at bugs.python.org  Fri Dec 13 12:59:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 11:59:27 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386935967.8.0.410067176063.issue19972@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yeah, it sounds logical for m_free to do the clearing too (same as tp_dealloc vs. tp_clear).

Note that the PEP 3121 scheme turns out to be problematic for proper resource management: https://mail.python.org/pipermail/python-dev/2013-August/127862.html

----------
nosy: +ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:05:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 12:05:10 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1386936310.78.0.24484577008.issue19974@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19974>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:19:49 2013
From: report at bugs.python.org (Sworddragon)
Date: Fri, 13 Dec 2013 12:19:49 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386937189.81.0.736900543235.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

> Instead, open() determines the default encoding by calling the same function that's used to initialize Py_FileSystemDefaultEncoding: get_locale_encoding() in Python/pythonrun.c.  Which on POSIX systems calls the POSIX function nl_langinfo().

open() will use at default the encoding of nl_langinfo() as sys.getfilesystemencoding() does on *nix. This is the part that looks dirty to me. As soon as LANG is set to C open() will rely on 'ascii' due to nl_langinfo() like sys.getfilesystemencoding() does too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:40:41 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Dec 2013 12:40:41 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1386938441.08.0.94665488206.issue19385@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Here's a benchmark:

- with current patch:


# ./python -S -m timeit -n 10000 -s 'import dbm.dumb as dbm; d=dbm.open("x.dat", "c");d.close()' 'try:' '  len(d)' 'except OSError:' '  pass'
10000 loops, best of 3: 1.78 usec per loop


- using 
 try:
     return len(self._index)
 except TypeError:
     raise error('...')


# ./python -S -m timeit -n 10000 -s 'import dbm.dumb as dbm; d=dbm.open("x.dat", "c");d.close()' 'try:' '  len(d)' 'except OSError:' '  pass'
10000 loops, best of 3: 3.27 usec per loop


Now this seems odd, maybe catching + reraising an exception has a greater overhead than a func call and checking if an attribute is None. Anyway, I agree that dbm.dumb is not performance critical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:47:55 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Dec 2013 12:47:55 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <1386938875.11.0.751754850645.issue14432@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

I agree that this is an improvement, but isn't it a bit late for removing a public field from a public header file in 3.4, without any preceding deprecation?

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:51:39 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Dec 2013 12:51:39 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1386937189.81.0.736900543235.issue19846@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cfXHR+iKYPyPB70oBTc2h33SW6pB-UvtmJ5iiq4Yf=aw@mail.gmail.com>


Nick Coghlan added the comment:

There's an alternative to trying to force a different encoding for the
standard streams when the OS claims ASCII as the OS encoding: we can
default to surrogateescape as the error handler, on the assumption that
whatever the *real* OS encoding is, it definitely isn't ASCII.

That means we'll still complain about displaying improperly encoded data
when the OS suggests a plausible encoding, but we won't fail entirely just
because someone enabled (deliberately or accidentally) the POSIX locale.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 13:57:59 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 Dec 2013 12:57:59 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1386938875.11.0.751754850645.issue14432@psf.upfronthosting.co.za>
Message-ID: <CADiSq7deeDop-qgR8JGpsnv6nzP_oRiXr9OK2dTE3YzfbNQfWg@mail.gmail.com>


Nick Coghlan added the comment:

Unfortunately Stefan has a point - what's the migration path for C API
users that were relying on that struct field?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:15:36 2013
From: report at bugs.python.org (Reuben Garrett)
Date: Fri, 13 Dec 2013 13:15:36 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1386444925.92.0.761499023098.issue19901@psf.upfronthosting.co.za>
Message-ID: <CAA-SZJEq+hQuHHCVQKuh7wnbKG6kOSkTxg5rvbzooG9QVRq34Q@mail.gmail.com>


Reuben Garrett added the comment:

On Sat, Dec 7, 2013 at 1:35 PM, Gregory P. Smith <report at bugs.python.org>wrote:

> I fixed this in 3.3 and 3.4 several weeks ago.
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19901>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:19:18 2013
From: report at bugs.python.org (Reuben Garrett)
Date: Fri, 13 Dec 2013 13:19:18 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1386444925.92.0.761499023098.issue19901@psf.upfronthosting.co.za>
Message-ID: <CAA-SZJGaEfkBywHGdgcOSgqZzc+fMSBR=DFEnFC=knxOXbP7Wg@mail.gmail.com>


Reuben Garrett added the comment:

On Sat, Dec 7, 2013 at 1:35 PM, Gregory P. Smith <report at bugs.python.org>
wrote:
> I fixed this in 3.3 and 3.4 several weeks ago.

Sorry for the duplicate message a few moments ago ? "fat-fingered" my send
button.

So, has the fix just not reached the Portage tree yet? I don't fully
understand how upstream commits reach Portage, and would appreciate any
direction you might have to avoid reporting something already fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19901>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:22:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 13:22:38 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <CADiSq7deeDop-qgR8JGpsnv6nzP_oRiXr9OK2dTE3YzfbNQfWg@mail.gmail.com>
Message-ID: <CAMpsgwZ4AykQ3KzmfqsR8tT42z9_CSnjTRMDaqZFN5OYF=qmFg@mail.gmail.com>


STINNER Victor added the comment:

> I agree that this is an improvement, but isn't it a bit late for removing a public field from a public header file in 3.4, without any preceding deprecation?

The header is not public, it is private. The structure in not
documented (in Doc/c-api/*.rst). There is only one public documented
method: PyFrame_GetLineNumber().

If you rely on such implement detail (PyFrameObject field), you have
to be prepared for breakage between Python releases (3.x).

Do you know applications relying on the field?

How don't see how you would like to deprecate the field since it's
private and not documented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:28:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 13:28:59 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <CAMpsgwZ4AykQ3KzmfqsR8tT42z9_CSnjTRMDaqZFN5OYF=qmFg@mail.gmail.com>
Message-ID: <CAMpsgwav=VrjMS9euE5Dv=VmS4z+Yoy15n6MiiU1HpsDgEiWSw@mail.gmail.com>


STINNER Victor added the comment:

2013/12/13 Victor Stinner <victor.stinner at gmail.com>:
> The header is not public, it is private.

Hum, I'm not clear. frameobject.h is not included in Python.h, so the
classic #include "Python.h" doesn't give you access to PyFrameObject
structure. You have to add a second #include "frameobject.h". All
definitions in this header are also surrounded by #ifndef
Py_LIMITED_API ... #endif, so the fields are not part of the stable
API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:33:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 13:33:16 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <3dgt9l6Ypdz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 278dd7eb2f2b by Victor Stinner in branch 'default':
Issue #14432: Document the removal of the PyFrameObject.f_tstate field
http://hg.python.org/cpython/rev/278dd7eb2f2b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:34:53 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Dec 2013 13:34:53 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <1386941693.29.0.344998656345.issue14432@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> what's the migration path for C API users that were relying on that struct field?

Depends on how you use it, I guess. In many cases (at least for Cython and likely some other low-level tools), it could be as simple as

#if PY_VERSION_HEX < 0x030400B2
    // set "f_tstate" here
#endif

My guess is that some (most?) code that sets this field only does so because CPython previously depended on it being set. (Stackless comes to mind, not sure if that's supposed to work with 3.x...)

Read access is an entirely different thing, though. No idea what other tools might be using it for. I'm sure there are debugging/tracing tools out there that make use of the frame internals. Would it be correct for them to just use the current thread state instead? E.g. from a signal handler that analysis the current threads?

On a quick look through Ohloh's code search I only found a couple of other occurrences outside of CPython so far.

http://code.ohloh.net/search?s=%22f_tstate%22&fe=c&filterChecked=true

Disclaimer: it's easy to fix for me with the above conditional, so I won't argue much about keeping up compatibility here. I'm merely raising the issue because there is evidently code that this change breaks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:38:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 13:38:11 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <CAMpsgwav=VrjMS9euE5Dv=VmS4z+Yoy15n6MiiU1HpsDgEiWSw@mail.gmail.com>
Message-ID: <1386941888.2319.1.camel@fsol>


Antoine Pitrou added the comment:

> All
> definitions in this header are also surrounded by #ifndef
> Py_LIMITED_API ... #endif, so the fields are not part of the stable
> API.

"Stable ABI", not API.

That said, I agree the field should have been private anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:38:44 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Dec 2013 13:38:44 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1386941924.46.0.962266162758.issue18986@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:46:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 13:46:08 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1386941693.29.0.344998656345.issue14432@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYX884dMxQZL+0=cUKySRxM8Xmww8arM4gEOm=b4a=r3w@mail.gmail.com>


STINNER Victor added the comment:

> Depends on how you use it, I guess. In many cases (at least for Cython and likely some other low-level tools), it could be as simple as
>
> #if PY_VERSION_HEX < 0x030400B2
>     // set "f_tstate" here
> #endif

Why would you set f_tstate field? Frame constructor (PyFrame_New) and
Generators (gen_send_ex) do it for you.

Cython does touch this field? Stackless Python supports Python 3 (3.4)?

If something relies on f_tstate, it's easy to avoid this field.

> Would it be correct for them to just use the current thread state instead? E.g. from a signal handler that analysis the current threads?

The faulthandler has different low-level C signal handlers and it
doesn't use f_tstate, but PyGILState_GetThisThreadState() (or
PyThreadState_Get() if thread support is disabled).

I was surprised that it was so easy to modify ceval.c: in most cases,
you already have the thread state. So I just passed the thread state
to the function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:47:25 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 13:47:25 +0000
Subject: [issue19230] Reimplement the keyword module in C
In-Reply-To: <1381537991.31.0.762180400628.issue19230@psf.upfronthosting.co.za>
Message-ID: <1386942445.81.0.0158177436828.issue19230@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Two things. One, no one has shown a startup improvement using the official startup benchmarks (either normal or nosite). That needs to be established to show an actual benefit.

Second, PEP 399 requires the pure Python version stick around, else you need to request an exception to drop keyword.py from python-dev.

I think you have a chance of getting the exception if you can show an actual startup improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19230>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:50:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 13:50:06 +0000
Subject: [issue19230] Reimplement the keyword module in C
In-Reply-To: <1381537991.31.0.762180400628.issue19230@psf.upfronthosting.co.za>
Message-ID: <1386942606.55.0.148228661761.issue19230@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Second, PEP 399 requires the pure Python version stick around, else you need to request an exception to drop keyword.py from python-dev.

I don't understand the purpose of providing a Python implementation of the keyword module. If you look at the current implementation, I don't know that anything other than CPython can use it. The code uses Python/graminit.c to regenerate the module.

But I don't want to fight if you don't care of minor speedup, so I'm closing the issue.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19230>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:50:25 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 13:50:25 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386942625.19.0.897347991775.issue19973@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Only if we keep the C version around do we have to care about two versions. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 14:53:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 13:53:10 +0000
Subject: [issue19230] Reimplement the keyword module in C
In-Reply-To: <1381537991.31.0.762180400628.issue19230@psf.upfronthosting.co.za>
Message-ID: <1386942790.85.0.523793095993.issue19230@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You're right, the regeneration might be specific to CPython (although maybe it should work from Grammar/Grammar instead?), but that's just creating the Python file which we check into the stdlib, so any VM can use it, they just can't recreate it (which is fine since every other VM works from a CPython release).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19230>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:01:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 14:01:46 +0000
Subject: [issue19969] PyBytes_FromFormatV("%c") and PyString_FromFormatV("%c")
 don't check for character min/max value
In-Reply-To: <1386894588.54.0.168996140683.issue19969@psf.upfronthosting.co.za>
Message-ID: <1386943306.32.0.00296981541793.issue19969@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It was easy to fix the issue on Python 3.3 (there are already unit tests on PyBytes_FromFormatV).

I prefer to leave Python 2.7 with it's current behaviour because applications running on Python 2.7 may be old and might be rely on the integer overflow. PyString is the native "string" type, so it is usually used. Whereas in Python 3, bytes is not the native type. I chose to fix Python 3.3 because it's a recent release and I believe that applications are more recent and if they rely on the bug, they can more easily fixed.

(Ok, I bet that in practice, nobody cares of non-ASCII characters in PyBytes_FromFormatV() because PyBytes_FromFormatV() is probably not used in the wild.)

So let close this minor issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19969>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:02:27 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 13 Dec 2013 14:02:27 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1332948868.24.0.309034348776.issue14432@psf.upfronthosting.co.za>
Message-ID: <1386943347.15.0.0315719987057.issue14432@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> frameobject.h is not included in Python.h, so the
> classic #include "Python.h" doesn't give you access to PyFrameObject
> structure. You have to add a second #include "frameobject.h".

Ah, right. I keep misremembering that, because in order to do anything non-trivial with frames you'll eventually end up importing that header file, so it feels "almost public".

I think it's reasonable to expect low-level tools to adapt manually to this kind of changes (or at least recompile for a specific CPython version), and it's unlikely that there's much other code that would make use of this field specifically.

So, no objection to keeping the change in 3.4 as it is (and I see that you already documented it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:07:47 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 14:07:47 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386943667.31.0.379803583279.issue19973@psf.upfronthosting.co.za>


Larry Hastings added the comment:

We tried a pure python implementation of io once.  Didn't go so well.  :p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:09:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 14:09:13 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386943753.71.0.558388071732.issue19973@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> We tried a pure python implementation of io once.  Didn't go so well.  :p

It is _pyio.

Note: _pyio is not 100% *pure* Python, it relies on FileIO which is implemented in C. I always found this surprising. One day I will maybe rewrite it using os.read() and os.write() :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:11:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 14:11:23 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386943753.71.0.558388071732.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386943881.2319.3.camel@fsol>


Antoine Pitrou added the comment:

> Note: _pyio is not 100% *pure* Python, it relies on FileIO which is
> implemented in C. I always found this surprising. One day I will maybe
> rewrite it using os.read() and os.write() :-)

Then you need to rewrite os.read() and os.write() in pure Python!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:24:29 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 14:24:29 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386944669.18.0.979641034795.issue19973@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Key point is it didn't go so well **for us**; works fine for PyPy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:28:20 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Fri, 13 Dec 2013 14:28:20 +0000
Subject: [issue19975] Remove unused imports from webbrowser
Message-ID: <1386944900.75.0.705131055274.issue19975@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

The attached patch removes three unused imports in webbrowser module.

----------
components: Library (Lib)
files: webbrowser_unused_imports.patch
keywords: patch
messages: 206091
nosy: Claudiu.Popa, georg.brandl
priority: normal
severity: normal
status: open
title: Remove unused imports from webbrowser
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33121/webbrowser_unused_imports.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19975>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:32:40 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 13 Dec 2013 14:32:40 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386945160.33.0.778431596533.issue19973@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

PyPy also has a "C-translated" version of the io module.
It's a bit faster I think, but more importantly it has correct behavior with signals and other asynchronous errors.

_pyio.py can be stopped in the middle of any function, and is not completely signal-safe.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 15:43:06 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 14:43:06 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
Message-ID: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I was just reading the _pickle sources and it appears that AC does not
generate a second arg for METH_NOARGS functions:

#define _PICKLE_PICKLERMEMOPROXY_CLEAR_METHODDEF    \
    {"clear", (PyCFunction)_pickle_PicklerMemoProxy_clear, METH_NOARGS, _pickle_PicklerMemoProxy_clear__doc__},

static PyObject *
_pickle_PicklerMemoProxy_clear(PicklerMemoProxyObject *self)


While this is a common occurrence in the source tree, the consensus
in #15402 was that the unused second arg should be present, e.g.:

msg166250
msg166405

----------
components: Demos and Tools
messages: 206093
nosy: larry, skrah
priority: normal
severity: normal
status: open
title: Argument Clinic: generate second arg for METH_NOARGS
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:07:04 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 13 Dec 2013 15:07:04 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1386947224.23.0.934747244282.issue19385@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

IMHO it is a bug fix, not a new feature, and could be applied in 3.3 and 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:11:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 15:11:08 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>
Message-ID: <1386947468.02.0.921819092269.issue19976@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I prefer to omit the unused parameter, even if NULL *is* passed to the function.

If you prefer to add the unused parameter, what do you propose to avoid compiler warnings if unused parameters are checked?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:28:56 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 15:28:56 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>
Message-ID: <1386948536.02.0.0689280906715.issue19976@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Stefan is right.  I'll fix Clinic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:42:57 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 15:42:57 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386949377.72.0.825161820977.issue19973@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Then if Jython and IronPython are not using _pyio we can probably remove the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:46:40 2013
From: report at bugs.python.org (Sworddragon)
Date: Fri, 13 Dec 2013 15:46:40 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386949600.33.0.803701702767.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

By the way I have found a valid use case for LANG=C. udev and Upstart are not setting LANG which will result in the ascii encoding for invoked Python scripts. This could be a problem since these applications are commonly dealing with non-ascii filesystems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:47:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 15:47:39 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386949377.72.0.825161820977.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386949656.2319.5.camel@fsol>


Antoine Pitrou added the comment:

> Then if Jython and IronPython are not using _pyio we can probably remove the file.

_pyio can be useful for prototyping. Whether or not other
implementations use it is quite irrelevant IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:49:19 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 15:49:19 +0000
Subject: [issue19973] Deprecate pyio
In-Reply-To: <1386934884.58.0.337950563019.issue19973@psf.upfronthosting.co.za>
Message-ID: <1386949759.36.0.868430926958.issue19973@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yes, but it's a small utility.  If it costs nothing to maintain _pyio then okay.  But if we're spending measurable time on it but it's only a nice-to-have then we should drop it.

(Full disclosure: I have no idea how much work goes into maintaining _pyio.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19973>
_______________________________________

From report at bugs.python.org  Fri Dec 13 16:57:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 15:57:02 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386950222.98.0.826895030956.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

By the way, Java behaves as Python: with LANG=C, Java uses ASCII:

http://stackoverflow.com/questions/13415975/cant-read-utf-8-filenames-when-launched-as-an-upstart-service

> udev and Upstart are not setting LANG

So it's an issue in udev and Upstart. See for example:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1235483
https://bugs.launchpad.net/ubuntu-translations/+bug/1208272

I found examples using "LANG=$LANG ..." when running a command in Upstart for example. I found another example using:


    if [ -r /etc/default/locale ]; then
	. /etc/default/locale
	export LANG LANGUAGE
    elif [ -r /etc/environment ]; then
	. /etc/environment
	export LANG LANGUAGE
    fi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:00:24 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 16:00:24 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386947468.02.0.921819092269.issue19976@psf.upfronthosting.co.za>
Message-ID: <20131213160023.GA10512@sleipnir.bytereef.org>


Stefan Krah added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> If you prefer to add the unused parameter, what do you propose to avoid compiler warnings if unused parameters are checked?

This works quite portably in _decimal (I don't get warnings from gcc, icc,
suncc, Visual Studio, aCC, clang):

#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
  #define UNUSED __attribute__((unused))
#else
  #define UNUSED
#endif

static PyObject *
signaldict_copy(PyObject *self, PyObject *args UNUSED)
{
    return flags_as_dict(SdFlags(self));
}

We could call the macro PY_UNUSED or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:03:58 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 16:03:58 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>
Message-ID: <1386950638.21.0.0369483939137.issue19976@psf.upfronthosting.co.za>


Larry Hastings added the comment:

A quick google suggests:

http://sourcefrog.net/weblog/software/languages/C/unused.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:06:34 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 13 Dec 2013 16:06:34 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>
Message-ID: <1386950794.36.0.906956422522.issue19976@psf.upfronthosting.co.za>


Larry Hastings added the comment:

To do it properly with Clang requires a pragma:

http://stackoverflow.com/questions/3417837/what-is-the-best-way-to-supress-unused-variable-x-warning/18724213#18724213

What a mess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:11:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:11:42 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>
Message-ID: <1386951102.95.0.266878013424.issue19976@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> We could call the macro PY_UNUSED or something.

I would prefer Py_UNUSED name. This sounds like a nice addition to Include/pymacros.h.

In C++, you can omit the parameter name, so the macro should take the parameter name: Py_UNUSED(name). Example:

   int foo(int Py_UNUSED(bar)) { return 1 }

In Visual Studio, you can use:

#define Py_UNUSED(NAME) __pragma(warning(suppress:4100)) NAME

For Clang, you can try:

#define Py_UNUSED(NAME) _Pragma(diagnostic ignored "-Wunused") NAME

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:15:36 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 16:15:36 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386950794.36.0.906956422522.issue19976@psf.upfronthosting.co.za>
Message-ID: <20131213161535.GA10658@sleipnir.bytereef.org>


Stefan Krah added the comment:

Larry Hastings <report at bugs.python.org> wrote:
> To do it properly with Clang requires a pragma:

Hmm. I just tested and clang warns with -Wall -W, but does not warn if
__attribute__((unused)) is present.

The macro I posted really works on all obscure buildbot platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:17:08 2013
From: report at bugs.python.org (Sworddragon)
Date: Fri, 13 Dec 2013 16:17:08 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386951428.5.0.936726175309.issue19846@psf.upfronthosting.co.za>


Sworddragon added the comment:

> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1235483

After opening many hundred tickets I would say: With luck this ticket will get a response within the next year. But in the worst case it will be simply refused.


> I found examples using "LANG=$LANG

This Upstart script:

"exec echo LANG=$LANG > /tmp/test.txt"

Will result in the following:

root at ubuntu:~# start test
test stop/waiting
root at ubuntu:~# cat /tmp/test.txt
LANG=

At least in this example I'm getting on my system an empty LANG.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:17:20 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 16:17:20 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <20131213161535.GA10658@sleipnir.bytereef.org>
Message-ID: <20131213161719.GB10658@sleipnir.bytereef.org>


Stefan Krah added the comment:

Stefan Krah <report at bugs.python.org> wrote:
> The macro I posted really works on all obscure buildbot platforms.

N.B. clang also defines __GNUC__, as does the intel compiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:31:40 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Fri, 13 Dec 2013 16:31:40 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386952300.04.0.612063485821.issue19846@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

It's not a bug for upstart, systemd, sysvinit, cron, etc to use LANG=C.  The POSIX locale is the only locale guaranteed to exist on a system.  Therefore these low level services should be using LANG=C.  Embedded systems, thin clients, and other low memory or low disk devices may benefit from shipping without any locales.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:33:34 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 16:33:34 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386951102.95.0.266878013424.issue19976@psf.upfronthosting.co.za>
Message-ID: <20131213163333.GA10766@sleipnir.bytereef.org>


Stefan Krah added the comment:

STINNER Victor <report at bugs.python.org> wrote:
> I would prefer Py_UNUSED name. This sounds like a nice addition to Include/pymacros.h.

Yes, Py_UNUSED is nicer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:40:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:40:20 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdout on
 UNIX for the C locale
Message-ID: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When LANG=C is used to get the english language (which is a mistake, LC_CTYPE=C should be used instead) or when Python is started with an empty environment (no environment variable), Python gets the POSIX locale (aka "C locale") for the LC_CTYPE (encoding) locale.

Standard streams use the locale encoding, which is usually ASCII with POSIX locale on most platforms (except on AIX: ISO 8859-1). In this case, data read from the OS (environment variables, command line arguments, filenames, etc.) may contain surrogate characters because of the internal usage of the surrogateescape error handler (see the PEP 383 for the rationale).

The problem is that standard output uses the strict error handler, and so print() fails to display OS data like filenames.

Example, "ls" command in Python:
---
import os
for name in sorted(os.listdir()): print(name)
---

Try it with "LANG=C python ls.py" in a directory containing non-ASCII characters and you will get unicode errors.

Issues #19846 and #19847 are examples of this annoyance.

I propose to use also the surrogateescape error handler for sys.stdout if the POSIX locale is used for LC_CTYPE at startup. Attached patch implements this idea.

With the patch, "LANG=C python ls.py" almost works as filenames and stdout are byte streams, even if the Unicode type is used.

----------
components: Unicode
files: c_locale_surrogateescape.patch
keywords: patch
messages: 206111
nosy: Sworddragon, a.badger, ezio.melotti, haypo, loewis, ncoghlan
priority: normal
severity: normal
status: open
title: Use "surrogateescape" error handler for sys.stdout on UNIX for the C locale
versions: Python 3.4
Added file: http://bugs.python.org/file33122/c_locale_surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:40:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:40:59 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386952859.54.0.611069110609.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #19977 as a follow up of this one: "Use surrogateescape error handler for sys.stdout on UNIX for the C locale".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:41:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:41:09 +0000
Subject: [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1386952869.24.0.983850262819.issue19847@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #19977 as a follow up of this one: "Use surrogateescape error handler for sys.stdout on UNIX for the C locale".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19847>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:42:18 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:42:18 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386952938.94.0.937260640165.issue19977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, in fact, sys.stdin is also modified by the patch (as I expected).

----------
title: Use "surrogateescape" error handler for sys.stdout on UNIX for the C locale -> Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:43:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 16:43:19 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <3dgyP22D8Cz7Ljy@mail.python.org>


Roundup Robot added the comment:

New changeset cea42629ddf5 by Brett Cannon in branch 'default':
Issue #19946: Raise ImportError when the main module cannot be found
http://hg.python.org/cpython/rev/cea42629ddf5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:44:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 16:44:04 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1386953044.94.0.448787622448.issue19846@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I propose to modify the error handler, the encoding cannot be modified. See my following message explaining why it's not possible to change the encoding:
http://bugs.python.org/issue19846#msg205675

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:44:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 16:44:41 +0000
Subject: [issue19978] Update multiprocessing.spawn to use runpy.run_path
Message-ID: <1386953081.33.0.610270366508.issue19978@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Once the 'target' parameter for runpy.run_path lands then multiprocessing.spawn should be updated to use it.

----------
components: Library (Lib)
messages: 206117
nosy: brett.cannon, jnoller, ncoghlan, sbt
priority: normal
severity: normal
stage: test needed
status: open
title: Update multiprocessing.spawn to use runpy.run_path
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19978>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:45:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 16:45:49 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386953149.5.0.680898992262.issue19946@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Created http://bugs.python.org/issue19978 to track using runpy.run_path in 3.5.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:55:53 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 16:55:53 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386953753.48.0.823018115928.issue12837@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Two things. First, I'm sorry David but my mind is not working fully enough at the moment to see how msg_controllen is compared to cmsg_len_end without relying on external value coming in through the parameters of the function.

Second, I have re-uploaded my patch using pragmas to silence the comparison so it's easier to read.

----------
Added file: http://bugs.python.org/file33123/silence_compiler_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:56:12 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Fri, 13 Dec 2013 16:56:12 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386953772.28.0.546267557483.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

Why has this issue been closed? Won't the spawn and forkserver mode work in Python 3.4 for Python program started by a Python script (which is probably the majority of programs written in Python under unix)?

Is there any reason not to use the `imp.load_source` code I put in my patch as a temporary workaround if the cleaner runpy.run_path solution is too tricky to implement for the Python 3.4 release time frame?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:56:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 16:56:17 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386953777.55.0.313401155393.issue19977@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/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 17:58:57 2013
From: report at bugs.python.org (Sworddragon)
Date: Fri, 13 Dec 2013 16:58:57 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386953937.78.0.704135771724.issue19977@psf.upfronthosting.co.za>


Sworddragon added the comment:

What would happen if we call this example script with LANG=C on the patch?:

---
import os
for name in sorted(os.listdir('?')):
	print(name)
---

Would it throw an exception on os.listdir('?')?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:03:54 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 17:03:54 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386954234.16.0.482277344726.issue19977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_ls.py: test script producing invalid filenames and then trying to display them into stdout.

Output with UTF-8 locale, UTF-8 terminal and Python 3.3 (or unpatched 3.4, it's the same):

ascii.txt
<UnicodeError 'invalid_utf8:\udcff.txt'>
<UnicodeError 'latin1:\udce9.txt'>
utf8:??.txt

Output with C locale (ASCII), UTF-8 terminal and Python 3.3:

ascii.txt
<UnicodeError 'invalid_utf8:\udcff.txt'>
<UnicodeError 'latin1:\udce9.txt'>
<UnicodeError 'utf8:\udcc3\udca9\udce2\udc82\udcac.txt'>

Output with C locale (ASCII), UTF-8 terminal and patched Python 3.4:

ascii.txt
invalid_utf8:?.txt
latin1:?.txt
utf8:??.txt

You get no Unicode error with LANG=C, but you get mojibake instead.

----------
Added file: http://bugs.python.org/file33124/test_ls.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:08:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Dec 2013 17:08:27 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386954507.8.0.569298594543.issue19977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

os.fsencode(text) always fail if text cannot be encoded to sys.getfilesystemencoding(). surrogateescape doesn't help here.

Your example is "artificial", you should not get '?'. All OS data is decoded from the filesystem encoding using the surrogateescape error handler (except on Windows, where strict is used, but it's a different story, Python uses Unicode functions when available so don't worry). So all these data can always be encoded back to bytes using os.fsencode().

More generally, os.fsencode(os.fsdecode(read_data)) == read_data is always true on Unix, with any filesystem (locale) encoding.

You may get Unicode data from other sources like files or a GUI, but I don't see what can be done here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:13:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 17:13:47 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386954827.03.0.325562163003.issue19977@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:21:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 17:21:05 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386955265.64.0.177484811774.issue19977@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> When LANG=C is used to get the english language (which is a mistake,
> LC_CTYPE=C should be used instead)

I think you mean LC_MESSAGES=C here.
(but it's not only about the English language; it's also about other locale parameters such as number formatting)

I think we should start thinking about making utf-8 the default filesystem encoding in 3.5 (under Unix).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:22:48 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 13 Dec 2013 17:22:48 +0000
Subject: [issue19562] Added description for assert statement
In-Reply-To: <1384278059.69.0.538735147491.issue19562@psf.upfronthosting.co.za>
Message-ID: <1386955368.44.0.021077730642.issue19562@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I am going to reject this.  Assert failures should never be seen by users and for a developer "assert 1 <= month <= 12" is as clear as "month must be in 1..12."

----------
nosy: +belopolsky
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19562>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:29:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 17:29:41 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386955780.99.0.740545485048.issue19946@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Multiple questions from Oliver to answer.

> Why has this issue been closed?

Because the decided issue of this bug -- raising AttributeError over ImportError -- was fixed.

> Won't the spawn and forkserver mode work in Python 3.4 for Python program started by a Python script (which is probably the majority of programs written in Python under unix)?

The semantics are not going to change in python 3.4 and will just stay as they were in Python 3.3.

> Is there any reason not to use the `imp.load_source` code I put in my patch as a temporary workaround if the cleaner runpy.run_path solution is too tricky to implement for the Python 3.4 release time frame?

There are two reasons. One is that the imp module is deprecated in Python 3.4 (http://docs.python.org/3.4/library/imp.html#module-imp). Two is that temporarily inserting for a single release a solution that will simply be ripped out in the following release is just asking for trouble. Someone will use the temporary fix in some way in production code and then be shocked when the better solution doesn't work in exactly the same way. It's best to simply wait until 3.5 has the proper solution available.

I know it's frustrating to either name your scripts with a .py until Python 3.5 comes out or just wait until 3.5, but we can't risk a hacky solution for a single release as users will be living with the hack for several years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:30:26 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 13 Dec 2013 17:30:26 +0000
Subject: [issue19562] Added description for assert statement
In-Reply-To: <1384278059.69.0.538735147491.issue19562@psf.upfronthosting.co.za>
Message-ID: <1386955826.92.0.440476655931.issue19562@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

@terry - datetime.py was originally written as a prototype for the C code and many seemingly unpythonic constructs therein are motivated by the desire to ease the translation to C.

I would not mind simplifying _DI4Y calculation as you suggest, but please check how it is done in C.  I would like to keep the two implementation as similar as possible.

Please open a separate issue if you would like to have this done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19562>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:31:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 17:31:09 +0000
Subject: [issue18036] "How do I create a .pyc file?" FAQ entry is out of date
In-Reply-To: <1369244271.04.0.495588356743.issue18036@psf.upfronthosting.co.za>
Message-ID: <3dgzSD3H1Fz7LkT@mail.python.org>


Roundup Robot added the comment:

New changeset a14f830196ec by R David Murray in branch '3.3':
#18036: update .pyc FAQ entry in light of PEP 3147.
http://hg.python.org/cpython/rev/a14f830196ec

New changeset a757bdfce6b3 by R David Murray in branch 'default':
Merge: #18036: update .pyc FAQ entry in light of PEP 3147.
http://hg.python.org/cpython/rev/a757bdfce6b3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18036>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:40:31 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Fri, 13 Dec 2013 17:40:31 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386956431.37.0.157915392304.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

> The semantics are not going to change in python 3.4 and will just stay as they were in Python 3.3.

Well the semantics do change: in Python 3.3 the spawn and forkserver modes did not exist at all. The "spawn" mode existed but only implicitly and only under Windows.

So Python 3.4 is introducing a new feature for POSIX systems that will only work in the rare cases where the Python program is launched by a ".py" ending script.

Would running the `imp.load_source` trick only if `sys.platform != "win32"` be a viable way to preserve the semantics of Python 3.3 under the windows while not introducing a partially broken feature in Python 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:43:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 17:43:35 +0000
Subject: [issue18036] "How do I create a .pyc file?" FAQ entry is out of date
In-Reply-To: <1369244271.04.0.495588356743.issue18036@psf.upfronthosting.co.za>
Message-ID: <1386956615.3.0.701539720008.issue18036@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, A Kaptur and Phil.  I used Phil's patch, and added some additional tweaks and words.  (For example, I don't think PYTHONDONTWRITEBYTECODE existed when the FAQ entry was last updated).

I've chosen to maintain the existing flow, since it matches the title of the entry better.  It is quite possible, however, that the "question" is no longer in fact a FAQ, since most people probably don't ever look in the __pycache__ directory unless they are a distro maintainer.  It is possible what is really needed is a section of the docs that covers the actual implementation of PEP 3147 and all the associated issues surrounding .pyc files, but this updated version of the FAQ entry is at least an improvement on the status quo.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18036>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:53:16 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 13 Dec 2013 17:53:16 +0000
Subject: [issue19968] Using DESTDIR breaks sys.path
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386957196.54.0.472363478325.issue19968@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/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 18:59:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 17:59:51 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386957591.23.0.891391215365.issue19977@psf.upfronthosting.co.za>


R. David Murray added the comment:

Reintroducing moji-bake intentionally doesn't sound like a particularly good idea, wasn't that what python3 was supposed to help prevent?

It does seem like a utf-8 default is the Way of the Future.  Or even the present, most places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:03:23 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 18:03:23 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za>
Message-ID: <1386957803.73.0.0288362416325.issue12837@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Christian Heimes pointed out #ifdef __clang__ might be necessary to silence warnings on other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:05:11 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 18:05:11 +0000
Subject: [issue19298] Use __attribute__(cleanup ...) to detect refleaks
In-Reply-To: <1382193451.78.0.278113981899.issue19298@psf.upfronthosting.co.za>
Message-ID: <1386957911.1.0.813302820362.issue19298@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19298>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:05:24 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 18:05:24 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386957924.04.0.247383987189.issue19946@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm sorry, Oliver, you are simply going to have to wait for Python 3.5 at this point to get the new semantics you want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:09:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 18:09:20 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386957924.04.0.247383987189.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386958157.2319.6.camel@fsol>


Antoine Pitrou added the comment:

> I'm sorry, Oliver, you are simply going to have to wait for Python 3.5
> at this point to get the new semantics you want.

Side note: it's Olivier, not Oliver.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:30:16 2013
From: report at bugs.python.org (Quanah Gibson-Mount)
Date: Fri, 13 Dec 2013 18:30:16 +0000
Subject: [issue19968] Using DESTDIR breaks sys.path
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386959416.87.0.142042542431.issue19968@psf.upfronthosting.co.za>


Quanah Gibson-Mount added the comment:

Ok, so the general idea is to be able to install your software in a specific location and then symlink it back into another location (like /usr/local).  This allows quick and easy software version swapping.  I've used it to do things like test mariadb vs mysql, or various builds of openldap.  It works well with perl too.

The issue I'm hitting here with python is with site packages.  I wanted to be able to install the specific versions of various modules into their own location, and link then back via stow, but python can't find them since the site path is the literal location of the install instead of the symlink'd location.  I ended up just installing the modules into the default python location to get around it by now, but it means I can't trivially swap out different versions the python modules now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:58:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 18:58:56 +0000
Subject: [issue19963] Update docs for importlib.import_module()
In-Reply-To: <1386863488.66.0.95075387915.issue19963@psf.upfronthosting.co.za>
Message-ID: <3dh1PW2WyMzQJ3@mail.python.org>


Roundup Robot added the comment:

New changeset a44be62026fc by Brett Cannon in branch '3.3':
Issue #19963: Document that importlib.import_module() will import
http://hg.python.org/cpython/rev/a44be62026fc

New changeset 33938321d46f by Brett Cannon in branch 'default':
merge for issue #19963
http://hg.python.org/cpython/rev/33938321d46f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19963>
_______________________________________

From report at bugs.python.org  Fri Dec 13 19:59:16 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 18:59:16 +0000
Subject: [issue19963] Update docs for importlib.import_module()
In-Reply-To: <1386863488.66.0.95075387915.issue19963@psf.upfronthosting.co.za>
Message-ID: <1386961156.5.0.989808632672.issue19963@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19963>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:18:24 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Fri, 13 Dec 2013 19:18:24 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386962304.94.0.823687753775.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

I can wait (or monkey-patch the stuff I need as a temporary workaround in my code). My worry is that Python 3.4 will introduce a new feature that is very crash-prone.

Take this simple program that uses the newly introduced `get_context` function (the same problem happens with `set_start_method`):

filename: mytool
"""
#!/usr/bin/env python
from multiprocessing import freeze_support, get_context


def compute_stuff(i):
    # in real life you could use a lib that uses threads
    # like cuda and that would crash with the default 'fork'
    # mode under POSIX
    return i ** 2


if __name__ == "__main__":
     freeze_support()
     ctx = get_context('spawn')
     ctx.Pool(4).map(compute_stuff, range(8))

"""

If you chmod +x this file and run it with ./mytool, the user will get an infinitely running process that keeps displaying on stderr:

"""
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 96, in spawn_main
    exitcode = _main(fd)
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 105, in _main
    prepare(preparation_data)
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 210, in prepare
    import_main_path(data['main_path'])
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 256, in import_main_path
    raise ImportError(name=main_name)
ImportError
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 96, in spawn_main
    exitcode = _main(fd)
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 105, in _main
    prepare(preparation_data)
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 210, in prepare
    import_main_path(data['main_path'])
  File "/opt/Python-HEAD/lib/python3.4/multiprocessing/spawn.py", line 256, in import_main_path
    raise ImportError(name=main_name)
ImportError
...
"""

until the user kills the process. Is there really nothing we can do to avoid releasing Python 3.4 with this bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:26:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 13 Dec 2013 19:26:27 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386962787.33.0.718332639183.issue19946@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Let's reopen, shall we? If not for 3.4, at least for 3.5.

It's likely that multiprocessing needs a __main__ simply because it needs a way to replicate the parent process' state in the child (for example, the set of imported modules, the logging configuration, etc.). Perhaps Richard can elaborate.

But, AFAIU, the __main__ could be imported as a script rather than a "proper" module from sys.path.

----------
assignee: brett.cannon -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:26:58 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 19:26:58 +0000
Subject: [issue19968] Python does not play well with 'stow'.
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386962818.77.0.120918695898.issue19968@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since it appears to be a perl based, it is not too surprising it works well with perl :)

A little googling turns up someone suggesting that the logic for finding things be changed slightly, such that if the binary is itself a symbolic link, it will look in the home dir of the symbolic link to see if it looks like a "python installation" where it can find things.  This *might* be a reasonable idea, but I'd prefer if the people who have worked this stuff out in the context of virtual environments were to consider this use case and make suggestions, so I've added Vinay to nosy.

It isn't a build or even an install issue, though, it's a runtime issue.  I've changed the title to reflect the real issue: python not playing well with stow's symlink setup.

I've marked this as an enhancement for 3.5, since it seems to me like a significant change in behavior, but it could be that an argument could be made that this is actually a bug, given that it seems like most unix programs work fine under such a symlink setup.

You can work around it by using a .pth file to add the site-packages dir you want onto the path, by the way, though you'd have to add that to each install by yourself.

----------
components: +Interpreter Core -Build
nosy: +vinay.sajip
title: Using DESTDIR breaks sys.path -> Python does not play well with 'stow'.
type:  -> enhancement
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:40:13 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Fri, 13 Dec 2013 19:40:13 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1386963613.66.0.3358346399.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

For Python 3.4:

Maybe rather than raising ImportError, we could issue warning to notify the users that names from the __main__ namespace could not be loaded and make the init_module_attrs return early.

This way a multiprocessing program that only calls functions defined in non-main namespaces could still use the new "start method" feature introduced in Python 3.4 while not changing the Python 3.3 semantics for windows programs and not relying on any deprecated hack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:44:36 2013
From: report at bugs.python.org (Toshio Kuratomi)
Date: Fri, 13 Dec 2013 19:44:36 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386963876.92.0.848546049254.issue19977@psf.upfronthosting.co.za>


Toshio Kuratomi added the comment:

My impression was that python3 was supposed to help get rid of UnicodeError tracebacks, not mojibake.  If mojibake was the problem then we should never have gone down the surrogateescape path for input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:52:36 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 19:52:36 +0000
Subject: [issue19701] Update multiprocessing for PEP 451
In-Reply-To: <1385138043.59.0.905087765846.issue19701@psf.upfronthosting.co.za>
Message-ID: <1386964356.36.0.556566012181.issue19701@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think this is as fixed as it's going to be until Python 3.5 and the code is updated to use runpy (see http://bugs.python.org/issue19978).

----------
dependencies:  -refactor pythonrun.c to make use of specs (__main__.__spec__)
resolution:  -> fixed
status: open -> closed
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19701>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:52:54 2013
From: report at bugs.python.org (Quanah Gibson-Mount)
Date: Fri, 13 Dec 2013 19:52:54 +0000
Subject: [issue19968] Python does not play well with 'stow'.
In-Reply-To: <1386893744.29.0.246592837254.issue19968@psf.upfronthosting.co.za>
Message-ID: <1386964374.63.0.438254197365.issue19968@psf.upfronthosting.co.za>


Quanah Gibson-Mount added the comment:

Thank you very much for looking at it. :)  Since I can work around it easily enough, I'm set for now, but it would be great to see Python play nicely with stow in a future release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19968>
_______________________________________

From report at bugs.python.org  Fri Dec 13 20:53:20 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 19:53:20 +0000
Subject: [issue19978] Update multiprocessing.spawn to use runpy.run_path
In-Reply-To: <1386953081.33.0.610270366508.issue19978@psf.upfronthosting.co.za>
Message-ID: <1386964400.33.0.184823422009.issue19978@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +refactor pythonrun.c to make use of specs (__main__.__spec__)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19978>
_______________________________________

From report at bugs.python.org  Fri Dec 13 21:03:36 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 20:03:36 +0000
Subject: [issue19705] Update test.test_namespace_pkgs to PEP 451
Message-ID: <1386965016.17.0.357169698106.issue19705@psf.upfronthosting.co.za>


New submission from Brett Cannon:

There is nothing to update; the tests work through the import statement directly.

----------
dependencies:  -Merge all (non-syntactic) import-related tests into test_importlib
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19705>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:01:49 2013
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Fri, 13 Dec 2013 21:01:49 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386968509.95.0.613344397438.issue19972@psf.upfronthosting.co.za>


Alexandre Vassalotti added the comment:

The patch is good. I am not sure if you need the freefunc cast though.

The example in the PEP 3121 should updated if freefunc is actually required. I didn't define freefunc because of this example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:25:03 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Dec 2013 21:25:03 +0000
Subject: [issue19562] Added description for assert statement
In-Reply-To: <1384278059.69.0.538735147491.issue19562@psf.upfronthosting.co.za>
Message-ID: <1386969903.09.0.880050374883.issue19562@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thank you for the explanation. If the style comment is not in the file already, you might add it whenever you next edit the file for substantive purposes (a real bug or feature change). Ditto for _DI4Y.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19562>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:27:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 21:27:00 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1386970020.78.0.665773916236.issue19977@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Mojibake in input can cause decoding error in other application which consumes output of Python script. In some cases this can be even worse thin UnicodeError in producer.

But for C locale this makes sense. I think we should try this experiment in 3.5. There will be much time for testing before 3.5 beta 1.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:31:17 2013
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 13 Dec 2013 21:31:17 +0000
Subject: [issue19979] Missing nested scope vars in class scope (bis)
Message-ID: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za>


New submission from Armin Rigo:

This is a repeat of the old issue 532860: "NameError assigning to class in a func".  It is about class statements' variable lookups, which has different behavior at module level or in a nested scope:

def f(n):
    class A:
        n = n     # doesn't work, tries to look up 'n' as a global

The point of repeating this very old issue is the much more recent issue 17853: "Conflict between lexical scoping and name injection in __prepare__".  This was a slightly different problem, but resolved by adding the exact opcode that would be needed to fix the old issue too: LOAD_CLASSDEREF.  It's an opcode which looks in the locals dict for a name, and if not found, falls back to freevars instead of to globals.

The present bug report is here to argue that this new opcode should be used a bit more systematically by the compiler.  Contrary to the conclusions reached in the very old bug report, I argue that nowadays it would seem reasonable to expect that the previous example should work.  By no means is it an essential issue in my opinion, but this would probably be a slight simplification and prevent corner-case surprizes.  Moreover it probably leads to a simplification in the compiler: no need to track which variables are local or not in class bodies --- instead just compile the loading of 'n' above as a LOAD_CLASSDEREF without worrying about the fact that the same 'n' is also assigned to in the same scope.

----------
components: Interpreter Core
messages: 206149
nosy: arigo
priority: normal
severity: normal
status: open
title: Missing nested scope vars in class scope (bis)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19979>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:33:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 21:33:07 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1386970387.81.0.8626883599.issue19974@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/issue19974>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:47:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 21:47:27 +0000
Subject: [issue19704] Update test.test_threaded_import to PEP 451
Message-ID: <3dh57y5LKXz7LjZ@mail.python.org>


New submission from Roundup Robot:

New changeset dbb9c23e1887 by Brett Cannon in branch 'default':
Issue #19704: Port test.test_threaded_import to PEP 451
http://hg.python.org/cpython/rev/dbb9c23e1887

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19704>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:47:47 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Dec 2013 21:47:47 +0000
Subject: [issue19704] Update test.test_threaded_import to PEP 451
In-Reply-To: <3dh57y5LKXz7LjZ@mail.python.org>
Message-ID: <1386971267.63.0.776165841037.issue19704@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies:  -Merge all (non-syntactic) import-related tests into test_importlib
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19704>
_______________________________________

From report at bugs.python.org  Fri Dec 13 22:53:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Dec 2013 21:53:26 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1386971606.08.0.452383393754.issue19385@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Now this seems odd, maybe catching + reraising an exception has a greater overhead than a func call and checking if an attribute is None.

Yes, of course, catching + reraising an exception is costly. But when an exception is not raised, this is cheap. Usually len() is called for open database.

> IMHO it is a bug fix, not a new feature, and could be applied in 3.3 and 3.4.

Hmm. If consider dbm.dumb as separated module, this is perhaps a new feature. But if consider it as an implementation of the dbm protocol, it should conform to other dbm modules, and this is a bugfix. What would you say Nick?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:06:05 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 22:06:05 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1386972365.55.0.928621229375.issue4130@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Our included libffi is:

2013-03-17  Anthony Green  <green at moxielogic.com>

        * README: Update for 3.0.13.
        * configure.ac: Ditto.
        * configure: Rebuilt.
        * doc/*: Update version.


According to https://sourceware.org/libffi/ that is the latest
released version. Did I miss something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:21:49 2013
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 Dec 2013 22:21:49 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1386973309.33.0.570109781225.issue19972@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I just see that it should be:

static void
pickle_free(PyObject *m)
...


Even then, the cast is necessary, otherwise you get this warning:

/home/stefan/hg/cpython/Modules/_pickle.c:7450:1: warning: initialization from incompatible pointer type [enabled by default]
/home/stefan/hg/cpython/Modules/_pickle.c:7450:1: warning: (near initialization for '_picklemodule.m_free') [enabled by default]


I agree that it would be nice to update the PEP, but I guess that
would be Martin's call.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:22:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Dec 2013 22:22:07 +0000
Subject: [issue19975] Remove unused imports from webbrowser
In-Reply-To: <1386944900.75.0.705131055274.issue19975@psf.upfronthosting.co.za>
Message-ID: <3dh5vz00kxz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset f2c6b0485ce6 by R David Murray in branch 'default':
#19975: remove unused imports from webbrowser module.
http://hg.python.org/cpython/rev/f2c6b0485ce6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19975>
_______________________________________

From report at bugs.python.org  Fri Dec 13 23:23:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Dec 2013 22:23:51 +0000
Subject: [issue19975] Remove unused imports from webbrowser
In-Reply-To: <1386944900.75.0.705131055274.issue19975@psf.upfronthosting.co.za>
Message-ID: <1386973431.17.0.670624468201.issue19975@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Claudiu.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19975>
_______________________________________

From report at bugs.python.org  Sat Dec 14 00:14:49 2013
From: report at bugs.python.org (Wim)
Date: Fri, 13 Dec 2013 23:14:49 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1386976489.87.0.550600361552.issue17088@psf.upfronthosting.co.za>


Wim added the comment:

Here's an improved patch (and improved testcase).

It's a little more intrusive than the last patch because when a default namespace is being used, two distinct qname caches must be made.

----------
Added file: http://bugs.python.org/file33125/bug17088_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17088>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:34:52 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 01:34:52 +0000
Subject: [issue19980] Improve help('non-topic') response
Message-ID: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

>>> help(1)
# help on int
>>> help(b'a')
# help on bytes
>>> help('a')
no Python documentation found for 'a'

The reason for this unhelpful response is that strings are treated differently from all other non-class objects. (msg205861 thought this a bug.) The strings value is matched against strings that would be recognized at the help> prompt given after help().

>>> help('topics')
# list of TOPICS
>>> help('LISTS')
# information about mutable sequences

Suggestion: add something more about what to do. Example enhanced response:

No Python documentation found for 'a'. Try help('help') for information on recognized strings or help(str) for help on the str class.

I believe this could be backported since help() is intented for interactive use only.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 206157
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve help('non-topic') response
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:35:29 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 01:35:29 +0000
Subject: [issue18918] help('FILES') finds no documentation
In-Reply-To: <1378269620.52.0.763555902483.issue18918@psf.upfronthosting.co.za>
Message-ID: <1386984929.16.0.111004584731.issue18918@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/issue18918>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:37:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 01:37:46 +0000
Subject: [issue19914] help([object]) returns "Not enough memory." on standard
 Python types, object and object functions
In-Reply-To: <1386372447.57.0.257737240226.issue19914@psf.upfronthosting.co.za>
Message-ID: <1386985066.3.0.421436996929.issue19914@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

cp65001 fails in many ways quite independent of Python.
Idle:
>>> "??????*"
'??????*'
Pasting the same string into Command Prompt (Win 7, USA, updated):
C:\Users\Terry>echo "??????*"
"??????*"

C:\Users\Terry>chcp 65001
Active code page: 65001

C:\Users\Terry>echo "*"
The system cannot write to the specified device.
---

help('xyz') treats string instances specially. Try 'topics' or 'LISTS'.
I opened #19980 for improving the 'not found' message.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19914>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:47:06 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 14 Dec 2013 01:47:06 +0000
Subject: [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1386985626.39.0.399504790951.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

IMHO this must be changed.

>>> help('')
# nothing!!!
>>> help('a')
Help on module a:

...

I happened to have a module called a.py in the default directory.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:54:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 01:54:16 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <3dhBck1nG7z7LkT@mail.python.org>


Roundup Robot added the comment:

New changeset 8e18a3b54bbe by R David Murray in branch '3.3':
#19970: Fix some comment typos.
http://hg.python.org/cpython/rev/8e18a3b54bbe

New changeset 358a35471f9f by R David Murray in branch 'default':
Merge: #19970: Fix some comment typos.
http://hg.python.org/cpython/rev/358a35471f9f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Sat Dec 14 02:59:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 01:59:01 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1386986341.12.0.244919792549.issue19970@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Vajrasky.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Sat Dec 14 03:18:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 02:18:07 +0000
Subject: [issue19933] Round default argument for "ndigits"
In-Reply-To: <1386563060.5.0.176884779469.issue19933@psf.upfronthosting.co.za>
Message-ID: <1386987487.54.0.8494253872.issue19933@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The docstring is better than the current doc as it says that the default precision is 0, without calling that the default for ndigits.

''' round(number[, ndigits]) -> number
    
    Round a number to a given precision in decimal digits (default 0 digits).
    This returns an int when called with one argument, otherwise the
    same type as the number. ndigits may be negative.'''

---
Sidenote: To write round in Python, one could easily write

_sentinel = object
def round(number, ndigits=_sentinel):
  if ndigits is _sentinel: ...

which makes ndigits positional-or-keyword, and almost optional-with-no-default, as _sentinel is close enough to being a default that cannot be passed in. This is a standard idiom. One who was really picky about having no default could use
  def round(number, *args, **kwds): ...
and look for len(args) == 1 xor kwds.keys() == {'ndigits'}.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19933>
_______________________________________

From report at bugs.python.org  Sat Dec 14 03:55:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 02:55:31 +0000
Subject: [issue19953] __iadd__() doc not strictly correct
In-Reply-To: <1386792788.94.0.272007303341.issue19953@psf.upfronthosting.co.za>
Message-ID: <1386989731.39.0.597709518015.issue19953@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The current doc is correct. Unlike the old incorrect version of the operator doc (#7259), it does not say that the call is all of the execution. The suggested replacement "x = x.__iadd__(y) is called" is not correct as statements are not called.

The said, it seems that some people miss the fact that augmented assignment always does an assignment. So, considering that the first sentence of the paragraph, "These methods are called to implement the augmented arithmetic assignments (+=, -=, *=, /=, //=, %=, **=, <<=, >>=, &=, ^=, |=)." already talks about calling, I thing

"For instance, to execute the statement x += y, where x is an instance of a class that has an __iadd__() method, x.__iadd__(y) is called. If x is an instance of a class that does not define a __iadd__() method, x.__add__(y) and y.__radd__(x) are considered, as with the evaluation of x + y."

might be replaced by

"For instance, if x is an instance of a class with an __iadd__() method, x += y is equivalent to x = x.__iadd__(y) . Otherwise, x.__add__(y) and y.__radd__(x) are considered, as with the evaluation of x + y."

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19953>
_______________________________________

From report at bugs.python.org  Sat Dec 14 03:59:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 02:59:08 +0000
Subject: [issue19954] test_tk floating point exception on my gentoo box with
 tk 8.6.1
In-Reply-To: <1386797179.8.0.0943570301002.issue19954@psf.upfronthosting.co.za>
Message-ID: <1386989948.52.0.048472739986.issue19954@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: test_tk floating point exception on my gentoo box running tk 8.6.1 -> test_tk floating point exception on my gentoo box with tk 8.6.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19954>
_______________________________________

From report at bugs.python.org  Sat Dec 14 04:24:19 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sat, 14 Dec 2013 03:24:19 +0000
Subject: [issue19936] Executable permissions of Python source files
In-Reply-To: <1386588201.39.0.841678145847.issue19936@psf.upfronthosting.co.za>
Message-ID: <1386991459.35.0.520062014095.issue19936@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/issue19936>
_______________________________________

From report at bugs.python.org  Sat Dec 14 04:59:09 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 03:59:09 +0000
Subject: [issue19956] inspect.getsource(obj.foo) fails when foo is an injected
 method constructed from another method
In-Reply-To: <1386804440.21.0.0153040236788.issue19956@psf.upfronthosting.co.za>
Message-ID: <1386993549.31.0.459859206348.issue19956@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do not think you have exactly identified a bug, certainly not one we would fix in an existing release. The behavior in more of an unintended consequence of separate decisions resulting from an unanticipated usage. I am not sure what, if anything, should be done. Changing the exception message could still be done in 3.4, but not making getsource recursive for bound methods.

----------
nosy: +terry.reedy
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.5 -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/issue19956>
_______________________________________

From report at bugs.python.org  Sat Dec 14 04:59:57 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Dec 2013 03:59:57 +0000
Subject: [issue19962] Create a 'python.bat' script to invoke interpreter from
 source root
In-Reply-To: <1386862429.77.0.358851450829.issue19962@psf.upfronthosting.co.za>
Message-ID: <1386993597.62.0.648760197759.issue19962@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/issue19962>
_______________________________________

From report at bugs.python.org  Sat Dec 14 05:13:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 04:13:50 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <1386994430.22.0.113816783649.issue19099@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, I think the error message can be improved because in Python 2.7 we differentiate very clearly the string from the unicode.

>>> import struct
>>> struct.Struct(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not int

But you can give unicode, right?

>>> struct.Struct(u'b')
<Struct object at 0x1f484b8>

This is consistent with other example:

>>> " cutecat ".strip(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: strip arg must be None, str or unicode

What do you say, Serhiy?

Here is the patch.

----------
Added file: http://bugs.python.org/file33126/fix_error_message_struct_Struct.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Sat Dec 14 06:17:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 05:17:33 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1386998253.97.0.251311997048.issue19970@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

R. David Murray, there is a reason I create separate patches for 3.3 and 3.4. You couldn't just merge them. Python 3.4 has additional file with typo, which is immediatly in Doc/library/asyncio-protocol.rst. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Sat Dec 14 06:56:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 05:56:54 +0000
Subject: [issue14432] Bug in generator if the generator in created in a
 temporary C thread
In-Reply-To: <1386943347.15.0.0315719987057.issue14432@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eTtp04DL9Ng4bNMuyRM8n_y3kAShBeGK4h3Do_sGoDaw@mail.gmail.com>


Nick Coghlan added the comment:

Ah, I always forget that frameobject.h isn't included from python.h
because none of the names have underscore prefixes. In that case,
together with the new note in the porting section, I agree this is
fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14432>
_______________________________________

From report at bugs.python.org  Sat Dec 14 07:07:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 06:07:30 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1387001250.32.0.415904219983.issue19977@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Getting rid of mojibake was the goal, surrogateescape was about dealing with cases where the "avoid mojibake" checks were spuriously breaking round-tripping between OS APIs due to other configuration errors (with LANG=C being set, or LANG not being set at all being the main problem). Other "high mojibake risk" power tools (like changing the encoding of an already open stream) are likely to return in the future, since there *are* cases where they're the right answer (e.g. you can't right an iconv equivalent in Python 3 at the moment, we need issue 15216 implemented before that will be possible).

+1 for this solution - see issue 19846 for the long discussion which got us to this point (there are a few unrelated tangents, a couple of them my fault, but this is definitely an improvement over the status quo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Sat Dec 14 07:10:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 06:10:02 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1387001402.44.0.450467299929.issue19846@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks Victor - I now agree that trying to guess another encoding is a bad idea, and that enabling surrogateescape for the standard streams under the C locale is a better way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec 14 07:55:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 06:55:45 +0000
Subject: [issue16355] inspect.getcomments() does not work in the interactive
 shell
In-Reply-To: <1351511930.82.0.59071323276.issue16355@psf.upfronthosting.co.za>
Message-ID: <1387004145.36.0.963732616879.issue16355@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

So, I just found out that imp has been deprecated. Here is the patch that uses importlib.machinery instead of imp.load_source.

----------
Added file: http://bugs.python.org/file33127/issue16355_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16355>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:39:27 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Dec 2013 08:39:27 +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: <1387010367.96.0.595652784133.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> From what I read in the thread it seems to be more like a bug rather than
> something to just be documented, right?

No, both round and formatting are working as expected: it's just a bit unfortunate that they use different rounding modes in 2.x.  It's not something that it would make sense to change in 2.7 at this stage---any such change would likely break a lot of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:42:34 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Dec 2013 08:42:34 +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: <1387010554.1.0.0434731375302.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

And the Python 2 behaviour has been essentially unchanged for a long time:

Python 2.4.6 (#1, Nov  7 2013, 16:01:20) 
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "%.f %.f" % (0.5, 1.5)
'0 2'
>>> round(0.5), round(1.5)
(1.0, 2.0)

(Though that first call just shows the result of whatever the OS C libraries decide to do, but historically that seems to be more likely to be round-half-to-even than anything else.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17259>
_______________________________________

From report at bugs.python.org  Sat Dec 14 09:58:32 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 08:58:32 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1387011512.33.0.243914197232.issue19974@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary path. It works and tested on Linux. I'll check the behaviour on Windows later.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33128/fix_tarfile_overwrites_symlink.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19974>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:19:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 09:19:52 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1387012792.98.0.200597116913.issue19974@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33128/fix_tarfile_overwrites_symlink.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19974>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:20:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 09:20:02 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1387012802.36.0.0790697423211.issue19974@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33129/fix_tarfile_overwrites_symlink.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19974>
_______________________________________

From report at bugs.python.org  Sat Dec 14 10:47:14 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 14 Dec 2013 09:47:14 +0000
Subject: [issue19981] Typo in mailbox documentation
Message-ID: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

In the last example, there is a misspelled imported module.

----------
assignee: docs at python
components: Documentation
files: mailbox_typo.patch
keywords: patch
messages: 206174
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Typo in mailbox documentation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33130/mailbox_typo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19981>
_______________________________________

From report at bugs.python.org  Sat Dec 14 11:43:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 10:43:35 +0000
Subject: [issue19981] Typo in mailbox documentation
In-Reply-To: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>
Message-ID: <3dhQMV6pWyz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 31fd129960d5 by Ezio Melotti in branch '2.7':
#19981: fix typo in email.mailbox docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/31fd129960d5

New changeset 364ca376956f by Ezio Melotti in branch '3.3':
#19981: fix typo in email.mailbox docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/364ca376956f

New changeset 0d8fe7d688a9 by Ezio Melotti in branch 'default':
#19981: merge with 3.3.
http://hg.python.org/cpython/rev/0d8fe7d688a9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19981>
_______________________________________

From report at bugs.python.org  Sat Dec 14 11:44:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Dec 2013 10:44:12 +0000
Subject: [issue19981] Typo in mailbox documentation
In-Reply-To: <1387014434.61.0.267929363323.issue19981@psf.upfronthosting.co.za>
Message-ID: <1387017852.06.0.956239219143.issue19981@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
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19981>
_______________________________________

From report at bugs.python.org  Sat Dec 14 12:35:52 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 Dec 2013 11:35:52 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1387020952.63.0.0725806037812.issue11798@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This seems to break BaseTestSuite.countTestCases when invoked after the TestSuite has been run:
  ...
  File "Lib/unittest/suite.py", line 42, in countTestCases
    cases += test.countTestCases()
AttributeError: 'NoneType' object has no attribute 'countTestCases'

Attached patch attempts to fix it.

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file33131/countTestCases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Dec 14 12:49:29 2013
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Sat, 14 Dec 2013 11:49:29 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1387021769.53.0.809539526847.issue19100@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

sys.displayhook doesn't fail, because it uses the backslashreplace error handler, and for sys.displayhook that's OK, because it's only used for screen output and there some output is better than no output. However print and pprint.pprint might be used for output that is consumed by other programs (via pipes etc.) and IMHO in this case "Errors should never pass silently."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Sat Dec 14 13:43:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 12:43:59 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <3dhT2R2Bn7z7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 8a78988fdb04 by Stefan Krah in branch 'default':
Issue #19972: Add rarely used freefunc.  This fixes a leak if sys.exit()
http://hg.python.org/cpython/rev/8a78988fdb04

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:17:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:17:37 +0000
Subject: [issue19946] Have multiprocessing raise ImportError when spawning a
 process that can't find the "main" module
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387027057.66.0.640665170986.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Long term fix: runpy.run_path and runpy.run_module need to accept a "target" parameter, multiprocessing needs to use the appropriate one based on whether or not __main__.__spec__ is None.

Short term (3.4) fix: we can expose a private API in runpy akin to the _run_module_as_main that we use to implement the -m switch that will do the right thing for multiprocessing.

----------
dependencies: +Update runpy for PEP 451

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:18:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:18:29 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387027109.58.0.546987978302.issue19946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Have multiprocessing raise ImportError when spawning a process that can't find the "main" module -> Handle a non-importable __main__ in multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:18:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:18:47 +0000
Subject: [issue19978] Update multiprocessing.spawn to use runpy.run_path
In-Reply-To: <1386953081.33.0.610270366508.issue19978@psf.upfronthosting.co.za>
Message-ID: <1387027127.74.0.322134357938.issue19978@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
dependencies: +Handle a non-importable __main__ in multiprocessing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19978>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:22:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:22:03 +0000
Subject: [issue19982] Add a "target" parameter to runpy.run_path and
 runpy.run_module
Message-ID: <1387027323.14.0.795736210788.issue19982@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

One idea from PEP 451 was to add a "target" parameter to runpy.run_path and runpy.run_module to allow them to support execution in an existing module namespace (like __main__).

This missed the feature freeze deadline for 3.4, but can be added in 3.5.

----------
messages: 206181
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a "target" parameter to runpy.run_path and runpy.run_module
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19982>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:22:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:22:13 +0000
Subject: [issue19982] Add a "target" parameter to runpy.run_path and
 runpy.run_module
In-Reply-To: <1387027323.14.0.795736210788.issue19982@psf.upfronthosting.co.za>
Message-ID: <1387027333.16.0.963580059465.issue19982@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
dependencies: +Update runpy for PEP 451

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19982>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:22:30 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:22:30 +0000
Subject: [issue19978] Update multiprocessing.spawn to use runpy.run_path
In-Reply-To: <1386953081.33.0.610270366508.issue19978@psf.upfronthosting.co.za>
Message-ID: <1387027350.9.0.133757111748.issue19978@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
dependencies: +Add a "target" parameter to runpy.run_path and runpy.run_module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19978>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:26:21 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 14 Dec 2013 13:26:21 +0000
Subject: [issue19972] Leak in pickle (?)
In-Reply-To: <1386929674.63.0.934928142629.issue19972@psf.upfronthosting.co.za>
Message-ID: <1387027581.62.0.889339839369.issue19972@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Should be fixed. Thanks for the comments everyone.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19972>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:28:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:28:35 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1387027715.73.0.842871144479.issue19385@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think it's definitely still OK to fix this in 3.4, but I think it's borderline enough to avoid including in the last ever 3.3 release. Changing exception types always introduces a little backwards compatibility risk, so it's something I lean towards only doing in new feature releases, even in cases like this where the old exception was clearly not the best choice.

----------
versions: +Python 3.4 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:35:26 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 14 Dec 2013 13:35:26 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1387028126.15.0.770357656231.issue19385@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> in the last ever 3.3 release.

msg204533 suggests that there will be >=2 bug fix releases in 3.3 branch (3.3.4 soon and 3.3.5 around release of 3.4.0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Sat Dec 14 14:51:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 13:51:36 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1387028126.15.0.770357656231.issue19385@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d78C1_pZiqgtQUgf+eYxmhPf3iCMuMQoDaSiPnFEpwQg@mail.gmail.com>


Nick Coghlan added the comment:

That's slightly more acceptable, but it's still hard to make the case
that changing exception types is a reasonable thing to do in a
maintenance release (it's only the specific nature of the error that
makes me consider it reasonable even in a feature release).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Sat Dec 14 15:51:37 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 14 Dec 2013 14:51:37 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1387032697.45.0.247740295533.issue17088@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17088>
_______________________________________

From report at bugs.python.org  Sat Dec 14 16:06:23 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 14 Dec 2013 15:06:23 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1387033583.95.0.0335830781448.issue17088@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Note that the option is called "default_namespace", not "default_namespace_prefix". Could you try passing the namespace URI instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17088>
_______________________________________

From report at bugs.python.org  Sat Dec 14 16:08:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Dec 2013 15:08:45 +0000
Subject: [issue19167] sqlite3 cursor.description varies across Linux (3.3.1), 
 Win32 (3.3.2), when selecting from a view.
In-Reply-To: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>
Message-ID: <1387033725.16.0.364091951603.issue19167@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

This is a bug from Sqlite. Sqlite 3.7 is afflicted. Solution: upgrade to sqlite 3.8.

http://sqlite.1065341.n5.nabble.com/sqlite3-column-name-contains-quotes-for-views-td65226.html
http://www.sqlite.org/src/info/5526e0aa3c

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19167>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:21:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:21:56 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1387038116.85.0.262356652536.issue19970@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, well, it would be good to note that in the issue comments, then :).

The commit workflow is that a patch gets applied to a branch, then merged forward.  So I would need to apply the additional changes by hand to 3.4, unless you provide a 3.4 diff that is a diff between the *merged* 3.3 changeset and the updated 3.4 changes.  

Either way, let the committer know in the comments.  (I'll fix this momentarily.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:23:13 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:23:13 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <1387038193.19.0.863660410598.issue19970@psf.upfronthosting.co.za>


R. David Murray added the comment:

s/need/prefer/, unless the differences between the two patchsets are large, in which case I'd probably do a null merge followed by a separate 3.4 commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:26:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 16:26:22 +0000
Subject: [issue19970] Typo of `immediatly` and `agin` words
In-Reply-To: <1386926926.59.0.938462755988.issue19970@psf.upfronthosting.co.za>
Message-ID: <3dhYz20D8Bz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 561822250761 by R David Murray in branch 'default':
#19970: fix additional typo in 3.4 asyncio docs.
http://hg.python.org/cpython/rev/561822250761

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19970>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:38:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 16:38:27 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387039107.58.0.332690692228.issue17919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The message should be "C unsigned short".

Thanks.

> The unit tests don't check that USHRT_MAX value is accepted.

And shouldn't. Not all values make sense. Meaning of USHRT_MAX is platform depended.

> With  poll_events_mask_overflow.patch, the following hack can maybe be removed?

No. Otherwise the result can be negative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:50:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:50:47 +0000
Subject: [issue19167] sqlite3 cursor.description varies across Linux (3.3.1), 
 Win32 (3.3.2), when selecting from a view.
In-Reply-To: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>
Message-ID: <1387039847.47.0.903436170448.issue19167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the conformation, Vajrasky.  It is apparently not hard to upgrade the sqlite3 that python uses even on Windows, so I'm going to close this issue.  (We're currently up to sqlite3 3.8.1 on 3.4).

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19167>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:51:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:51:23 +0000
Subject: [issue19167] sqlite3 cursor.description varies across Linux (3.3.1), 
 Win32 (3.3.2), when selecting from a view.
In-Reply-To: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>
Message-ID: <1387039883.17.0.603993670716.issue19167@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg206192

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19167>
_______________________________________

From report at bugs.python.org  Sat Dec 14 17:51:37 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Dec 2013 16:51:37 +0000
Subject: [issue19167] sqlite3 cursor.description varies across Linux (3.3.1), 
 Win32 (3.3.2), when selecting from a view.
In-Reply-To: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>
Message-ID: <1387039897.21.0.666653926402.issue19167@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the confirmation, Vajrasky.  It is apparently not hard to upgrade the sqlite3 that python uses even on Windows, so I'm going to close this issue.  (We're currently up to sqlite3 3.8.1 on 3.4).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19167>
_______________________________________

From report at bugs.python.org  Sat Dec 14 18:19:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 17:19:16 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <3dhb842NNvz7Ljl@mail.python.org>


Roundup Robot added the comment:

New changeset 9bee6cc30db7 by Serhiy Storchaka in branch '2.7':
Issue #17919: Fixed integer overflow in the eventmask parameter.
http://hg.python.org/cpython/rev/9bee6cc30db7

New changeset 87bbe810e4e7 by Serhiy Storchaka in branch '3.3':
Issue #17919: Fixed integer overflow in the eventmask parameter.
http://hg.python.org/cpython/rev/87bbe810e4e7

New changeset 2fbb3c77f157 by Serhiy Storchaka in branch 'default':
Issue #17919: Fixed integer overflow in the eventmask parameter.
http://hg.python.org/cpython/rev/2fbb3c77f157

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Sat Dec 14 18:26:59 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Dec 2013 17:26:59 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1387042019.74.0.465662841537.issue18986@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Mark Dickinson]
> It's essentially an IdentityDict, though I've found other 
> more specific transforms useful.

Have any of the applications had use for the part of the API that looks up the original, untransformed key?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Sat Dec 14 19:16:44 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 14 Dec 2013 18:16:44 +0000
Subject: [issue18986] Add a case-insensitive case-preserving dict
In-Reply-To: <1378725721.97.0.387646378602.issue18986@psf.upfronthosting.co.za>
Message-ID: <1387045004.05.0.0254025811279.issue18986@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Not my applications, no.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18986>
_______________________________________

From report at bugs.python.org  Sat Dec 14 19:26:19 2013
From: report at bugs.python.org (=?utf-8?q?G=C3=B6kcen_Eraslan?=)
Date: Sat, 14 Dec 2013 18:26:19 +0000
Subject: [issue19097] bool(cgi.FieldStorage(...)) may be False unexpectedly
In-Reply-To: <1380239682.41.0.674159694258.issue19097@psf.upfronthosting.co.za>
Message-ID: <1387045579.37.0.382963308243.issue19097@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/issue19097>
_______________________________________

From report at bugs.python.org  Sat Dec 14 19:43:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 18:43:23 +0000
Subject: [issue19623] Support for writing aifc to unseekable file
In-Reply-To: <1384602280.29.0.166311165953.issue19623@psf.upfronthosting.co.za>
Message-ID: <3dhd163zNpz7LkG@mail.python.org>


Roundup Robot added the comment:

New changeset c10ea224392d by Serhiy Storchaka in branch '2.7':
Issue #19623: Fixed writing to unseekable files in the aifc module.
http://hg.python.org/cpython/rev/c10ea224392d

New changeset 35f6a5937a63 by Serhiy Storchaka in branch '3.3':
Issue #19623: Fixed writing to unseekable files in the aifc module.
http://hg.python.org/cpython/rev/35f6a5937a63

New changeset 804406d79b45 by Serhiy Storchaka in branch 'default':
Issue #19623: Fixed writing to unseekable files in the aifc module.
http://hg.python.org/cpython/rev/804406d79b45

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19623>
_______________________________________

From report at bugs.python.org  Sat Dec 14 19:45:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 18:45:06 +0000
Subject: [issue19623] Support for writing aifc to unseekable file
In-Reply-To: <1384602280.29.0.166311165953.issue19623@psf.upfronthosting.co.za>
Message-ID: <1387046706.58.0.606381786878.issue19623@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

During applying the patch to 2.7 yet one bug was found in 2.7.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19623>
_______________________________________

From report at bugs.python.org  Sat Dec 14 20:08:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Dec 2013 19:08:20 +0000
Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or
 operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <3dhdYw00G0z7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset a3de2b3881c1 by Serhiy Storchaka in branch '3.3':
Issue #17576: Removed deprecation warnings added in changeset 618cca51a27e.
http://hg.python.org/cpython/rev/a3de2b3881c1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17576>
_______________________________________

From report at bugs.python.org  Sat Dec 14 20:57:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 19:57:59 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1387051079.11.0.598418395259.issue19100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The purpose of pprint.pprint() is to produce human-readable output. In this case some output is better than nothing. It isn't designed to be parseable by other programs, because sometimes it is even less accurate than the result of repr() (pprint() truncates long reprs and losses information for dict subclasses). Also result of pprint() can be changed from version to version (e.g. issue17150). The main source of non-ASCII characters is string reprs and for them the backslashreplace error handler doesn't lose information. And pprint.pprint() is mainly used for screen output too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Sat Dec 14 20:59:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 19:59:50 +0000
Subject: [issue19856] shutil.move() can't move a directory in non-empty
 directory on Windows
In-Reply-To: <1385924474.74.0.566817188038.issue19856@psf.upfronthosting.co.za>
Message-ID: <1387051190.44.0.896947860504.issue19856@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/issue19856>
_______________________________________

From report at bugs.python.org  Sat Dec 14 21:08:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 20:08:00 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387051680.85.0.379674435614.issue17919@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/issue17919>
_______________________________________

From report at bugs.python.org  Sat Dec 14 21:08:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 20:08:37 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387051717.84.0.184006911243.issue17919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Delhallt for your report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Sat Dec 14 21:38:03 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 14 Dec 2013 20:38:03 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1386277185.98.0.181450665143.issue19901@psf.upfronthosting.co.za>
Message-ID: <1387053483.59.0.484154962253.issue19901@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

You didn't do anything wrong. You were running 3.3.3 which is the latest release of 3.3.  Portage is Gentoo's thing, you'd have to ask the gentoo python portage ebuild maintainer and point them at the commit with the additional patch to apply if you want it fixed there.  (or file a bug on gentoo's bug tracking system and point it at this one)

In general gentoo is one of the more up to date distros (compared to everything else) but it is always helpful to try checking out and compiling the latest source tree from hg.python.org as described in http://docs.python.org/devguide/ (on the 3.3 branch in your case) when reporting an issue.

I just happened to have noticed this problem myself and fixed it without bothering to file an issue about it a few weeks before you ran into it. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19901>
_______________________________________

From report at bugs.python.org  Sat Dec 14 23:41:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 22:41:17 +0000
Subject: [issue19492] Report skipped distutils tests as skipped
In-Reply-To: <1383569864.94.0.187586889245.issue19492@psf.upfronthosting.co.za>
Message-ID: <1387060877.03.0.0335197386992.issue19492@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Why this change?

For better skip message (see a change above).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19492>
_______________________________________

From report at bugs.python.org  Sun Dec 15 00:14:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Dec 2013 23:14:01 +0000
Subject: [issue19493] Report skipped ctypes tests as skipped
In-Reply-To: <1383569878.45.0.454771857446.issue19493@psf.upfronthosting.co.za>
Message-ID: <1387062841.19.0.70543596838.issue19493@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19493>
_______________________________________

From report at bugs.python.org  Sun Dec 15 00:14:10 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 23:14:10 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387062850.18.0.18539712996.issue19946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 00:55:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Dec 2013 23:55:01 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387065301.08.0.479790742299.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I added some unit tests for the interactions between runpy and namespace packages, which showed that I was doing the check for __main__ submodules and the check for "no loader" in the wrong order.

Last missing piece is to ensure that __spec__ is being populated appropriately, then I'll check this in.

----------
Added file: http://bugs.python.org/file33132/issue19700_runpy_spec_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 01:28:29 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 15 Dec 2013 00:28:29 +0000
Subject: [issue17621] Create a lazy import loader mixin
In-Reply-To: <1364925647.64.0.233663837419.issue17621@psf.upfronthosting.co.za>
Message-ID: <1387067309.45.0.612393722281.issue17621@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Need to quickly test that this will work with PEP 451 works with the design in my head before we get farther into 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17621>
_______________________________________

From report at bugs.python.org  Sun Dec 15 01:37:56 2013
From: report at bugs.python.org (Julian Berman)
Date: Sun, 15 Dec 2013 00:37:56 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1387067876.72.0.278303436801.issue19959@psf.upfronthosting.co.za>


Julian Berman added the comment:

Why not take this a step further and make it take a callable that's expected to take the command line argument and coerce it into a path

----------
nosy: +Julian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Sun Dec 15 02:01:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 01:01:29 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387069289.39.0.832725047812.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

So close!

importlib.util.spec_from_file_location failed me (unsurprisingly) when it came to the zipfile execution tests. I'm thinking I'll just hack in a way to avoid checking the loader when the expected loader is set to None.

----------
Added file: http://bugs.python.org/file33133/issue19700_runpy_spec_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 02:16:06 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 01:16:06 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387070165.97.0.522681689867.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Latest version simply doesn't check the loader type for the zipimport tests. (Note that just using find_spec doesn't work, since the directory and zipfile execution tests include implicit sys.path manipulation)

I also removed the separated "precompiled" flag that was in earlier patches, since importlib.util.spec_from_file_location deals with that for us.

If the full regression test suite passes, I'll be checking this version in.

----------
Added file: http://bugs.python.org/file33134/issue19700_runpy_spec_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 02:49:28 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 01:49:28 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1387072168.6.0.307458380879.issue19944@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Adding a dependency on issue 19700, as I'm about to commit that fix and runpy should be updated to use whatever we come up with here.

----------
dependencies: +Update runpy for PEP 451

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:04:38 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 02:04:38 +0000
Subject: [issue14228] It is impossible to catch sigint on startup in python
 code
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387073078.88.0.711227729983.issue14228@psf.upfronthosting.co.za>


Changes by Jurko Gospodneti? <jurko.gospodnetic at gmail.com>:


----------
components: +email -Interpreter Core
nosy: +Jurko.Gospodneti?, barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:08:09 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 02:08:09 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387073289.19.0.893821794579.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Working on the docs updates made me realise the test cases didn't cover the "no suffix" case that is causing grief in issue 19946.

So I've added a test case for that now, but haven't fixed it yet (will need to deal with the __spec__ = None case for such scripts)

----------
Added file: http://bugs.python.org/file33135/issue19700_runpy_spec_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:25:41 2013
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 15 Dec 2013 02:25:41 +0000
Subject: [issue17621] Create a lazy import loader mixin
In-Reply-To: <1364925647.64.0.233663837419.issue17621@psf.upfronthosting.co.za>
Message-ID: <1387074341.4.0.804382123445.issue17621@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Attached is a script to verify that PEP 451 works as desired, so Python 3.5 doesn't have any technical blockers for doing a lazy loader for PEP 451 loaders.

And with __spec__.loader_state it might be possible to work things out through a common API to work around issue #18275 so that relying on super() and doing this as a mixin goes away and instead just somehow store the final loader on the spec (e.g. loader's constructor just takes a spec so that you can instantiate the actual loader, reset __loader__ & __spec__.loader, and then proceed with exec_module()).

----------
dependencies:  -Implementation for PEP 451 (importlib.machinery.ModuleSpec)
Added file: http://bugs.python.org/file33136/lazy_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17621>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:28:58 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 02:28:58 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
Message-ID: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>


New submission from Jurko Gospodneti?:

If you press Ctrl-C during Python startup on Windows you may get interpreter crashes with different Python tracebacks displayed on the standard system error output stream.

Reproduced using:
  - Windows 7 SP1 x64
  - Python 3.3.3 (64-bit) as downloaded from 'http://www.python.org/download/releases/3.3.3' (but seen with different earlier Python versions as well).
  - either a non-trivial Python script, one containing only a '#! python3' shabang line, or a completely empty one
  - default site.py

To reproduce simply run the Python interpreter with a prepared Python script as input and press Ctrl-C immediately afterwards.

Possible results:
  * Script finishes before your Ctrl-C kicks in.
  * You get a clean KeyboardInterrupt traceback and the script exits.
  * You get a KeyboardInterrupt traceback and the interpreter process crashes.

I'm attaching more detailed information on specific crash instances.

For some more information & background see the devel mailing list thread started at: 'https://mail.python.org/pipermail/python-dev/2013-December/130750.html'.

----------
components: Interpreter Core, Windows
files: crash-info-10.txt
messages: 206212
nosy: Jurko.Gospodneti?
priority: normal
severity: normal
status: open
title: Ctrl-C causes startup crashes on Windows
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file33137/crash-info-10.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:29:51 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 02:29:51 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387074591.1.0.311199042882.issue19983@psf.upfronthosting.co.za>


Changes by Jurko Gospodneti? <jurko.gospodnetic at gmail.com>:


Added file: http://bugs.python.org/file33138/crash-info-1-9 - Python tracebacks only.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:54:00 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 02:54:00 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387076040.68.0.723240256765.issue19983@psf.upfronthosting.co.za>


Jurko Gospodneti? added the comment:

I can reproduce this most easily if I run a command like:

  clean.cmd & run.py

where clean.cmd is any short batch script and run.py is a file containing only the '#! python3' shabang line.

The batch script in front is not necessary, and I've originally been reproducing the issue without it, but the problem seems much easier to reproduce with it, most likely because is slightly delays the Python startup and thus makes it easier for the Ctrl-C signal to kick in early enough during Python startup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 03:58:01 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 02:58:01 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387076281.31.0.0784655258393.issue19983@psf.upfronthosting.co.za>


Jurko Gospodneti? added the comment:

I reproduced the issue about 10 more times to see if I'd get some more useful C tracebacks in Visual Studio, but they seems to be the pretty much the same every time (as seen in the attached http://bugs.python.org/file33137/crash-info-10.txt file).

I'm attaching another one, just for the record. The only difference I see between crash #10 and this one is that second thread has a bit different name, but that is most likely just some internal Windows API worker thread and not something explicitly started by Python or relevant to this report.

----------
Added file: http://bugs.python.org/file33139/crash-info-11.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 04:02:42 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 03:02:42 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387076562.43.0.820316462366.issue19983@psf.upfronthosting.co.za>


Changes by Jurko Gospodneti? <jurko.gospodnetic at gmail.com>:


Removed file: http://bugs.python.org/file33139/crash-info-11.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 04:03:05 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 03:03:05 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387076585.66.0.151741038067.issue19983@psf.upfronthosting.co.za>


Changes by Jurko Gospodneti? <jurko.gospodnetic at gmail.com>:


Added file: http://bugs.python.org/file33140/crash-info-11.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 04:20:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Dec 2013 03:20:40 +0000
Subject: [issue14228] It is impossible to catch sigint on startup in python
 code
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387077640.86.0.995502251632.issue14228@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Interpreter Core -email

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Sun Dec 15 04:26:07 2013
From: report at bugs.python.org (=?utf-8?q?Jurko_Gospodneti=C4=87?=)
Date: Sun, 15 Dec 2013 03:26:07 +0000
Subject: [issue14228] It is impossible to catch sigint on startup in python
 code
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387077967.09.0.474028217987.issue14228@psf.upfronthosting.co.za>


Jurko Gospodneti? added the comment:

This issue is related to issue #19983 on Windows.

  Also, I do not think the suggested -z option implementation should be accepted 'as is'.

  On Unix it would make Ctrl-C silently terminate the process if it occurs before default Python signal handling is enabled. I do not know what effect this would have on Windows - possibly the signal would simply be ignored & lost.

  It would also still leave a slight window between when Python sets up its default SIGINT handling and when user code has a chance to set up its own.

  My first instinct is to not do that and instead add an option to block SIGINT handling and allow user code to enable its own or default Python handling as it wishes and then unblock SIGINT handling. Note that by 'blocking' a signal I do not mean losing/ignoring it but delaying its handling until signal handling is unblocked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Sun Dec 15 06:23:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 05:23:22 +0000
Subject: [issue19984] Add new format of fix length string for PyErr_Format
Message-ID: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

This ticket sprung from this discussion:
https://mail.python.org/pipermail/python-dev/2013-December/130756.html

Basically I am always confused when writing error message in C-API.

Is it:

PyErr_Format(PyExc_TypeError,"can't intern %.400s", s->ob_type->tp_name);

or

PyErr_Format(PyExc_TypeError,"can't intern %.80s", s->ob_type->tp_name);

or

PyErr_Format(PyExc_TypeError,"can't intern %s", s->ob_type->tp_name);

In conclusion, is it %s or %.80s or %.400s?

This patch will add one true way of writing fixed length string of the wrong type. This is just preliminary patch. I'll write the documentation later (and maybe test?).

----------
components: Interpreter Core
files: add_T_format_for_PyErr_Format.patch
keywords: patch
messages: 206216
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Add new format of fix length string for PyErr_Format
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file33141/add_T_format_for_PyErr_Format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19984>
_______________________________________

From report at bugs.python.org  Sun Dec 15 06:27:28 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 05:27:28 +0000
Subject: [issue19984] Add new format of fix length string for PyErr_Format
In-Reply-To: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>
Message-ID: <1387085248.66.0.5348897033.issue19984@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33141/add_T_format_for_PyErr_Format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19984>
_______________________________________

From report at bugs.python.org  Sun Dec 15 06:27:35 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 05:27:35 +0000
Subject: [issue19984] Add new format of fix length string for PyErr_Format
In-Reply-To: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>
Message-ID: <1387085255.24.0.138425443061.issue19984@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33142/add_T_format_for_PyErr_Format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19984>
_______________________________________

From report at bugs.python.org  Sun Dec 15 08:14:11 2013
From: report at bugs.python.org (Wim)
Date: Sun, 15 Dec 2013 07:14:11 +0000
Subject: [issue17088] ElementTree incorrectly refuses to write attributes
 without namespaces when default_namespace is used
In-Reply-To: <1359599707.26.0.771342463799.issue17088@psf.upfronthosting.co.za>
Message-ID: <1387091651.18.0.0655727091627.issue17088@psf.upfronthosting.co.za>


Wim added the comment:

Yes, the problem occurs regardless of whether the default_namespace parameter is the correct SVG namespace URI --- it's the fact of requesting a default namespace at all that exposes the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17088>
_______________________________________

From report at bugs.python.org  Sun Dec 15 10:08:28 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 09:08:28 +0000
Subject: [issue19984] Add new format of fixed length string for PyErr_Format
In-Reply-To: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>
Message-ID: <1387098508.15.0.843498784382.issue19984@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


----------
title: Add new format of fix length string for PyErr_Format -> Add new format of fixed length string for PyErr_Format

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19984>
_______________________________________

From report at bugs.python.org  Sun Dec 15 10:28:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 09:28:50 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
Message-ID: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Python 3.4 (3.3 is also afflicted:

>>> import struct
>>> struct.Struct(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be a bytes object, not int
>>> struct.Struct('b')
<Struct object at 0x7fec04763180>

Python 2.7:

>>> import struct
>>> struct.Struct(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Struct() argument 1 must be string, not int
>>> struct.Struct(u'b')
<Struct object at 0x17993e8>

Here is the patch to better error message for Python 3.4 and 3.3.

----------
components: Extension Modules
files: better_error_message_struct_python_34_and_33.patch
keywords: patch
messages: 206218
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Not so correct error message when initializing Struct with ill argument
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33143/better_error_message_struct_python_34_and_33.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Sun Dec 15 10:29:11 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 09:29:11 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>
Message-ID: <1387099751.66.0.164408924575.issue19985@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

And here is the patch to better error message in Python 2.7.

----------
Added file: http://bugs.python.org/file33144/better_error_message_struct_python_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Sun Dec 15 10:31:40 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 09:31:40 +0000
Subject: [issue19099] struct.pack fails first time with unicode fmt
In-Reply-To: <1380270487.08.0.885911184861.issue19099@psf.upfronthosting.co.za>
Message-ID: <1387099900.01.0.340510379896.issue19099@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Nevermind, I already created this issue. http://bugs.python.org/issue19985

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19099>
_______________________________________

From report at bugs.python.org  Sun Dec 15 11:24:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 10:24:05 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387103045.85.0.241011197068.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Final patch that reflects the version I'm about to commit. It includes appropriate docs updates, and ensures __main__.__spec__ is None in the cases where the import system isn't involved in initialising main.

----------
Added file: http://bugs.python.org/file33145/issue19700_runpy_spec_v6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 11:33:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Dec 2013 10:33:21 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <3dj25D2VPpz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 51dddfead80a by Nick Coghlan in branch 'default':
Issue #19700: set __spec__ appropriately in runpy
http://hg.python.org/cpython/rev/51dddfead80a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 11:35:52 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 10:35:52 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387103752.36.0.102863697082.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Final review of the patch showed it *wasn't* quite done, it's still missing the "both __name__ and __spec__.name are configured in sys.modules" change that is needed to get more pickle friendly behaviour from __main__.

However, I wanted to commit this version to help unblock issue 19946.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Sun Dec 15 11:36:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 10:36:46 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387103806.36.0.946472165697.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 19700 isn't quite finished, but I believe it is finished enough to let me get this working properly.

----------
dependencies:  -Update runpy for PEP 451
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 12:22:42 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 15 Dec 2013 11:22:42 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1387106562.32.0.787355677471.issue19766@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I've released distlib 0.1.5 on PyPI. This release uses dummy_threading when threading isn't available.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec 15 12:24:37 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 15 Dec 2013 11:24:37 +0000
Subject: [issue19913] TR/Crypt.XPACK.Gen-4 in easy_install.exe
In-Reply-To: <1386364438.99.0.869672605432.issue19913@psf.upfronthosting.co.za>
Message-ID: <1387106677.13.0.221168528787.issue19913@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I've released distlib 0.1.5 on PyPI. This release uses uncompressed launchers which (at the time of writing) pass the checks on virustotal.com.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19913>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:03:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 12:03:48 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1387109028.62.0.168147823504.issue19766@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Not quite fixed yet - Donald, I think all the vendored dependencies have been updated now, would it be possible to spin and incorporate a pip 1.5rc2 somewhat soonish so we know what's still left to be addressed on the ensurepip side?

----------
assignee:  -> dstufft
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:19:14 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 15 Dec 2013 12:19:14 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387109954.98.0.472240056824.issue19946@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

So there are really two situations:

1) The __main__ module *should not* be imported.  This is the case if you use __main__.py in a package or if you use nose to call test_main().

This should really be detected in get_preparation_data() in the parent process so that import_main_path() does not get called in the child process.

2) The __main__ module *should* be imported but it does not have a .py extension.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:43:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 12:43:44 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387111424.46.0.555026189273.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Bumping the priority on this, as multiprocessing is currently creating invalid child processes by failing to set __main__.__spec__ appropriately.

The attached patch is designed to get us started down that path. It's currently broken, but I need feedback from folks that know the multiprocessing code better than I do in order to know where best to start poking and prodding.

With the patch, invoking regrtest directly still works:

    ./python Lib/test/regrtest.py -v test_multiprocessing_spawn

But relying on module execution fails:
    ./python -m test -v test_multiprocessing_spawn

I appear to be somehow getting child processes where __main__.__file__ is set, but __main__.__spec__ is not.

----------
nosy: +larry
priority: low -> release blocker
Added file: http://bugs.python.org/file33146/issue19946_pep_451_multiprocessing.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 13:47:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 12:47:41 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387111661.59.0.853511848786.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

With the restructuring in my patch, it would be easy enough to move the "early return" cases from the _fixup_main_* functions to instead be "don't set the variable" cases in get_preparation_data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:05:11 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 13:05:11 +0000
Subject: [issue19167] sqlite3 cursor.description varies across Linux (3.3.1), 
 Win32 (3.3.2), when selecting from a view.
In-Reply-To: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>
Message-ID: <1387112711.72.0.0913942684543.issue19167@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Upgrading sqlite3 in Windows maybe easy but Python 2.7.6 and 3.3.3 on Windows were built with defected sqlite3. Maybe at least we can provide the correct sqlite3 version next time we release Windows version of Python 2.7 and 3.3? Python 3.3 comes with sqlite3 3.7.12. Python 2.7.6 comes with sqlite3 3.6.12.

Python 3.4 is not afflicted. It comes with sqlite3 3.8.1.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19167>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:29:32 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 15 Dec 2013 13:29:32 +0000
Subject: [issue19984] Add new format of fixed length string for PyErr_Format
In-Reply-To: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>
Message-ID: <1387114172.97.0.922975781923.issue19984@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/issue19984>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:36:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 13:36:22 +0000
Subject: [issue19984] Add new format of fixed length string for PyErr_Format
In-Reply-To: <1387085002.5.0.729792789255.issue19984@psf.upfronthosting.co.za>
Message-ID: <1387114582.67.0.296956930627.issue19984@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Originally Antoine had proposed [1] `"%T", obj` as replacement for `"%.400s", Py_TYPE(obj)->tp_name`.

[1] http://permalink.gmane.org/gmane.comp.python.devel/143925

----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19984>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:40:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 13:40:25 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>
Message-ID: <1387114825.81.0.193960517938.issue19985@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that error message in 2.7 is correct. "String" means both str and unicode.

As for 3.x, agree, it should be corrected. But I prefer "str or bytes" or "string or bytes object".

----------
nosy: +serhiy.storchaka
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Sun Dec 15 14:40:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 13:40:49 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>
Message-ID: <1387114849.22.0.386948135504.issue19985@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +mark.dickinson, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Sun Dec 15 15:31:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 14:31:01 +0000
Subject: [issue19974] tarfile doesn't overwrite symlink by directory
In-Reply-To: <1386935948.7.0.893963676407.issue19974@psf.upfronthosting.co.za>
Message-ID: <1387117861.06.0.131829053538.issue19974@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch that works both on Windows and Linux.

----------
Added file: http://bugs.python.org/file33147/fix_tarfile_overwrites_symlink_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19974>
_______________________________________

From report at bugs.python.org  Sun Dec 15 15:43:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 15 Dec 2013 14:43:10 +0000
Subject: [issue19985] Not so correct error message when initializing Struct
 with ill argument
In-Reply-To: <1387099730.06.0.788825958744.issue19985@psf.upfronthosting.co.za>
Message-ID: <1387118590.97.0.63853039761.issue19985@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch to address Serhiy's request.

Hmmm, if string means both string and unicode in Python 2.7, should we fix these behaviours?

>>> import _csv
>>> _csv.register_dialect(2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: dialect name must be a string or unicode
>>> ' cute cat '.strip(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: strip arg must be None, str or unicode
>>> import sqlite3
>>> conn = sqlite3.connect(':memory:')
>>> c = conn.cursor()
>>> c.execute(3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: operation parameter must be str or unicode

----------
Added file: http://bugs.python.org/file33148/better_error_message_struct_python_34_and_33_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19985>
_______________________________________

From report at bugs.python.org  Sun Dec 15 16:13:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 15 Dec 2013 15:13:58 +0000
Subject: =?utf-8?b?W2lzc3VlMTk5ODZdIOKAmG1wZF9kZWzigJkgZGlzY2FyZHMgcXVhbGlmaWVy?=
 =?utf-8?q?s_from_pointer_target_type?=
Message-ID: <1387120438.0.0.567792231798.issue19986@psf.upfronthosting.co.za>


New submission from Christian Heimes:

One buildbot is emitting a warning:

Modules/_decimal/libmpdec/mpdecimal.c:4438: warning: passing argument 1 of ?mpd_del? discards qualifiers from pointer target type

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/9351/steps/compile/logs/warnings%20%281%29

----------
components: Extension Modules
messages: 206236
nosy: christian.heimes
priority: low
severity: normal
stage: needs patch
status: open
title: ?mpd_del? discards qualifiers from pointer target type
type: compile error
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19986>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:05:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 15 Dec 2013 16:05:31 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
Message-ID: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>


New submission from Christian Heimes:

======================================================================
FAIL: test_alias_fallback (test.test_winsound.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_winsound.py", line 167, in test_alias_fallback
    '!"$%&/(#+*', winsound.SND_ALIAS
AssertionError: RuntimeError not raised by PlaySound


http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1948/steps/test/logs/stdio

----------
components: Tests
keywords: buildbot
messages: 206237
nosy: christian.heimes, serhiy.storchaka
priority: low
severity: normal
stage: test needed
status: open
title: Winsound: test_alias_fallback fails on WS 2008
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:27:52 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Dec 2013 16:27:52 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
Message-ID: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In Py3k __hex__ and __oct__ were removed, and hex() and oct() switched to use __index__.

hex() and oct() should be using __int__ instead.

Having read through PEP 357 [1] I see that __index__ is /primarily/ concerned with allowing arbitrary objects to be used in slices, but will also allow Python to convert an object to an int "whenever it needs one".

The problem is that my dbf [2] module has a couple custom types (Logical and Quantum) that allow for ternary logic (False/True/Unknown).  As much as possible Logical is intended to be a drop in replacement for the bool type, but of course there are some differences:

  - internally 'unknown' is represented as None

  - attempts to get an int, float, complex, etc., numeric value
    on Unknown raises an Exception

  - attempts to get the numeric string value via __hex__ and
    __oct__ on Unknown raises an Exception

  - when Unknown is used as an index (via __index__), 2 is returned

The problem, of course, is that in Python 3 calling hex() and oct() on Unknown now succeeds when it should be raising an exception, and would be if __int__ were used instead of __index__.

In summary, if Python just switches to using __index__, there would be little point in having separate __int__ and __index__ methods.


[1] http://www.python.org/dev/peps/pep-0357
[2] https://pypi.python.org/pypi/dbf

----------
messages: 206238
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: hex() and oct() use __index__ instead of __int__
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:39:00 2013
From: report at bugs.python.org (Filip Malczak)
Date: Sun, 15 Dec 2013 16:39:00 +0000
Subject: [issue19989] Error while sending function code over queue
 (multiprocessing)
Message-ID: <1387125540.4.0.544926984003.issue19989@psf.upfronthosting.co.za>


New submission from Filip Malczak:

Ive been using YAPSY to load plugins in one process. In this process I tried to put them in queue, and in another process I read them from queue.

There was a problem with non-existing type of plugin in consumer process, so I tried to serialize plugin instance by hand and deserialize by hand in consumer.

Both processes were created and started from main process, which passed them both the same queue.

Law forbids me from showing the whole code, but I'm attaching file with code pieces that generate error below:

Process ConsumerProcess-2:
Traceback (most recent call last):
  File "/usr/lib/python3.3/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.3/multiprocessing/process.py", line 95, in run
    self._target(*self._args, **self._kwargs)
  File "/<private_path>/consumer_stub.py", line 27, in _consumer
    result = foo()
  File "/<private_path>/loader_process.py", line 90, in x
    val = (kind, plugin, meta)
SystemError: ../Objects/cellobject.c:24: bad argument to internal function

----------
components: Build
files: pythonbug.txt
messages: 206239
nosy: Filip.Malczak
priority: normal
severity: normal
status: open
title: Error while sending function code over queue (multiprocessing)
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file33149/pythonbug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19989>
_______________________________________

From report at bugs.python.org  Sun Dec 15 17:44:27 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Dec 2013 16:44:27 +0000
Subject: =?utf-8?b?W2lzc3VlMTk5ODZdIOKAmG1wZF9kZWzigJkgZGlzY2FyZHMgcXVhbGlmaWVy?=
 =?utf-8?q?s_from_pointer_target_type?=
In-Reply-To: <1387120438.0.0.567792231798.issue19986@psf.upfronthosting.co.za>
Message-ID: <1387125867.59.0.25079709529.issue19986@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I agree that warnings are annoying, but I'm not sure what to do
with this one:  It's wrong and only occurs with fairly old gcc
versions.

My feeling was that pragmas are overkill for relatively old
compilers.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19986>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:05:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 17:05:27 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387127127.46.0.28603229578.issue19988@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

__index__() is used because float has __int__ but not __index__.

>>> (42.0).__int__()
42
>>> (42.0).__index__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'float' object has no attribute '__index__'

----------
nosy: +mark.dickinson, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:09:16 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 17:09:16 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387127356.83.0.906597276841.issue19987@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This test was re-enabled in issue19595.

----------
nosy: +zach.ware
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:09:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 17:09:38 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387127378.34.0.650055224154.issue19987@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/issue19987>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:16:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Dec 2013 17:16:11 +0000
Subject: [issue19167] sqlite3 cursor.description varies across Linux (3.3.1), 
 Win32 (3.3.2), when selecting from a view.
In-Reply-To: <1380919983.53.0.47531466178.issue19167@psf.upfronthosting.co.za>
Message-ID: <1387127771.96.0.0941925685263.issue19167@psf.upfronthosting.co.za>


R. David Murray added the comment:

That sqlite checkin is well before 3.7.12 was released, and 3.3.3 shipped with that version.  Was the bug present in 3.6?  If so I don't think we can do anything, since I believe we stay with the same minor version (ie: 3.6) of sqlite for the life of a minor version of Python (ie: 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19167>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:18:06 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Dec 2013 17:18:06 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1386945786.12.0.418187279765.issue19976@psf.upfronthosting.co.za>
Message-ID: <1387127886.64.0.968380167158.issue19976@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Here's a first attempt at a patch.

The Visual Studio pragma disables for the rest of the file, which is undesirable.  Maybe we could turn it on and off inline, but it's not clear to me that that would have the desired effect of turning off the warning for explicitly that parameter declaration.

Also, a little googling confirms that clang supports the GCC __attribute((unused)) extension, so I just went with that.

----------
Added file: http://bugs.python.org/file33150/larry.clinic.fix.meth_noargs.1.diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:28:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Dec 2013 17:28:32 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387128512.63.0.72990947945.issue19988@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Indeed, the definition and use of __index__ has derived since PEP 357. Nowadays, __index__ means "can be converted to an int without loss".

In any case, I find the behaviour of your "logical type" a bit dubious. If it's like bool but ternary, it *should* convert to int (or perhaps be an int subclass like bool).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:31:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Dec 2013 17:31:18 +0000
Subject: [issue19983] Ctrl-C causes startup crashes on Windows
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387128678.26.0.0789172892514.issue19983@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, tim.golden, tim.peters
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 18:37:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Dec 2013 17:37:40 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387129060.96.0.0141436137456.issue19983@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, ok. So it's a controlled crash: Python fails initializing the standard streams and so it decides to bail out (by using Py_FatalError, since Py_Initialize doesn't return an error code).

What we could do is call initsigs() after initstdio() (but still before initsite(), since initsite() can call arbitrary Python code).

I'm a bit surprised that you manage to press Ctrl-C so fast that it occurs right during initialization of standard streams, by the way :-)

----------
nosy: +haypo, pitrou
title: Ctrl-C causes startup crashes on Windows -> Ctrl-C at startup can end in a Py_FatalError call
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Sun Dec 15 20:43:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 19:43:29 +0000
Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or
 /usr/sbin
In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>
Message-ID: <1387136609.69.0.0566672404319.issue19855@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This check was added in r50954 (changeset 654c380cf8b9).

Here is better (but larger) patch for 3.3+.

----------
assignee:  -> serhiy.storchaka
nosy: +nnorwitz
Added file: http://bugs.python.org/file33151/uuid_find_mac_which_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19855>
_______________________________________

From report at bugs.python.org  Sun Dec 15 20:45:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 19:45:27 +0000
Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or
 /usr/sbin
In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>
Message-ID: <1387136727.22.0.807159205766.issue19855@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And here is a patch for 2.7. It uses backported from 3.3 and simplified variant of shutil.which().

----------
Added file: http://bugs.python.org/file33152/uuid_find_mac_which-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19855>
_______________________________________

From report at bugs.python.org  Sun Dec 15 20:54:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 19:54:24 +0000
Subject: [issue19537] Fix misalignment in fastsearch_memchr_1char
In-Reply-To: <1384014728.51.0.918202421473.issue19537@psf.upfronthosting.co.za>
Message-ID: <1387137264.76.0.198322889444.issue19537@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Antoine, if sizeof(PyUnicodeObject) is 38, the start of UCS4 unicode string is not aligned. This should be fixed.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19537>
_______________________________________

From report at bugs.python.org  Sun Dec 15 20:59:35 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Dec 2013 19:59:35 +0000
Subject: [issue19537] Fix misalignment in fastsearch_memchr_1char
In-Reply-To: <1384014728.51.0.918202421473.issue19537@psf.upfronthosting.co.za>
Message-ID: <1387137575.36.0.0335478405894.issue19537@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Antoine, if sizeof(PyUnicodeObject) is 38, the start of UCS4 unicode
> string is not aligned. This should be fixed.

Probably. Does anyone want to propose a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19537>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:03:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Dec 2013 20:03:32 +0000
Subject: =?utf-8?b?W2lzc3VlMTk5ODZdIOKAmG1wZF9kZWzigJkgZGlzY2FyZHMgcXVhbGlmaWVy?=
 =?utf-8?q?s_from_pointer_target_type?=
In-Reply-To: <1387120438.0.0.567792231798.issue19986@psf.upfronthosting.co.za>
Message-ID: <3djGl72YMgz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 274b293435fb by Stefan Krah in branch '3.3':
Issue #19986: Avoid an incorrect warning of older gcc versions.
http://hg.python.org/cpython/rev/274b293435fb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19986>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:11:08 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 15 Dec 2013 20:11:08 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387138268.34.0.239760945398.issue19946@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> I appear to be somehow getting child processes where __main__.__file__ is
> set, but __main__.__spec__ is not.

That seems to be true for the __main__ module even when multiprocessing is not involved.  Running a file /tmp/foo.py containing

    import sys
    print(sys.modules['__main__'].__spec__, sys.modules['__main__'].__file__)

I get output

    None /tmp/foo.py

I am confused by why you would ever want to load by module name rather than file name.  What problem would that fix?  If the idea is just to support importing a main module without a .py extension, isn't __file__ good enough?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:20:03 2013
From: report at bugs.python.org (Andreas Schwab)
Date: Sun, 15 Dec 2013 20:20:03 +0000
Subject: [issue19537] Fix misalignment in fastsearch_memchr_1char
In-Reply-To: <1384014728.51.0.918202421473.issue19537@psf.upfronthosting.co.za>
Message-ID: <1387138803.33.0.0513019442856.issue19537@psf.upfronthosting.co.za>


Andreas Schwab added the comment:

How about adding explicit padding to the bitfield in PyASCIIObject?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19537>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:21:14 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Dec 2013 20:21:14 +0000
Subject: [issue19537] Fix misalignment in fastsearch_memchr_1char
In-Reply-To: <1387138803.33.0.0513019442856.issue19537@psf.upfronthosting.co.za>
Message-ID: <1387138871.2296.0.camel@fsol>


Antoine Pitrou added the comment:

> How about adding explicit padding to the bitfield in PyASCIIObject?

That sounds ok to me, but it must be explicitly for 68k (or use a
sufficiently smart scheme not to affect already aligned architectures).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19537>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:42:51 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Dec 2013 20:42:51 +0000
Subject: =?utf-8?b?W2lzc3VlMTk5ODZdIOKAmG1wZF9kZWzigJkgZGlzY2FyZHMgcXVhbGlmaWVy?=
 =?utf-8?q?s_from_pointer_target_type?=
In-Reply-To: <1387120438.0.0.567792231798.issue19986@psf.upfronthosting.co.za>
Message-ID: <1387140171.16.0.512299330838.issue19986@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type: compile error -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19986>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:45:05 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 15 Dec 2013 20:45:05 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387140305.81.0.666483742919.issue19988@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> hex() and oct() should be using __int__ instead.

Strong -1 from me.  I wouldn't want `hex(45.3)` to work, and `hex(45.0)` working isn't much better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:57:26 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Dec 2013 20:57:26 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387141046.94.0.89065053804.issue19988@psf.upfronthosting.co.za>


Stefan Krah added the comment:

-1 from me as well.  I would not want to audit a large program for
accidentally converted floats.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 21:58:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 20:58:37 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387141117.21.0.232043612972.issue18879@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Jakub's patch has a bug:

>>> import tempfile
>>> f = tempfile.NamedTemporaryFile(dir=".",delete=False)
>>> write = f.write
>>> write
<function BufferedRandom.write at 0xb716b4f4>
>>> write2 = f.write
>>> write2
<built-in method write of _io.BufferedRandom object at 0xb721deac>
>>> del f
>>> write(b'foo')
3
>>> del write
>>> write2(b'bar')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: write to closed file

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sun Dec 15 22:09:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Dec 2013 21:09:47 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387141787.66.0.073003640809.issue18879@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is fixed Jakub's patch.

----------
assignee:  -> serhiy.storchaka
Added file: http://bugs.python.org/file33153/tempfile_wrap_methods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sun Dec 15 22:14:39 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Sun, 15 Dec 2013 21:14:39 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <1387142079.6.0.910578441173.issue19648@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Hi,

I created 2 simple tests for test_getinitargs and test_reduce.

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33154/19648.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Sun Dec 15 22:21:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Dec 2013 21:21:03 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1387138268.34.0.239760945398.issue19946@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cSk+Tp_6_ELXzZSQZjyK51ZLWTtSjhQ9R-pgEFne_Peg@mail.gmail.com>


Nick Coghlan added the comment:

Scripts (whether in source form or precompiled) work via direct execution,
but all the other execution paths (directories, zipfiles, -m) rely on the
import system (via runpy). multiprocessing has been broken for years in
that regard, hence my old comment about the way it derived the module name
from the file name being problematic (although it only outright *broke*
with submodule execution, and even then you would likely get away with it
if you didn't use relative imports).

Historically, it was a hard problem to solve, since even the parent process
forgot the original name of __main__, but PEP 451 has now fixed that
limitation.

I also have an idea as to what may be wrong with my patch - I'm going to
try adjusting the first early return from _fixup_main_from_name to ensure
that __main__.__spec__ is set correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Sun Dec 15 22:25:09 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Dec 2013 21:25:09 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387142709.92.0.266161758817.issue19988@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Guido, I believe that __index__ was your initiative.  Do you care to opine on this one?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 23:27:50 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 15 Dec 2013 22:27:50 +0000
Subject: [issue19990] Add unittests for imghdr module
Message-ID: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello! The following patch adds unit tests for the previously untested `imghdr` module.

----------
components: Tests
files: test_imghdr.patch
keywords: patch
messages: 206262
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: Add unittests for imghdr module
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33155/test_imghdr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19990>
_______________________________________

From report at bugs.python.org  Sun Dec 15 23:50:45 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 15 Dec 2013 22:50:45 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387147845.36.0.725933180477.issue19988@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I agree with Mark and Stafan.  Hex/oct/bin are only defined for integers.  __int__ is ambiguous -- it has the same problem as (int) in C in that it applies to floats and then loses the fraction.

I think the problem with Ethan's ternary logic is that it tries to act as an index and yet doesn't want to be an integer -- that doesn't make a lot of logical sense.  (You should use a dict to map from true/false/unknown, not a list of size three.)

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Sun Dec 15 23:55:55 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 15 Dec 2013 22:55:55 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387148155.76.0.980906935234.issue17919@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Hi, this happens on the OpenIndiana bot:

http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.3/builds/1259/steps/test/logs/stdio

test_devpoll1 (test.test_devpoll.DevPollTests) ... ok
test_events_mask_overflow (test.test_devpoll.DevPollTests) ... ERROR
test_timeout_overflow (test.test_devpoll.DevPollTests) ... ok

======================================================================
ERROR: test_events_mask_overflow (test.test_devpoll.DevPollTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.3.cea-indiana-x86/build/Lib/test/test_devpoll.py", line 96, in test_events_mask_overflow
    self.assertRaises(OverflowError, pollster.register, 0, USHRT_MAX + 1)
NameError: global name 'USHRT_MAX' is not defined

----------------------------------------------------------------------
Ran 3 tests in 0.006s

FAILED (errors=1)
test test_devpoll failed

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Sun Dec 15 23:58:44 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 15 Dec 2013 22:58:44 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387148324.76.0.601890405157.issue17919@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have fixed the issue in http://hg.python.org/cpython/rev/039306b45230

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 00:12:41 2013
From: report at bugs.python.org (David Watson)
Date: Sun, 15 Dec 2013 23:12:41 +0000
Subject: [issue12837] Patch for issue #12810 removed a valid check on socket
 ancillary data
In-Reply-To: <1386953753.48.0.823018115928.issue12837@psf.upfronthosting.co.za>
Message-ID: <20131215231236.GA4998@dbwatson.uk7.net>


David Watson added the comment:

On Fri 13 Dec 2013, Brett Cannon wrote:
> Two things. First, I'm sorry David but my mind is not working fully enough at the moment to see how msg_controllen is compared to cmsg_len_end without relying on external value coming in through the parameters of the function.

The lines (in the existing code)

    if (space < cmsg_len_end)
        space = cmsg_len_end;

ensure that space >= cmsg_len_end, and then we have

    return (cmsg_offset <= (size_t)-1 - space &&
            cmsg_offset + space <= msg->msg_controllen);

so that 0 is returned if msg->msg_controllen < (cmsg_offset +
space), but since cmsg_offset is nonnegative and cmsg_len_end <=
space, we always have cmsg_len_end <= (cmsg_offset + space).
Hence if we get to this last line and msg->msg_controllen <
cmsg_len_end, then msg->msg_controllen < (cmsg_offset + space),
and so the function returns 0.

(So returning 0 immediately if msg->msg_controllen < cmsg_len_end
doesn't change the behaviour of the function, provided this
comparison is done correctly.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12837>
_______________________________________

From report at bugs.python.org  Mon Dec 16 01:13:55 2013
From: report at bugs.python.org (Andrei Kucharavy)
Date: Mon, 16 Dec 2013 00:13:55 +0000
Subject: [issue19991] configparser instances cannot be pretty printed
Message-ID: <1387152835.44.0.30925026143.issue19991@psf.upfronthosting.co.za>


New submission from Andrei Kucharavy:

ConfigParser seems to share a lot of behavior with a dict, but cannot be pretty printed.

----------
messages: 206267
nosy: Andrei.Kucharavy
priority: normal
severity: normal
status: open
title: configparser instances cannot be pretty printed
type: enhancement
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19991>
_______________________________________

From report at bugs.python.org  Mon Dec 16 01:26:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 00:26:29 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387153589.3.0.0650367691104.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Here is a patch with unrolled loops.

I suppose that was some kind of joke, but what I meant was that we don't need to test with 100 levels of symlinks. 2 or 3 are enough...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 01:50:15 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 00:50:15 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387155015.26.0.787611531386.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch with refactored tests. Vajrasky, do you want to test under Windows?

----------
Added file: http://bugs.python.org/file33156/pathlib_resolve_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:06:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Dec 2013 01:06:32 +0000
Subject: [issue19991] configparser instances cannot be pretty printed
In-Reply-To: <1387152835.44.0.30925026143.issue19991@psf.upfronthosting.co.za>
Message-ID: <1387155992.68.0.251891355772.issue19991@psf.upfronthosting.co.za>


R. David Murray added the comment:

Without looking at the details, I would guess that doing anything about this should have issue 7434 as a prereq.  But  ?ukasz will have a more informed opinion.

----------
nosy: +lukasz.langa, r.david.murray
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19991>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:29:41 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Dec 2013 01:29:41 +0000
Subject: [issue19104] pprint produces invalid output for long strings
In-Reply-To: <1380289250.98.0.0529515271695.issue19104@psf.upfronthosting.co.za>
Message-ID: <1387157381.51.0.587442085173.issue19104@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Would it pay to have a meta issue for all the outstanding pprint issues, or possibly make issue 7434 the meta issue?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19104>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:52:40 2013
From: report at bugs.python.org (Thayne McCombs)
Date: Mon, 16 Dec 2013 01:52:40 +0000
Subject: [issue19992] subprocess documentation not explicit about fileno()
Message-ID: <1387158760.79.0.499761911724.issue19992@psf.upfronthosting.co.za>


New submission from Thayne McCombs:

The subprocess documentation for stdout/stderr/stdin states: 
"Valid values are PIPE, an existing file descriptor (a positive integer), an existing file object, and None. PIPE indicates that a new pipe to the child should be created."

However, file-like objects such as StringIO are not valid if they do not implement fileno(). The documentation should be more explicit that the file object should be backed by an actual file descriptor (and therefore has a fileno() function).

----------
assignee: docs at python
components: Documentation
messages: 206272
nosy: Thayne.McCombs, docs at python
priority: normal
severity: normal
status: open
title: subprocess documentation not explicit about fileno()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19992>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:57:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 01:57:06 +0000
Subject: [issue19532] compileall -f doesn't force to write bytecode files
In-Reply-To: <1383977671.71.0.216863733514.issue19532@psf.upfronthosting.co.za>
Message-ID: <3djQb52KhDz7LkH@mail.python.org>


Roundup Robot added the comment:

New changeset 6afad4f29249 by R David Murray in branch '3.3':
#19532: make compileall with no file/dir args respect -f and -q.
http://hg.python.org/cpython/rev/6afad4f29249

New changeset 0e07ab605e0b by R David Murray in branch 'default':
Merge: #19532: make compileall with no file/dir args respect -f and -q.
http://hg.python.org/cpython/rev/0e07ab605e0b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19532>
_______________________________________

From report at bugs.python.org  Mon Dec 16 02:58:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Dec 2013 01:58:23 +0000
Subject: [issue19532] compileall -f doesn't force to write bytecode files
In-Reply-To: <1383977671.71.0.216863733514.issue19532@psf.upfronthosting.co.za>
Message-ID: <1387159103.44.0.0192035150648.issue19532@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Vajrasky.

I did not backport this to 2.7 because the code is different and we don't have proper tests there, so the chance of breaking something is higher than the benefit of fixing it.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19532>
_______________________________________

From report at bugs.python.org  Mon Dec 16 03:04:56 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 02:04:56 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387159496.56.0.395213596474.issue19988@psf.upfronthosting.co.za>


Ethan Furman added the comment:

For the record, the true/false values of my Logical type do convert to int, just not the unknown value.

I agree using __int__ is dubious because of float (and Decimal, etc.), which means really the only clean way to solve the issue (definitely for me, and for any one else in a similar situation) is to bring back __hex__, __oct__, and, presumably, __bin__.

To make things even worse, there is a discrepancy between hex() and %x, oct() and %o:

  --> hex(Unknown)
  '0x2'

  --> oct(Unknown)
  '0o2'

  --> '%x' % Unknown
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: %x format: a number is required, not Logical

  --> '%o' % Unknown
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: %o format: a number is required, not Logical

Which is bizarre when one considers:

  --> '%o' % Truth
  '1'

So if '%o' fails, why doesn't oct()?

Do we reopen this issue, or start a new one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Mon Dec 16 04:38:39 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Dec 2013 03:38:39 +0000
Subject: [issue19990] Add unittests for imghdr module
In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za>
Message-ID: <1387165119.5.0.292639627163.issue19990@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Beside my review, I think we need one more test that tests the invalid image file, for example file with header b'cutecat'.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19990>
_______________________________________

From report at bugs.python.org  Mon Dec 16 05:38:51 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Dec 2013 04:38:51 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387168731.59.0.615643159535.issue19988@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I still think the problem is with your class design.  You shouldn't want a hex representation for a value that's not an integer.

For the difference between %x and hex() please open another issue (you might want to track down the cause in the source first so you can add a patch or at least a suggested fix to the issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Mon Dec 16 08:55:02 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 16 Dec 2013 07:55:02 +0000
Subject: [issue19990] Add unittests for imghdr module
In-Reply-To: <1387146470.57.0.419345603545.issue19990@psf.upfronthosting.co.za>
Message-ID: <1387180502.92.0.430792279496.issue19990@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Thanks for the review, Vajrasky! Here's the updated version.

----------
Added file: http://bugs.python.org/file33157/test_imghdr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19990>
_______________________________________

From report at bugs.python.org  Mon Dec 16 09:31:16 2013
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Mon, 16 Dec 2013 08:31:16 +0000
Subject: [issue19993] Pool.imap doesn't work as advertised
Message-ID: <1387182676.04.0.471976296284.issue19993@psf.upfronthosting.co.za>


New submission from Jurjen N.E. Bos:

The pool.imap and pool.imap_unordered functions are documented as "a lazy version of Pool.map".
In fact, they aren't: they consume the iterator argument as a whole. This is almost certainly not what the user wants: it uses unnecessary memory and will be slower than expected if the output iterator isn't consumed in full. In fact, there isn't much use at all of imap over map at the moment.
I tried to fixed the code myself, but due to the two-level queueing of the input arguments this is not trivial.
Stackoverflow's Blckknght wrote a simplified solution that gives the idea how it should work.
Since that wasn't posted here, I thought it would be useful to put it here, even if only for documentation purposes.

----------
components: Library (Lib)
files: mypool.py
messages: 206279
nosy: jneb
priority: normal
severity: normal
status: open
title: Pool.imap doesn't work as advertised
type: behavior
Added file: http://bugs.python.org/file33158/mypool.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19993>
_______________________________________

From report at bugs.python.org  Mon Dec 16 09:42:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Dec 2013 08:42:52 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1387183372.45.0.389760969029.issue19871@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

How about this doc fix?

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33159/fix_doc_parse_non_valid_json_float.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19871>
_______________________________________

From report at bugs.python.org  Mon Dec 16 09:50:34 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 08:50:34 +0000
Subject: [issue19976] Argument Clinic: generate second arg for METH_NOARGS
In-Reply-To: <1387127886.64.0.968380167158.issue19976@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYOFwK_eU+SbhDcQo8sxOtBGqOrgTHPhokKNwbBas-GwQ@mail.gmail.com>


STINNER Victor added the comment:

> The Visual Studio pragma disables for the rest of the file, which is undesirable.  Maybe we could turn it on and off inline, but it's not clear to me that that would have the desired effect of turning off the warning for explicitly that parameter declaration.

Oh, I didn't know that it is file-wide. There are
__pragma(warning(push)) and __pragma(warning(pop)) commands to disable
a pragma. I don't know it is can be used using Py_UNUSED(name) macro
(is it possible to "pop" the pragma before the function body?).

If a compiler does not provide a syntax to disable the warning just in
one function, the warning should be disabled for the compilation of
the whole project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19976>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:02:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 09:02:29 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387184549.18.0.248908328227.issue19983@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I modified initstdio() to add raise(SIGINT); at the beginning of the function. I get:

$ ./python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 2157, in _find_and_load
KeyboardInterrupt
Abandon (core dumped)

You can also inject SIGINT in gdb if you set a breakpoint on initstdio():

(gdb) b initstdio
(gdb) run
<python stopped at initstdio enter>
(gdb) signal SIGINT

I don't consider this as a bug, but I understand that you would prefer a different behaviour. The question is which behaviour do you want? You want to ignore CTRL+c during initialization? Do you prefer to quit without calling abort(), ex: exit with exit code 1?

Maybe we should modify Py_FatalError() to call exit(1) in release mode, and only call abort() in debug mode? Dumping a core dump, opening a Windows fatal error popup, calling Fedora ABRT handler, etc. is maybe not very useful, especially for the KeyboardInterrupt case.

> What we could do is call initsigs() after initstdio() (but still before initsite(), since initsite() can call arbitrary Python code).

initfsencoding() calls also Python code. It loads at least 3 Python scripts: encodings/__init__.py, encodings/aliases.py and encodings/NAME.py where NAME is your locale encoding.

IMO signal handlers should be set up before any Python code is loaded, so initsigs() should be called before initfsencoding().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:16:04 2013
From: report at bugs.python.org (Taesu Pyo)
Date: Mon, 16 Dec 2013 09:16:04 +0000
Subject: [issue19994] re.match does not return or takes long time
Message-ID: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>


New submission from Taesu Pyo:

// code sampe:

import re

r = (r'(/.*)*X')
s = '////////////////////////////'

print re.match(r, s)
print list(re.finditer(r, s))
print re.findall(r, s)

// it does not return or takes long time depends on length of 's'

----------
components: Regular Expressions
messages: 206283
nosy: Taesu.Pyo, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.match does not return or takes long time
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19994>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:17:07 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 16 Dec 2013 09:17:07 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <1387184549.18.0.248908328227.issue19983@psf.upfronthosting.co.za>
Message-ID: <52AEC510.1050407@egenix.com>


Marc-Andre Lemburg added the comment:

On 16.12.2013 10:02, STINNER Victor wrote:
> 
> Maybe we should modify Py_FatalError() to call exit(1) in release mode, and only call abort() in debug mode? Dumping a core dump, opening a Windows fatal error popup, calling Fedora ABRT handler, etc. is maybe not very useful, especially for the KeyboardInterrupt case.

I don't think changing Py_FatalError() is a good idea. However,
its use in this particular case (streams not initializing) appears
wrong.

Python should simply exit with an error code in such a case; which then
also allows the calling script or application to react to the error.

The fatal error is reserved for cases where you cannot continue
and can't even report back an error, not even as error code.
Those are rare situations. You usually only use abort() if you need
to debug the situation via a core dump, which is not needed in
this case, since we know that the user caused a keyboard
interrupt and in most other cases know that it's a config problem,
not a problem in the C implementation of Python.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:21:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 09:21:19 +0000
Subject: [issue19537] Fix misalignment in fastsearch_memchr_1char
In-Reply-To: <1384014728.51.0.918202421473.issue19537@psf.upfronthosting.co.za>
Message-ID: <1387185679.19.0.407255845372.issue19537@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If you compile Python with GCC, we can maybe try something with __attribute__ ((aligned (sizeof(void *)))) attribute. The attribute can be used on a structure field. The problem is that we don't care of the alignment of header attributes, only of data, but data is not a field but the data just after the structure.

Or is it possible to GCC to get a structure size aligned on 4 bytes?

For the explicit padding: how do you compute the size of the padding?

How about disabling the fast-path in FASTSEARCH if data is not aligned?

(You might get non-aligned if even if structure is correctly aligned, it may happen if the memory allocator does not align memory blocks. I don't know if Python may get "unaligned" memory blocks.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19537>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:23:39 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 09:23:39 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387185819.33.0.877817000795.issue17919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I have fixed the issue in http://hg.python.org/cpython/rev/039306b45230

You forget 2.7 and 3.3 branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:30:19 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 09:30:19 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <52AEC510.1050407@egenix.com>
Message-ID: <CAMpsgwas3_KqnPQ+XB3U=w7vw3CZ59r0GDHqEmv=bVNPN=+xTg@mail.gmail.com>


STINNER Victor added the comment:

2013/12/16 Marc-Andre Lemburg <report at bugs.python.org>:
> I don't think changing Py_FatalError() is a good idea. However,
> its use in this particular case (streams not initializing) appears
> wrong.
>
> Python should simply exit with an error code in such a case; which then
> also allows the calling script or application to react to the error.

Before exiting, you need a message. If there is also an exception, you
may want to display it. If there is no exception, you may want to
display the Python traceback. All these tasks are already implemented
in Py_FatalError.

If the defaullt behaviour of Py_FatalError() cannot be modified, a new
function should be be added, a function sharing its code with
Py_FatalError().

Example: a new private function "void initerror(const char *message)"
only used during Py_Initialize().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:32:30 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 16 Dec 2013 09:32:30 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <CAMpsgwas3_KqnPQ+XB3U=w7vw3CZ59r0GDHqEmv=bVNPN=+xTg@mail.gmail.com>
Message-ID: <52AEC8AB.3070908@egenix.com>


Marc-Andre Lemburg added the comment:

On 16.12.2013 10:30, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> 2013/12/16 Marc-Andre Lemburg <report at bugs.python.org>:
>> I don't think changing Py_FatalError() is a good idea. However,
>> its use in this particular case (streams not initializing) appears
>> wrong.
>>
>> Python should simply exit with an error code in such a case; which then
>> also allows the calling script or application to react to the error.
> 
> Before exiting, you need a message. If there is also an exception, you
> may want to display it. If there is no exception, you may want to
> display the Python traceback. All these tasks are already implemented
> in Py_FatalError.
> 
> If the defaullt behaviour of Py_FatalError() cannot be modified, a new
> function should be be added, a function sharing its code with
> Py_FatalError().
> 
> Example: a new private function "void initerror(const char *message)"
> only used during Py_Initialize().

Sounds reasonable.

BTW: Why can't we make this an official API function, e.g.
Py_Terminate() ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Mon Dec 16 10:37:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 09:37:52 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387186672.44.0.589848207027.issue19983@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> BTW: Why can't we make this an official API function, e.g. Py_Terminate() ?

Exiting Python immediatly is bad practice, there is already Py_FatalError() for that.

Instead of adding a second public function, I would prefer to remove most calls to Py_FatalError() and write nicer error handlers :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Mon Dec 16 11:29:04 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 10:29:04 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
Message-ID: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Using Enum to illustrate:

    --> class Grade(enum.Enum):
    ...   A = 4
    ...   B = 3
    ...   C = 2
    ...   D = 1
    ...   F = 0
    ...   def __index__(self):
    ...     return self._value_

    --> ['miserable'][Grade.F]
    'miserable'

    --> '%x' % Grade.F
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: %x format: a number is required, not Grade

    --> hex(Grade.F)
    '0x0'

I suggest that hex() and oct() have the same check that %x and %o do so that non-numbers are not representable as hex and octal.  

While we're at it, we should do the same for bin().  Are there any others?

I'll create a patch once we have a decision on which way to solve this issue.

----------
assignee: ethan.furman
messages: 206290
nosy: ethan.furman, gvanrossum, mark.dickinson, pitrou, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: hex() and %x, oct() and %o do not behave the same
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 11:33:23 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 10:33:23 +0000
Subject: [issue19988] hex() and oct() use __index__ instead of __int__
In-Reply-To: <1387124872.75.0.863849760572.issue19988@psf.upfronthosting.co.za>
Message-ID: <1387190003.67.0.882704642377.issue19988@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Guido van Rossum opined:
------------------------
> I still think the problem is with your class design.
> You shouldn't want a hex representation for a value
> that's not an integer.

Well, in fairness I only supported it because bool does, and I was trying to have Logical match bool as closely as possible.  Which is also why, in Py2, attempting such operations on an Unknown value raises exceptions.

As an example:

  # bool
  --> True + True
  2

  # Logical
  --> Truth + Truth
  2

  --> Truth + Unknown
  Logical('?')

I can do that because I was able to override __add__ and __raddd__; however, if I _do not_ overide index:

  # bool
  --> ['no', 'yes'][True]
  'yes'

  # Logical
  --> ['no', 'yes', 'maybe'][Truth]
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: list indices must be integers, not Logical

So either I break compatibility with bools in a rather fundamental way, or I live with the eyesore of being able to use %x and %o on Unknown values.

Incidentally, bool is still not subclassable, and using int as a base class for Logical blew up over half my tests.

Perhaps not quite so incidentally, if __index__ is added to an Enum (not IntEnum) subclass, it will have the same wierdness.


Guido van Rossum stated:
------------------------
> For the difference between %x and hex() please open another
> issue (you might want to track down the cause in the source
> first so you can add a patch or at least a suggested fix to
> the issue).

Issue19995 is created, current participants nosied.  I'll track it down as soon as I can (may be a few days).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19988>
_______________________________________

From report at bugs.python.org  Mon Dec 16 11:44:22 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Dec 2013 10:44:22 +0000
Subject: [issue19871] json module won't parse a float that starts with a
 decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1387190662.29.0.10604504753.issue19871@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Okay, I added unit test for this edge case.

----------
Added file: http://bugs.python.org/file33160/parse_non_valid_json_float_with_unit_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19871>
_______________________________________

From report at bugs.python.org  Mon Dec 16 11:44:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 10:44:42 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387190682.59.0.460309299571.issue19995@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Calls:
* hex()/oct() => PyNumber_ToBase() => PyNumber_Index().
* PyUnicode_Format() => mainformatlong() => PyNumber_Long()

I never understood the difference between "long" (__int__ method) and "index" (__index__ method). Is the difference on the behaviour of floating point numbers?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 12:42:30 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 11:42:30 +0000
Subject: [issue19996] httplib infinite read on invalid header
Message-ID: <1387194150.79.0.311354392317.issue19996@psf.upfronthosting.co.za>


Changes by Cory Benfield <cory at lukasa.co.uk>:


----------
components: Library (Lib)
nosy: Lukasa
priority: normal
severity: normal
status: open
title: httplib infinite read on invalid header
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 12:55:45 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 11:55:45 +0000
Subject: [issue19996] httplib infinite read on invalid header
Message-ID: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>


New submission from Cory Benfield:

Initially spotted on Requests GitHub bugtracker: https://github.com/kennethreitz/requests/issues/1804

On receiving an HTTP response with an invalid header, httplib stops parsing the headers and attempts to receive the rest of the message as body content. Normally that would be fine, but problems occur if later on in the headers "Transfer-Encoding: chunked" is declared. This leads to a hang while reading the body content until the remote end forcibly closes the connection.

This bug certainly affects versions 2.7 through 3.3.

To reproduce (note that we need to request gzip to get the server to send the bad header):

    import http.client
    h = http.client.HTTPConnection('www.sainsburysbank.co.uk')
    h.request('GET', '/', headers={'Accept-Encoding': 'gzip'})
    r = h.getresponse()
    hdrs = r.getheaders()
    body = r.read()  # Hang here.

cURL configured equivalently doesn't exhibit this problem, that is the following works fine:

curl --compressed http://www.sainsburysbank.co.uk/


It's not clear to me that this behaviour is wrong. The server is definitely violating RFC 2616 which expressly forbids empty header names. I'm open to consultation about what the correct fix should be here (which may be nothing at all).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:28:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 12:28:59 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <3djhcB39x8z7Ljw@mail.python.org>


Roundup Robot added the comment:

New changeset c42647d76bd1 by Christian Heimes in branch '3.3':
Issue #17919: add missing import of USHRT_MAX
http://hg.python.org/cpython/rev/c42647d76bd1

New changeset 1f3f4147c35e by Christian Heimes in branch 'default':
Issue #17919: add missing import of USHRT_MAX
http://hg.python.org/cpython/rev/1f3f4147c35e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:29:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Dec 2013 12:29:54 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387196994.66.0.3414897424.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I created a test suite to ensure that all the various cases were handled correctly by the eventual patch (it doesn't test some of the namespace package related edge cases, but they devolve to normal module execution in terms of the final state of __main__, and that's covered by these tests).

----------
Added file: http://bugs.python.org/file33161/test_multiprocessing_main_handling.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:39:08 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Dec 2013 12:39:08 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387197548.92.0.8184025375.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Current work in progress patch. The existing multiprocessing tests all pass, but the new main handling tests fail.

The fork start_method passes all the tests
The forkserver and spawn start methods fail the directory, zipfile and package tests.

----------
Added file: http://bugs.python.org/file33162/issue19946_pep_451_multiprocessing_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:44:53 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Dec 2013 12:44:53 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387197893.17.0.165375470537.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated test that handles timeouts better.

I also realised the current test failures are due to an error in the test design - the "failing" cases are ones where we deliberately *don't* rerun __main__ because the entire __main__.py file is assumed to be inside an implicit __main__-only guard.

So the code changes should be complete, I just need to figure out a way to tweak the tests appropriately.

----------
Added file: http://bugs.python.org/file33163/test_multiprocessing_main_handling.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:45:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Dec 2013 12:45:00 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387197900.75.0.974624053895.issue19946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:48:13 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 16 Dec 2013 12:48:13 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
Message-ID: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

imghdr.what check explicitly for string path, while `open` happily accepts bytes paths, as seen below:

>>> x
b'\xc2\xba'
>>> imghdr.what(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tank/libs/cpython/Lib/imghdr.py", line 15, in what
    location = file.tell()
AttributeError: 'bytes' object has no attribute 'tell'
>>> open(x)
<_io.TextIOWrapper name=b'\xc2\xba' mode='r' encoding='UTF-8'>

A reason why this should be supported can be found in this message: http://bugs.python.org/msg191691.
The following patch fixes this. Also, it depends on issue19990 (where test_imghdr.py was added).

----------
components: Library (Lib)
files: imghdr_bytes.patch
keywords: patch
messages: 206299
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: imghdr.what doesn't accept bytes paths
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file33164/imghdr_bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:50:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 12:50:41 +0000
Subject: [issue19965] Non-atomic generation of Include/Python-ast.h and
 Python/Python-ast.c
In-Reply-To: <1386868810.74.0.691786710751.issue19965@psf.upfronthosting.co.za>
Message-ID: <3djj5D6JgZz7Ljw@mail.python.org>


Roundup Robot added the comment:

New changeset 874813a3523d by Charles-Fran?ois Natali in branch '2.7':
Issue #19965: Make sure that Python-ast.h is properly taken into account in the
http://hg.python.org/cpython/rev/874813a3523d

New changeset cfe0a293551f by Charles-Fran?ois Natali in branch '3.3':
Issue #19965: Make sure that Python-ast.h is properly taken into account in the
http://hg.python.org/cpython/rev/cfe0a293551f

New changeset ad42ea70668e by Charles-Fran?ois Natali in branch 'default':
Issue #19965: Make sure that Python-ast.h is properly taken into account in the
http://hg.python.org/cpython/rev/ad42ea70668e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19965>
_______________________________________

From report at bugs.python.org  Mon Dec 16 13:56:12 2013
From: report at bugs.python.org (Olivier Grisel)
Date: Mon, 16 Dec 2013 12:56:12 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387198572.45.0.118011569032.issue19946@psf.upfronthosting.co.za>


Olivier Grisel added the comment:

I applied issue19946_pep_451_multiprocessing_v2.diff and I confirm that it fixes the problem that I reported initially.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:08:52 2013
From: report at bugs.python.org (Reuben Garrett)
Date: Mon, 16 Dec 2013 13:08:52 +0000
Subject: [issue19901] tests fail due to unsupported SO_REUSEPORT when building
 Python 3.3.2-r2
In-Reply-To: <1387053483.59.0.484154962253.issue19901@psf.upfronthosting.co.za>
Message-ID: <CAA-SZJGOmzRBbRnOAAwXjgSSo4P4DC59-aBZUGoabNjWByRqTw@mail.gmail.com>


Reuben Garrett added the comment:

On Sat, Dec 14, 2013 at 2:38 PM, Gregory P. Smith <report at bugs.python.org>
wrote:
> ask the gentoo python portage ebuild maintainer and point them at the
commit with the additional patch to apply if you want it fixed there.  (or
file a bug on gentoo's bug tracking system and point it at this one)
> ?
> try checking out and compiling the latest source tree from hg.python.orgas described in
http://docs.python.org/devguide/ (on the 3.3 branch in your case) when
reporting an issue.

That's actually really good advice (applicable to other projects beyond
Python) ? thank you so much, Gregory!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19901>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:11:38 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 16 Dec 2013 13:11:38 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387199498.78.0.359927195208.issue19995@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It seems to me that by giving it an __index__ method, you're saying it can be used as an integer. It's not surprising to me that hex(), oct(), and bin() would work with a Grade.F object. If anything, I'd say that more places should use __index__ than currently do.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:22:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 13:22:48 +0000
Subject: [issue19911] ntpath.splitdrive() fails when UNC part contains \u0130
In-Reply-To: <1386353906.42.0.949556557512.issue19911@psf.upfronthosting.co.za>
Message-ID: <3djjpJ009Vz7LmM@mail.python.org>


Roundup Robot added the comment:

New changeset 7b0d083082ea by Serhiy Storchaka in branch '3.3':
Issue #19911: ntpath.splitdrive() now correctly processes the '?' character
http://hg.python.org/cpython/rev/7b0d083082ea

New changeset 63d769dfa4ef by Serhiy Storchaka in branch 'default':
Issue #19911: ntpath.splitdrive() now correctly processes the '?' character
http://hg.python.org/cpython/rev/63d769dfa4ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19911>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:22:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 13:22:49 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
In-Reply-To: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>
Message-ID: <3djjpJ5jnVz7Lmy@mail.python.org>


Roundup Robot added the comment:

New changeset 129105f8457d by Serhiy Storchaka in branch '3.3':
Issue #19912: Fixed numerous bugs in ntpath.splitunc().
http://hg.python.org/cpython/rev/129105f8457d

New changeset 5e39c69bad21 by Serhiy Storchaka in branch 'default':
Issue #19912: Fixed numerous bugs in ntpath.splitunc().
http://hg.python.org/cpython/rev/5e39c69bad21

New changeset e4beb183a674 by Serhiy Storchaka in branch '2.7':
Issue #19912: Fixed numerous bugs in ntpath.splitunc().
http://hg.python.org/cpython/rev/e4beb183a674

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19912>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:26:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 13:26:19 +0000
Subject: [issue19911] ntpath.splitdrive() fails when UNC part contains \u0130
In-Reply-To: <1386353906.42.0.949556557512.issue19911@psf.upfronthosting.co.za>
Message-ID: <1387200379.92.0.345735176905.issue19911@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/issue19911>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:27:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 13:27:15 +0000
Subject: [issue19911] ntpath.splitdrive() fails when UNC part contains \u0130
In-Reply-To: <1386353906.42.0.949556557512.issue19911@psf.upfronthosting.co.za>
Message-ID: <1387200435.73.0.406440491783.issue19911@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19911>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:27:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 13:27:35 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
In-Reply-To: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>
Message-ID: <1387200455.2.0.269596677572.issue19912@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/issue19912>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:31:54 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Dec 2013 13:31:54 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387200714.75.0.408783971352.issue19996@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, having it hang forever is a potential DOS attack, so something needs to be fixed, I think.

----------
nosy: +christian.heimes, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:34:41 2013
From: report at bugs.python.org (Jim Carroll)
Date: Mon, 16 Dec 2013 13:34:41 +0000
Subject: [issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
Message-ID: <1387200881.03.0.963168965941.issue19998@psf.upfronthosting.co.za>


New submission from Jim Carroll:

When building Python 2.7.6 on older GCC 2.x, the _ctypes module fails to build. The failure is caused due to a header file reference to __builtin_expect (the author expected this to be available when the module was built with gcc, but did not take into account that this was not available in all versions of gcc).

The solution is a simple modification to the test in ffi_common.h

--- Modules/_ctypes/libffi/include/ffi_common.h Sun Nov 10 02:36:41 2013
+++ Modules/_ctypes/libffi/include/ffi_common.h.fix     Mon Dec 16 08:23:56 2013
@@ -115,7 +115,7 @@

 typedef float FLOAT32;

-#ifndef __GNUC__
+#if !defined(__GNUC__) || __GNUC__==2
 #define __builtin_expect(x, expected_value) (x)
 #endif
 #define LIKELY(x)    __builtin_expect(!!(x),1)

----------
components: Build
files: ffi_common.h.patch
keywords: patch
messages: 206307
nosy: jamercee
priority: normal
severity: normal
status: open
title: Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file33165/ffi_common.h.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19998>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:35:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 13:35:56 +0000
Subject: [issue17919] AIX POLLNVAL definition causes problems
In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za>
Message-ID: <1387200956.27.0.612278919635.issue17919@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Christian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:36:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 13:36:08 +0000
Subject: [issue18215] Script to test multiple versions of OpenSSL
In-Reply-To: <1371225642.81.0.592691190065.issue18215@psf.upfronthosting.co.za>
Message-ID: <3djk5g38hmz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset 7719efb182e3 by Christian Heimes in branch 'default':
Issue #18215: Add script Tools/ssl/test_multiple_versions.py to compile and
http://hg.python.org/cpython/rev/7719efb182e3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18215>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:36:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 13:36:38 +0000
Subject: [issue18215] Script to test multiple versions of OpenSSL
In-Reply-To: <1371225642.81.0.592691190065.issue18215@psf.upfronthosting.co.za>
Message-ID: <1387200998.7.0.039317540706.issue18215@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18215>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:43:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 13:43:46 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387201426.04.0.68883049423.issue19887@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I suppose that was some kind of joke, but what I meant was that we don't need to test with 100 levels of symlinks. 2 or 3 are enough...

Yes, sorry for this joke. Your tests LGTM, but why you repeat similar code 3-4 times instead using loops?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:52:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 13:52:23 +0000
Subject: [issue19537] Fix misalignment in fastsearch_memchr_1char
In-Reply-To: <1384014728.51.0.918202421473.issue19537@psf.upfronthosting.co.za>
Message-ID: <1387201943.68.0.265899356158.issue19537@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that adding __attribute__ ((aligned (sizeof(void *)))) to the PyObject type (or to the ob_base field) is enough.

If first byte of structure is aligned, then first byte past the structure should be aligned too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19537>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:54:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 13:54:33 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <3djkVw5wGCz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset 1824fa874f08 by Christian Heimes in branch 'default':
Issue #19987: disable test_winsound's test_alias_fallback test when no sound card
http://hg.python.org/cpython/rev/1824fa874f08

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 14:59:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 16 Dec 2013 13:59:24 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387202364.54.0.443901374303.issue19887@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

The patch passed on Windows Vista.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:09:27 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 16 Dec 2013 14:09:27 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387202967.13.0.495058649498.issue19987@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This is a little odd, since it seems that that buildbot doesn't have a sound card (according to _have_soundcard), but succeeded in playing a sound...although without an ear in the room, we have no way to tell if a sound was played or not.  I'm thinking it may be most sane to rewrite the test to call PlaySound in a `try: ... except RuntimeError:` block, and add a comment saying that either outcome is acceptable; a failure would be any other error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:12:44 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 14:12:44 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387203164.52.0.749194647303.issue19996@psf.upfronthosting.co.za>


Cory Benfield added the comment:

The easiest way to 'fix' the DoS problem is to throw an exception if an invalid header is parsed. That's a backwards-compatibility problem though: things that previously 'worked' now won't. That presumably limits the ability to back-apply this fix to 2.7.7.

An alternative option is to speculatively attempt to parse the next line for headers or the end of the header block. I'm not sure this is a great idea: at this stage all we know is that the header block is malformed, so it's not clear that 'doing our best' is a good idea either, especially since that attitude got us here to begin with.

The best 'middle of the road' option is to abort message parsing at this stage without throwing an exception. This leads to truncated headers and no body, where previously we'd have got truncated headers and a body that potentially included the missing headers. We could also potentially add a warning about the problem.

Are there any preferences for a fix here, or a better solution than the above (none of which I'm wild about)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:22:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 14:22:38 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387203758.56.0.505077112601.issue19987@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Zach, that sounds like a really good plan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:29:57 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 16 Dec 2013 14:29:57 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387204197.48.0.771008942331.issue19987@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'll get it committed shortly, thanks Christian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:30:07 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 16 Dec 2013 14:30:07 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387204207.38.0.667209154307.issue19987@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 15:35:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Dec 2013 14:35:38 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387204538.18.0.537045632301.issue19996@psf.upfronthosting.co.za>


R. David Murray added the comment:

I haven't looked at the code, but could we preserve the existing behavior but apply a timeout to mitigate the DOS?

On the other hand, the fact that curl manages to return something indicates there is probably an error recovery strategy that would work.  I'm not sure if we have an error reporting mechanism in httplib if we do error recovery.  We do in the email module, and httplib uses the email code for headers, I think, so there might be a way to leverage that if there is no existing mechanism.  But of course even deciding to do that requires some discussion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:05:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 15:05:53 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <3djm5D6TZXz7Lk3@mail.python.org>


Roundup Robot added the comment:

New changeset f590e9aeb990 by Zachary Ware in branch '2.7':
Issue #19987: Re-write test_alias_fallback in test_winsound to have two
http://hg.python.org/cpython/rev/f590e9aeb990

New changeset 5455456945d4 by Zachary Ware in branch '3.3':
Issue #19987: Re-write test_alias_fallback in test_winsound to have two
http://hg.python.org/cpython/rev/5455456945d4

New changeset 1aa6751b298f by Zachary Ware in branch 'default':
Issue #19987: Merge with 3.3
http://hg.python.org/cpython/rev/1aa6751b298f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:08:58 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Dec 2013 15:08:58 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387206538.04.0.0715879463101.issue19996@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/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:16:49 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 15:16:49 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387207009.23.0.842589492686.issue19996@psf.upfronthosting.co.za>


Cory Benfield added the comment:

Maybe. If we do it we have to apply that timeout to all the socket actions on that HTTP connection. This would have the effect of changing the default value of the timeout parameter on the HTTPConnection object from socket._GLOBAL_DEFAULT_TIMEOUT to whatever value was chosen. We could do this for reads only, and avoid applying the timeout to connect() calls, but that's kind of weird.

We hit the same problem though: by default, HTTPConnections block indefinitely on all socket calls: we'd be changing that default to some finite timeout instead. Does that sound like a good way to go?

As for curl's error recovery strategy, I'm pretty sure it just keeps parsing the header block. That can definitely be done here. We do have an error reporting mechanism as well (sort of): we set the HTTPMessage.status field to some error string. We could do that, and continue to parse the header block: that's probably the least destructive way to fix this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:42:10 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 15:42:10 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387208530.39.0.478755317431.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Victor Stinner commented:
-------------------------
> I never understood the difference between "long" (__int__ method)
> and "index" (__index__ method). Is the difference on the behaviour
> of floating point numbers?

__index__ was originally added so that non-int integers, such as NumPy's int16, int32, etc, integer types could be used as indices and slices.

Now it means "if your type can produce a lossless integer, use __index__", which is why float and similar types don't define it.

The current meaning is unfortunate in that it is possible to want a type that can be used as an index or slice but that is still not a number, and in fact won't be used as a number in any scenario _except_ bin(), hex(), and oct().

It seems to me that by having those three functions check that the argument is a number, and bailing if it is not, is a decent way to ensure consistency.

One question I do have, since I don't have NumPy installed, is what happens with:

  --> "NumPy's int's work here? %x" % uint16(7)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:46:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 15:46:59 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387208819.06.0.0916333562077.issue19995@psf.upfronthosting.co.za>


STINNER Victor added the comment:

$ python
Python 2.7.5 (default, Nov 12 2013, 16:18:42) 
>>> import numpy
>>> hex(numpy.uint16(257))
'0x101'
>>> "%x" % numpy.uint16(257)
'101'
>>> x=numpy.uint16(257)
>>> x.__int__()
257
>>> x.__index__()
257

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 16:49:00 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Dec 2013 15:49:00 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387208530.39.0.478755317431.issue19995@psf.upfronthosting.co.za>
Message-ID: <20131216154859.GA10578@sleipnir.bytereef.org>


Stefan Krah added the comment:

Ethan Furman <report at bugs.python.org> wrote:
> The current meaning is unfortunate in that it is possible to want a type that
> can be used as an index or slice but that is still not a number, and in fact
> won't be used as a number in any scenario _except_ bin(), hex(), and oct().

memoryview, struct and probably also array.array accept __index__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:00:59 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 16:00:59 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387209659.99.0.89294447009.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Did I mention __index__ is an unfortunate name for the current trend for this method?

Stefan Krah commented:
----------------------
> memoryview, struct and probably also array.array accept __index__.

When you say "accept __index__" do you mean for use as indices, or for use as values in the data structure itself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:17:58 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Dec 2013 16:17:58 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387209659.99.0.89294447009.issue19995@psf.upfronthosting.co.za>
Message-ID: <20131216161756.GA12598@sleipnir.bytereef.org>


Stefan Krah added the comment:

> Did I mention __index__ is an unfortunate name for the current trend for this method?

Yes, but it's probably too late to change that now.  Also, a fully precise
name would be something like:

  __to_int_exact_iff_object_has_integer_nature__ :)

> When you say "accept __index__" do you mean for use as indices, or for use as
> values in the data structure itself?

The latter, see Lib/test/test_buffer.py:2489 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:24:47 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Dec 2013 16:24:47 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
In-Reply-To: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>
Message-ID: <1387211087.53.0.197260423845.issue19912@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Hi Serhiy, there are commented-out lines in changeset http://hg.python.org/cpython/rev/e4beb183a674. Are they intentionally there?

+    #if p[1:2] == ':':
+        #return '', p # Drive letter present
+    #firstTwo = p[0:2]
+    #if firstTwo == '//' or firstTwo == '\\\\':
+        ## is a UNC path:
+        ## vvvvvvvvvvvvvvvvvvvv equivalent to drive letter
+        ## \\machine\mountpoint\directories...
+        ##           directory ^^^^^^^^^^^^^^^
+        #normp = normcase(p)
+        #index = normp.find('\\', 2)
+        #if index == -1:
+            ###raise RuntimeError, 'illegal UNC path: "' + p + '"'
+            #return ("", p)
+        #index = normp.find('\\', index + 1)
+        #if index == -1:
+            #index = len(p)
+        #return p[:index], p[index:]
+    #return '', p

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19912>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:43:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 16:43:51 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
In-Reply-To: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>
Message-ID: <3djpGG40qwz7Lk3@mail.python.org>


Roundup Robot added the comment:

New changeset 4de09cbd3b97 by Serhiy Storchaka in branch '2.7':
Removed old implementation of ntpath.splitunc() (issue #19912).
http://hg.python.org/cpython/rev/4de09cbd3b97

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19912>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:45:06 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 16 Dec 2013 16:45:06 +0000
Subject: [issue19994] re.match does not return or takes long time
In-Reply-To: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>
Message-ID: <1387212306.44.0.859838889603.issue19994@psf.upfronthosting.co.za>


Tim Peters added the comment:

It will always complete, but may take a very long time - this is one of many ways to write a regexp that can't match requiring time exponential in the length of the string.  It's not a bug - it's the way Python's kind of regexp engine works.  For detailed explanation, see Jeffrey Friedl's book "Mastering Regular Expressions":

http://www.amazon.com/Mastering-Regular-Expressions-Jeffrey-Friedl/dp/0596528124

----------
nosy: +tim.peters
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19994>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:47:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 16:47:54 +0000
Subject: [issue19912] ntpath.splitunc() is broken and not tested
In-Reply-To: <1386356571.53.0.00350504550121.issue19912@psf.upfronthosting.co.za>
Message-ID: <1387212474.22.0.0983353955901.issue19912@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, my fault. Thank you Berker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19912>
_______________________________________

From report at bugs.python.org  Mon Dec 16 17:52:22 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 16:52:22 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387212742.8.0.489754302342.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Hmmm...

Well, much as I hate to say it, it's sounding like the correct solution here is to have %o and %x work when __index__ is available, instead of the other way around.  :(

.format is not an issue because one must specify one's own if inheriting from object.

So the complete list of spcecifiers then is d, i, o, u, U, and c [1], and they should work if __index__ works.

Are we in agreement?


[1] http://docs.python.org/dev/library/stdtypes.html#printf-style-string-formatting

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:11:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 17:11:41 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387212742.8.0.489754302342.issue19995@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZp0UOjDOJGU8U+7+hY-UjJHmthNgjdT-v0-hy53mBD4g@mail.gmail.com>


STINNER Victor added the comment:

> Are we in agreement?

Start maybe on writing unit tests :-)

IMO all int-like objects should behave the same. I don't see any good
reason why hex(value) would succeed whereas "%x" % value fails. Both
should succeed (or both should fail).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:16:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 17:16:13 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <20131216161756.GA12598@sleipnir.bytereef.org>
Message-ID: <4420492.PjgdSlPve1@raxxla>


Serhiy Storchaka added the comment:

> > Did I mention __index__ is an unfortunate name for the current trend for
> > this method?
> Yes, but it's probably too late to change that now.  Also, a fully precise
> name would be something like:
> 
>   __to_int_exact_iff_object_has_integer_nature__ :)

Perhaps in future (may be in 4.0) __index__ should be renamed to __int__ and 
__int__ to __trunc__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:25:37 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 16 Dec 2013 17:25:37 +0000
Subject: [issue19993] Pool.imap doesn't work as advertised
In-Reply-To: <1387182676.04.0.471976296284.issue19993@psf.upfronthosting.co.za>
Message-ID: <1387214737.38.0.685132557079.issue19993@psf.upfronthosting.co.za>


Tim Peters added the comment:

Nice to see you, Jurjen!  Been a long time :-)

I'd like to see changes here too.  It's unclear what "a lazy version"  is intended to mean, exactly, but I agree the actual behavior is surprising, and that mpool.py is a lot less surprising in several ways.

I got bitten by this just last week, when running a parallelized search over a massive space _expected_ to succeed after exploring a tiny fraction of the search space.  Ran out of system resources because imap_unordered() tried to queue up countless millions of work descriptions.  I had hoped/expected that it would interleave generating and queue'ing "a few" inputs with retrieving outputs, much as mpool.py behaves.

In that case I switched to using apply_async() instead, interposing my own bounded queue (a collections.deque used only in the main program) to throttle the main program.  I'm still surprised it was necessary ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19993>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:43:23 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 16 Dec 2013 17:43:23 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387215803.71.0.685860318628.issue19987@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The revised test passes on that buildbot on 3.3 and 3.x; the 2.7 build is having permissions issues (and seems to have been for some time).  Closing the issue.

Thanks for pointing it out and approving the rewrite, Christian!

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 18:58:04 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 16 Dec 2013 17:58:04 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387216684.62.0.955787230195.issue19995@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Yes, I think adding __index__ to d, i, o, u, U, and c is the correct thing to do here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:03:41 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:03:41 +0000
Subject: [issue19987] Winsound: test_alias_fallback fails on WS 2008
In-Reply-To: <1387123531.4.0.00419061279512.issue19987@psf.upfronthosting.co.za>
Message-ID: <1387217021.67.0.654086932055.issue19987@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Awesome! Thanks a lot! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19987>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:18:04 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Dec 2013 18:18:04 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387217884.63.0.891297188072.issue19995@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Not so fast.  Currently, even in Python 3, '%d' % 3.14 returns '3'.  "Fixing" this will likely break a huge amount of code.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:22:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 16 Dec 2013 18:22:21 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387218141.89.0.455741110519.issue19995@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Also (the tracker email interface swallowed this):

> it is possible to want a type that can be used as an index or slice but that is still not a number

I'm sorry, but this requirement is absurd. An index *is* a number. You
have to make up your mind. (I know, in the context of the example that
started this, this is funny, but I still stand by it.)

---

Finally, the correct name should perhaps have been __integer__ but I don't see enough reason to change it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:25:18 2013
From: report at bugs.python.org (David Palms)
Date: Mon, 16 Dec 2013 18:25:18 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1387218318.42.0.251380860497.issue7980@psf.upfronthosting.co.za>


David Palms added the comment:

I am still seeing this in 2.7.5, has a patch been created yet?

----------
nosy: +dpalms2011

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:34:18 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 16 Dec 2013 18:34:18 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387218858.16.0.975875960435.issue19995@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

If you were going to make this change, I'd think you'd have to look for __index__ and then __int__. But I'll admit I haven't thought through all of the ramifications. It would be interesting to see what tests would break.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:38:14 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:38:14 +0000
Subject: [issue16733] Solaris ctypes_test failures
In-Reply-To: <1355959487.2.0.457059136813.issue16733@psf.upfronthosting.co.za>
Message-ID: <1387219094.4.0.456064925444.issue16733@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The ctypes issue also affects test_uuid. #19045 is a duplicate of this bug, too.

======================================================================
FAIL: test_ints (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/ctypes/test/test_bitfields.py", line 40, in test_ints
    self.assertEqual(getattr(b, name), func(byref(b), name.encode('ascii')))
AssertionError: -1 != 1

======================================================================
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/ctypes/test/test_bitfields.py", line 47, in test_shorts
    self.assertEqual(getattr(b, name), func(byref(b), name.encode('ascii')))
AssertionError: -32 != 32

======================================================================
FAIL: test_uuid4 (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/3.x.snakebite-solaris11-amd64/build/Lib/test/test_uuid.py", line 441, in test_uuid4
    equal(u.variant, uuid.RFC_4122)
AssertionError: 'reserved for Microsoft compatibility' != 'specified in RFC 4122'
- reserved for Microsoft compatibility
+ specified in RFC 4122

----------
nosy: +christian.heimes
versions: +Python 3.4 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16733>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:39:13 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:39:13 +0000
Subject: [issue19045] Make on Solaris 11 x64 with OracleStudio12.3 failed
In-Reply-To: <1379574179.05.0.180767783928.issue19045@psf.upfronthosting.co.za>
Message-ID: <1387219153.73.0.32173407591.issue19045@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks for the report. This is a duplicate of issue #16733. I'm closing this bug as duplicated.

----------
nosy: +christian.heimes
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19045>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:46:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:46:58 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
Message-ID: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I have seen this failure multiple times.

http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/7353/steps/test/logs/stdio

======================================================================
FAIL: test_monotonic (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_time.py", line 387, in test_monotonic
    self.assertAlmostEqual(dt, 0.5, delta=0.2)
AssertionError: 0.8012567944824696 != 0.5 within 0.2 delta

----------------------------------------------------------------------

----------
assignee: haypo
components: Tests
keywords: buildbot
messages: 206344
nosy: christian.heimes, haypo
priority: low
severity: normal
stage: test needed
status: open
title: test_monotonic fails on x86 OpenIndiana
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:49:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 18:49:01 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387219741.32.0.643860035718.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> why you repeat similar code 3-4 times instead using loops?

For no real reason :) I'll try with a loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:53:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 18:53:21 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387220001.96.0.691075282521.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, I remember. Using subtests would make it more annoying to backport to 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:53:51 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 18:53:51 +0000
Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs
Message-ID: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The new method SSLContext.get_ca_certs() returns all certificates in the context's trusted X509_STORE. I recently found out that it is possible to put a self-signed certificate into the store and use it successfully with verify_mode CERT_REQUIRED. get_ca_certs() doesn't return the cert although it is used to successfully validate a remote cert.

I propose to modify and rename the function and to add a "check_ca" to the dict that is returned by getpeercert().

----------
components: Extension Modules
messages: 206347
nosy: christian.heimes
priority: normal
severity: normal
stage: test needed
status: open
title: SSLContext.get_ca_certs() and self-signed certs
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20000>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:57:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 18:57:50 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <3djsDq3pVnz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 12a52186b4fd by Antoine Pitrou in branch 'default':
Issue #19887: Improve the Path.resolve() algorithm to support certain symlink chains.
http://hg.python.org/cpython/rev/12a52186b4fd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 19:58:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 18:58:29 +0000
Subject: [issue19887] Path.resolve() fails on complex symlinks
In-Reply-To: <1386190005.89.0.0350896340322.issue19887@psf.upfronthosting.co.za>
Message-ID: <1387220309.24.0.745724654361.issue19887@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks a lot for the patch!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19887>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:13:00 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 19:13:00 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387221180.54.0.424720333471.issue19996@psf.upfronthosting.co.za>


Cory Benfield added the comment:

An update: in Python 2.7 through 3.3, fixing this should only affect http.client/httplib, because they do most of their header parsing themselves. Fixing this in later versions of Python is more interesting, as http.client got rewritten to use email.parser (which uses email.feedparser). This means any change to fix this problem in HTTP will also affect anything else that uses this module. Not sure how problematic that is yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:13:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 19:13:58 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1387221238.94.0.863473924458.issue19921@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note that the description of the POSIX mkdir utility (*) has something a bit more complex to say about the `-p` option. Instead of simply applying the default umask, it computes """(S_IWUSR|S_IXUSR|~filemask)&0777 as the mode argument, where filemask is the file mode creation mask of the process (see XSH umask)""".

But unless the umask has a pathological value (such as 0o333), it doesn't really matter. The main point is that the original mode argument is ignored.

(*) http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:14:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 19:14:08 +0000
Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs
In-Reply-To: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za>
Message-ID: <1387221248.69.0.21130005011.issue20000@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Example:

$ openssl s_server -cert Lib/test/ssl_cert.pem -key Lib/test/ssl_key.pem

$ ./python
>>> import ssl
>>> ctx = ssl.SSLContext(ssl.PROTOCOL_SSLv3)
>>> ctx.verify_mode = ssl.CERT_REQUIRED
>>> ctx.check_hostname = True
>>> ctx.load_verify_locations("Lib/test/ssl_cert.pem")
>>> s = ssl.create_connection(("localhost", 4433))
>>> with ctx.wrap_socket(s, server_hostname="localhost") as ssock:
...     peer = ssock.getpeercert()
... 
>>> peer
{'notAfter': 'Oct  5 23:01:56 2020 GMT', 'version': 3, 'serialNumber': 'D7C7381919AFC24E', 'subjectAltName': (('DNS', 'localhost'),), 'issuer': ((('countryName', 'XY'),), (('localityName', 'Castle Anthrax'),), (('organizationName', 'Python Software Foundation'),), (('commonName', 'localhost'),)), 'subject': ((('countryName', 'XY'),), (('localityName', 'Castle Anthrax'),), (('organizationName', 'Python Software Foundation'),), (('commonName', 'localhost'),)), 'notBefore': 'Oct  8 23:01:56 2010 GMT'}
>>> ctx.get_ca_certs()
[]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20000>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:18:11 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 19:18:11 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387221491.76.0.0742279685532.issue19996@psf.upfronthosting.co.za>


Cory Benfield added the comment:

Actually, that might be OK. I don't know the email package at all, but I suspect being able to handle empty header keys (by ignoring them) is a reasonable thing to do in the email case as well. Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:18:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 19:18:58 +0000
Subject: [issue20001] pathlib inheritance diagram too large
Message-ID: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The inheritance diagram at http://docs.python.org/dev/library/pathlib.html is too large, it can easily take up half the vertical space (or perhaps all of it on a smaller screen).

The font size looks fine, it's just that there's a lot of spacing around.
(of course, the style could perhaps also be changed or improved)

----------
assignee: docs at python
components: Documentation
messages: 206354
nosy: docs at python, eli.bendersky, georg.brandl, pitrou
priority: low
severity: normal
status: open
title: pathlib inheritance diagram too large
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20001>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:22:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 19:22:44 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <3djsnZ6Rtqz7LlG@mail.python.org>


Roundup Robot added the comment:

New changeset 87b81b7df7f0 by Antoine Pitrou in branch 'default':
Issue #19921: When Path.mkdir() is called with parents=True, any missing parent is created with the default permissions, ignoring the mode argument (mimicking the POSIX "mkdir -p" command).
http://hg.python.org/cpython/rev/87b81b7df7f0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:23:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 19:23:18 +0000
Subject: [issue19921] Path.mkdir(0, True) always fails
In-Reply-To: <1386441358.84.0.105181081607.issue19921@psf.upfronthosting.co.za>
Message-ID: <1387221798.4.0.416928817151.issue19921@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19921>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:28:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 19:28:37 +0000
Subject: [issue19930] os.makedirs('dir1/dir2', 0) always fails
In-Reply-To: <1386500945.84.0.693179822476.issue19930@psf.upfronthosting.co.za>
Message-ID: <1387222117.75.0.418559495014.issue19930@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19930>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:41:53 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 16 Dec 2013 19:41:53 +0000
Subject: [issue19993] Pool.imap doesn't work as advertised
In-Reply-To: <1387182676.04.0.471976296284.issue19993@psf.upfronthosting.co.za>
Message-ID: <1387222913.11.0.348884596404.issue19993@psf.upfronthosting.co.za>


Tim Peters added the comment:

Just for interest, I'll attach the worm-around I mentioned (imu.py).  At this level it's a very simple implementation, but now that I look at it, it's actually a lazy implementation of imap() (or of an unimaginative ;-) imap_unordered()).

----------
Added file: http://bugs.python.org/file33166/imu.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19993>
_______________________________________

From report at bugs.python.org  Mon Dec 16 20:49:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 19:49:50 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
Message-ID: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which contains many small cleanups and optimizations for the pathlib module. Not all of them can be backported to 2.7 version.

----------
assignee: pitrou
components: Library (Lib)
files: pathlib_cleanup.patch
keywords: patch
messages: 206357
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Cleanup and microoptimize pathlib
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33167/pathlib_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:06:25 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 20:06:25 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1387224385.38.0.28103065977.issue19919@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file33168/issue19919.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:10:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 20:10:32 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1387224632.82.0.721978129017.issue19919@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Looks fine to me.

----------
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:14:01 2013
From: report at bugs.python.org (Cory Benfield)
Date: Mon, 16 Dec 2013 20:14:01 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387224841.24.0.385820722651.issue19996@psf.upfronthosting.co.za>


Cory Benfield added the comment:

Alright, here's a patch for the current tip. I'll need to prepare a different patch for earlier versions of Python, which will take me a little while longer to do (maybe not today). I've also signed a contributor agreement, but it doesn't look like that's propagated here yet.

----------
keywords: +patch
Added file: http://bugs.python.org/file33169/hdrs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:17:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 20:17:13 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <3djv0S400szLrY@mail.python.org>


Roundup Robot added the comment:

New changeset 40955ae17472 by Christian Heimes in branch '3.3':
Issue #19919: Fix flacky SSL test. connect_ex() sometimes returns
http://hg.python.org/cpython/rev/40955ae17472

New changeset 593c3fa7aa2c by Christian Heimes in branch 'default':
Issue #19919: Fix flacky SSL test. connect_ex() sometimes returns
http://hg.python.org/cpython/rev/593c3fa7aa2c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:17:45 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 16 Dec 2013 20:17:45 +0000
Subject: [issue19919] SSL: test_connect_ex_error fails with EWOULDBLOCK
In-Reply-To: <1386434917.9.0.425282577519.issue19919@psf.upfronthosting.co.za>
Message-ID: <1387225065.07.0.963358450244.issue19919@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19919>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:20:58 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 20:20:58 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387225258.45.0.362221043763.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Eric V. Smith commented:
------------------------
> If you were going to make this change, I'd think you'd have to look
> for __index__ and then __int__.

Does the order matter?  Are there any types (and should there be) that would have both and return different answers for each?

If not, pick an order, try one and, if that one fails, try the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:24:40 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 20:24:40 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387225480.7.0.86235392571.issue19995@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I'm with Guido: it doesn't really make sense to allow __index__ but not __int__ on a type. So trying __index__ in str.format() sounds like a distraction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:26:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 20:26:56 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>
Message-ID: <1387225616.38.0.844154706094.issue20002@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, since it makes backporting more tedious, I'd rather keep this for post-3.4.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:28:29 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Dec 2013 20:28:29 +0000
Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs
In-Reply-To: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za>
Message-ID: <1387225709.32.0.336510822562.issue20000@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/issue20000>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:38:19 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Dec 2013 20:38:19 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387226299.98.0.216810783856.issue19995@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/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:47:28 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Dec 2013 20:47:28 +0000
Subject: [issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
In-Reply-To: <1387200881.03.0.963168965941.issue19998@psf.upfronthosting.co.za>
Message-ID: <1387226848.71.0.382284468724.issue19998@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Modules/_ctypes/libffi directory contains a copy of externally maintained libffi library. Please report problem to libffi maintainers:
https://github.com/atgreen/libffi

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19998>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:48:46 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 20:48:46 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387226926.53.0.777939040208.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Antoine Pitrou opined:
----------------------
> I'm with Guido: it doesn't really make sense to allow __index__ but not __int__ on
> a type. So trying __index__ in str.format() sounds like a distraction.

  --> hex(3.14)  # calls __index__
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: 'float' object cannot be interpreted as an integer

  --> '%x' % 3.14  # calls __int__
  '3'

One of those behaviours is wrong.  Which?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 21:50:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 20:50:18 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387226926.53.0.777939040208.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387227016.2303.1.camel@fsol>


Antoine Pitrou added the comment:

>   --> '%x' % 3.14  # calls __int__
>   '3'
> 
> One of those behaviours is wrong.  Which?

For '%x' and '%o', it probably doesn't make sense to convert the float
to an int.
(however, it does make sense for other formatters, such as '%d')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:14:35 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 21:14:35 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387228475.76.0.486748687513.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Ethan Furman previously stated:
-------------------------------
> So the complete list of spcecifiers then is d, i, o, u, U, and c [1], and they
> should work if __index__ works.

Okay, so 'd' then should be considered a conversion operation, whilst the others should only work if the object is actually an integer type (which is implied by specifying __index__).

In other words

  - if %d or %u is specified, try __int__, then __index__
    (according to the docs, u is obsolete and identical to d)

  - if %i, %o, %x, %X, or %c is specified, try only __index__

Agreed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:23:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 21:23:53 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <1387229033.4.0.68621095304.issue18283@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

All low-level functions in the os.path module supports string and bytes paths. But not all high-level functions in the shutil module supports bytes paths. Adding support for bytes paths will complicate implementation and tests.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:26:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 21:26:27 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387228475.76.0.486748687513.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387229184.2303.3.camel@fsol>


Antoine Pitrou added the comment:

> In other words
> 
>   - if %d or %u is specified, try __int__, then __index__
>     (according to the docs, u is obsolete and identical to d)

Again, I don't think trying __index__ is useful.

>   - if %i, %o, %x, %X, or %c is specified, try only __index__

I think everything yielding a decimal output should work with floats
(i.e. %i too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:39:24 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 21:39:24 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <3djwqH0KzHz7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 4864c0b914ae by Victor Stinner in branch '3.3':
Close #19999: tolerate coarse time when testing time.monotonic() on very
http://hg.python.org/cpython/rev/4864c0b914ae

New changeset a34582c53911 by Victor Stinner in branch 'default':
(Merge 3.3) Close #19999: tolerate coarse time when testing time.monotonic() on
http://hg.python.org/cpython/rev/a34582c53911

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:46:36 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 21:46:36 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <1387230396.05.0.448342826576.issue18283@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Almost all functions of the shutil module support bytes filenames. I tested shutil.copyfile(), shutil.ignore_patterns(), shutil.copytree(), shutil.rmtree() and shutil.move().

I only found one function which only support Unicode filenames: shutil.make_archive().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:49:11 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Dec 2013 21:49:11 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <3djx2X60LBz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset a1a05e2724dd by Victor Stinner in branch 'default':
Issue #18283: shutil.which() now supports bytes argument, not only text argument.
http://hg.python.org/cpython/rev/a1a05e2724dd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:49:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 21:49:27 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387223389.48.0.793135130447.issue20002@psf.upfronthosting.co.za>
Message-ID: <1387230567.64.0.0447342599401.issue20002@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is compatible with 2.7 part of the patch. It is important to apply it before 3.4 release otherwise supporting different versions will be more tedious.

----------
Added file: http://bugs.python.org/file33170/pathlib_cleanup_compatible.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:50:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 21:50:31 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387230567.64.0.0447342599401.issue20002@psf.upfronthosting.co.za>
Message-ID: <1387230629.2303.4.camel@fsol>


Antoine Pitrou added the comment:

> Here is compatible with 2.7 part of the patch. It is important to
> apply it before 3.4 release otherwise supporting different versions
> will be more tedious.

Do you have performance numbers that show a significant improvement?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Mon Dec 16 22:54:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 21:54:30 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <1387230870.12.0.936199379065.issue18283@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:06:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 22:06:59 +0000
Subject: [issue20002] Cleanup and microoptimize pathlib
In-Reply-To: <1387230629.2303.4.camel@fsol>
Message-ID: <2764023.f6NhJqq1Xr@raxxla>


Serhiy Storchaka added the comment:

> Do you have performance numbers that show a significant improvement?

No. The benefit is too small (but theoretically it should be). Some changes 
also simplify the code. This is why this patch should be applied now, while 
pathlib code is not frozen yet.

For example "drv or root" replaced by "root or drv" because drv is always 
false on Unix and both arguments of "or" should be evaluated. This is very 
tiny optimization, but it has zero cos if apply it right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20002>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:11:08 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 22:11:08 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387231868.3.0.713551062632.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Antoine, if I understand you correctly, you are saying that any type that defines __index__ is an integer, and should therefore also define __int__, in which case Python can just use __int__ and not worry about __index__?

Here's the problem with that:

  --> '%x' % 3.14
  '3'

While I am beginning to agree that an integer type needs to implement both __int__ and __index__, it still remains true that Python needs to call __index__ if what it needs is already a real, true int, and not just something that can be truncated or otherwise converted into an int -- such as float.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:15:20 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 22:15:20 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387231868.3.0.713551062632.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387232118.2303.5.camel@fsol>


Antoine Pitrou added the comment:

> Antoine, if I understand you correctly, you are saying that any type
> that defines __index__ is an integer, and should therefore also define
> __int__, in which case Python can just use __int__ and not worry about
> __index__?

... is an integer-like, yes.

> While I am beginning to agree that an integer type needs to implement
> both __int__ and __index__, it still remains true that Python needs to
> call __index__ if what it needs is already a real, true int, and not
> just something that can be truncated or otherwise converted into an
> int -- such as float.

Of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:22:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 22:22:21 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387232541.54.0.752666041005.issue19999@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, there is something wrong with this buildbot!

http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.3/builds/1266/steps/test/logs/stdio

======================================================================
FAIL: test_monotonic (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.3.cea-indiana-x86/build/Lib/test/test_time.py", line 379, in test_monotonic
    self.assertTrue(0.5 <= dt <= 1.0, dt)
AssertionError: False is not true : 2.2977897822856903

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:22:52 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Dec 2013 22:22:52 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <1387232572.51.0.315907165422.issue18283@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
stage:  -> committed/rejected
versions: +Python 3.4 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:23:41 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Dec 2013 22:23:41 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387232621.89.0.594653034495.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Antoine,

Does that mean you are reducing your previous statement of

> So trying __index__ in str.format() sounds like a distraction.

to "using __index__ for %d, %i, and %u is not correct, but is correct for %c, %o, %x, and %X" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:24:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Dec 2013 22:24:33 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387232621.89.0.594653034495.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387232671.2303.6.camel@fsol>


Antoine Pitrou added the comment:

> Antoine,
> 
> Does that mean you are reducing your previous statement of
> 
> > So trying __index__ in str.format() sounds like a distraction.
> 
> to "using __index__ for %d, %i, and %u is not correct, but is correct
> for %c, %o, %x, and %X" ?

Ah, yes, sorry for the confusion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:28:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Dec 2013 22:28:05 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387232885.45.0.0296207912961.issue19995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In addition, PyLong_AsLong() calls __int__, while PyLong_AsUnsignedLong() doesn't call __int__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:28:29 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 16 Dec 2013 22:28:29 +0000
Subject: [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <1387232909.92.0.481488619726.issue20001@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

The source for the diagram is here: https://docs.google.com/drawings/d/1F8do-1WL1sIGkZuiufcxcpZRtS0w4SwAowq-Uamrwt8/edit?usp=sharing

Anyone - feel free to copy that doc over and create a new diagram with smaller whitespacing. Let me know if there are any problem accessing the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20001>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:29:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 22:29:30 +0000
Subject: [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <1387232970.28.0.756240520574.issue20001@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Please include the SVG source of the diagram in the Python source code, so the picture can be regenerated.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20001>
_______________________________________

From report at bugs.python.org  Mon Dec 16 23:40:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 22:40:52 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <1387233652.76.0.941650545241.issue18283@psf.upfronthosting.co.za>


STINNER Victor added the comment:

which_bytes.patch does not work on Windows.

According to Serhiy, it's a new feature and so should wait for Python 3.5.

----------
resolution: fixed -> 
status: closed -> open
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:10:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:10:58 +0000
Subject: [issue16286] Use hash if available to optimize a==b and a!=b for
 bytes and str
In-Reply-To: <1350650166.87.0.27478619259.issue16286@psf.upfronthosting.co.za>
Message-ID: <1387235458.39.0.964176223999.issue16286@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If it's hard to see a real speedup, it's probably not interesting to use the hash in string comparison.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16286>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:12:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:12:27 +0000
Subject: [issue18227] Use Python memory allocators in external libraries like
 zlib or OpenSSL
In-Reply-To: <1371338869.58.0.00725626403199.issue18227@psf.upfronthosting.co.za>
Message-ID: <1387235547.3.0.827526601467.issue18227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I modified modules when it was possible and easy to do. More modules should be modified, but it's more tricky. If you are interested, please open new issues.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18227>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:14:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:14:32 +0000
Subject: [issue18421] Refactor call_with_frame() function of pyexpat.c
In-Reply-To: <1373456756.74.0.870039145452.issue18421@psf.upfronthosting.co.za>
Message-ID: <1387235672.66.0.855959730847.issue18421@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not really interested to refactory pyexpat.c code. If you are interested, open a new the issue with a patch.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18421>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:19:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:19:20 +0000
Subject: [issue18733] elementtree: stop the parser more quickly on error
In-Reply-To: <1376438300.88.0.235284556503.issue18733@psf.upfronthosting.co.za>
Message-ID: <1387235960.11.0.0445467516681.issue18733@psf.upfronthosting.co.za>


STINNER Victor added the comment:

No reaction from Fred Drake, I don't know how to implement it and I'm no more interested to optimize this case, so I'm closing the issue.

Reopen it with a patch if you are interested to work on it.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18733>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:19:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:19:57 +0000
Subject: [issue19229] operator.py: move the Python implementation in the else
 block of try/except ImportError
In-Reply-To: <1381535351.94.0.0685942795619.issue19229@psf.upfronthosting.co.za>
Message-ID: <1387235997.36.0.611434908697.issue19229@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19229>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:22:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:22:20 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387236140.4.0.329127110329.issue19518@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, but because of the bikeshedding, I'm not more interested to work on this issue. Don't hesitate to re-work my patch if you want to fix the bug ("On Windows, these changes should allow to pass an unencodable filename on the command line").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 00:22:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Dec 2013 23:22:32 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387236152.25.0.595075763383.issue19518@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/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 02:50:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2013 01:50:45 +0000
Subject: [issue13024] cgitb uses stdout encoding
In-Reply-To: <1316559729.08.0.724028142076.issue13024@psf.upfronthosting.co.za>
Message-ID: <1387245045.01.0.243328687145.issue13024@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13024>
_______________________________________

From report at bugs.python.org  Tue Dec 17 02:52:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2013 01:52:17 +0000
Subject: [issue12263] punycode codec ignores the error handler argument
In-Reply-To: <1307229378.45.0.142684435058.issue12263@psf.upfronthosting.co.za>
Message-ID: <1387245137.27.0.0770956462431.issue12263@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I prefer to not touch punycode right now, it works, there is no need to modify it.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12263>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:11:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 02:11:43 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1387246302.96.0.662975436632.issue7980@psf.upfronthosting.co.za>


R. David Murray added the comment:

There's no patch posted here, and the issue is still open, so no.

On the other hand, the way imports are handled in 3.3 and later is a bit different, and if I run the unit test (which does still fail for me on 2.7 tip) on 3.3 and 3.4 tip it passes.

Given that, I'm guessing it is likely that none of the current Python committers are going to have time to look in to this, so unless someone else comes up with a patch, it isn't likely to get fixed in 2.7.

----------
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:17:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 17 Dec 2013 02:17:19 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>
Message-ID: <1387246639.22.0.299457623722.issue19997@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Why limit to str and bytes. Open can accept integer as well. I am asking not suggesting.

>>> with open('/tmp/cutecat.txt', 'wb') as f:
...   f.write(b'cutecat')
... 
7
>>> a = open('/tmp/cutecat.txt')
>>> a.fileno()
3
>>> b = open(3)
>>> b.read()
'cutecat'

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:17:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 02:17:49 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387246669.61.0.688878748796.issue19996@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh.  A missing header *name* was something I never considered in the email package tests.  So yeah, that's worth handing one way or another.  I'll put reviewing this on my TODO list, since I'm the maintainer of the email package.

I'm updating the versions per our usual practice: the versions in which we want to fix it.

----------
components: +email
nosy: +barry
versions: +Python 3.4 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:50:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 02:50:48 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387248648.11.0.865102040048.issue19518@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Just getting this on Larry's radar and summarising the current position.

The original problem: using "char *" to pass filenames around doesn't work properly on Windows, we need to use Unicode objects.

The solution: parallel APIs that accept PyObject * rather than char * for the filename parameters.

The new problem: both Serhiy and I find the *Object() suffix currently used for those "filename as Unicode object instead of C string" parallel APIs to be ambiguous and confusing. However, the problem the parallel APIs solve is real, and reverting or excessively modifying any of the work Victor has already done would be silly.

That means we're now in a situation where we have to either:

* accept *Object as the suffix for all of these APIs indefinitely, even though it's ambiguous and confusing
* choose a new suffix and use that for the APIs already added in 3.4 and add compatibility aliases for the older APIs to make them consistent
* change the public API additions already made for 3.4 to new private APIs by adding an underscore prefix, and then reconsider the public API naming question for 3.5
* accept *Object as the suffix for the moment, but aim to replace it with something more descriptive in Python 3.5

Neither Serhiy nor I are comfortable with the first option, and making a decision in haste for the second option doesn't seem like a good idea. Option 3 seems like far too much work to make things less useful (a capability that works, but has an ambiguous and confusing name, is better than a capability that isn't provided at all)

That leaves option number 4: don't change anything further now, but revisit it for 3.5, including changing the preferred name of the existing APIs.

I like that approach, so I'm assigning to myself to take a closer look at how some of the suggestions above read in the docs once 3.4 is out the door.

----------
assignee:  -> ncoghlan
nosy: +larry
priority: normal -> 
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:54:09 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 02:54:09 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387248849.72.0.15161650877.issue19518@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 03:54:31 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 17 Dec 2013 02:54:31 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1387248871.23.0.752149265678.issue19717@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Updated patch to tip. Later, I refactor Windows code to make sure it does not loop forever.

----------
Added file: http://bugs.python.org/file33171/add_non_strict_resolve_pathlib_v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:12:51 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 17 Dec 2013 03:12:51 +0000
Subject: [issue19994] re.match does not return or takes long time
In-Reply-To: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>
Message-ID: <1387249971.83.0.898880843641.issue19994@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Tim, if you made this ticket as invalid, why don't you close it? Any reason?

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19994>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:28:57 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 17 Dec 2013 03:28:57 +0000
Subject: [issue19994] re.match does not return or takes long time
In-Reply-To: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>
Message-ID: <1387250937.54.0.137422070596.issue19994@psf.upfronthosting.co.za>


Tim Peters added the comment:

@vajrasky, I didn't close it just because "the usual suspects" haven't chimed in yet.  That is, it's a pretty common kind of report, and these usually attract the same kinds of comments pointing to other regexp implementations.  So leaving it to "the regexp person" (whoever that may be these days) to close it.  But marked it as invalid so as not to give the OP false hope ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19994>
_______________________________________

From report at bugs.python.org  Tue Dec 17 04:47:52 2013
From: report at bugs.python.org (rurpy)
Date: Tue, 17 Dec 2013 03:47:52 +0000
Subject: [issue20003] Language Ref "raise" doc misssing "from None"
Message-ID: <1387252072.89.0.572943909834.issue20003@psf.upfronthosting.co.za>


New submission from rurpy:

In the current (3.3.3 and 3.4dev) Language Reference Manual, the section on the Raise statement fails to mention that the second expression can be None (per PEP-409/415) or the special behavior (suppressing a chained exception) that ensues.  Rather it explicitly states it can not be None:
 "...the second expression must be another exception class  or instance..."

It appears that although the Exceptions section of the Library Reference was updated when PEP-409/415 was implemented, the Language Reference was not.

----------
assignee: docs at python
components: Documentation
messages: 206400
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: Language Ref "raise" doc misssing "from None"
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20003>
_______________________________________

From report at bugs.python.org  Tue Dec 17 06:13:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 05:13:40 +0000
Subject: [issue20001] pathlib inheritance diagram too large
In-Reply-To: <1387221538.52.0.488414928183.issue20001@psf.upfronthosting.co.za>
Message-ID: <3dk6vR1hVRz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset fe49ed665190 by Eli Bendersky in branch 'default':
Issue #20001: Add the SVG source of the pathlib-inheritance diagram to Hg
http://hg.python.org/cpython/rev/fe49ed665190

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20001>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:11:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 06:11:56 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <3dk8Bf37PPz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 2c27c0e5bc50 by Eric Snow in branch 'default':
Issue #19713: Update importlib docs for module spec changes, including deprecations.
http://hg.python.org/cpython/rev/2c27c0e5bc50

New changeset b78de8029606 by Eric Snow in branch 'default':
Issue #19713: Fix mistakes in the import page of language reference.
http://hg.python.org/cpython/rev/b78de8029606

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:12:53 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:12:53 +0000
Subject: [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387260773.74.0.640815013966.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

New changeset 2c27c0e5bc50 by Eric Snow in branch 'default':
Issue #19713: Update importlib docs for module spec changes, including deprecations.
http://hg.python.org/cpython/rev/2c27c0e5bc50

New changeset b78de8029606 by Eric Snow in branch 'default':
Issue #19713: Fix mistakes in the import page of language reference.
http://hg.python.org/cpython/rev/b78de8029606

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19710>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:13:27 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:13:27 +0000
Subject: [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387260807.51.0.739243298694.issue19710@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19710>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:14:03 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:14:03 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387260843.87.0.667985802149.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

The doc deprecations should now be complete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:15:03 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:15:03 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387260903.53.0.778747234149.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

P.S. changeset b78de8029606 should have referred to #19710.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:16:23 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:16:23 +0000
Subject: [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387260983.89.0.964021882959.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm leaving this as pending for the moment in case we notice anything I missed.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19710>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:26:07 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:26:07 +0000
Subject: [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387261567.58.0.260771342178.issue19710@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19710>
_______________________________________

From report at bugs.python.org  Tue Dec 17 07:55:17 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 06:55:17 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387263317.75.0.143892242505.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a patch that simply adds all the deprecation warnings.  It does not include any effort to silence the zillion warnings that happen when the test suite is run with -Wall.  I plan on addressing all those when I have some time.  That will be a matter of refactoring tests or stdlib modules to not use deprecated APIs.

In cases when the warnings happen due to BuiltinImporter.load_module() or ExtensionFileLoader.load_module(), I'll need to silence the warnings in the tests.

2 questions:

* Could I push this changeset (after a few fixes) before adding in all the refactors, doing those separately?
* Could we special-case BuiltinImporter and ExtensionFileLoader in _SpecMethods._load_backward_compatible() so that they don't cause a warning?  I know we've also talked about skipping the deprecation warning entirely for load_module()...

There are also several places in _bootstrap where a method (A) may raise a warning and a method it calls (B) may raise a similar warning.  Would there be any probably with silencing the deprecation warning coming out of the called method (B)?

----------
Added file: http://bugs.python.org/file33172/issue19713-deprecation-warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 08:09:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 07:09:37 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1387264177.16.0.901935352072.issue19717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Vajrasky's patch implements fourth strategy, which is not conform neither --canonicalize nor --canonicalize-missing. Path(BASE, 'foo', 'in', 'spam') is resolved to Path(BASE, 'foo'). I doubt that this is most expected behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Tue Dec 17 08:09:59 2013
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Dec 2013 07:09:59 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387264199.35.0.707132858429.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thank you, Victor and Serhiy, for your pointers into the code.

I'm hoping we have general agreement about %c, %o, %x, and %X and having them use __index__ only (using __int__ would open the door to float conversions).

I still have a question about %i, though.  The docs say %u is exactly the same as %d and is therefore deprecated.  The docs do not say thay %i is the same as %d, but the descriptions are the same.

Are %i and %d the same, or is there some difference?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Tue Dec 17 08:16:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 07:16:01 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387264561.23.0.644132629953.issue19713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please use correct stacklevel, such that warnings will point to places where deprecated function used, not where they are defined?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 08:23:58 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 17 Dec 2013 07:23:58 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387265038.96.0.813295581944.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'd meant to do that.  I'll update the patch when I have a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:13:17 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 17 Dec 2013 08:13:17 +0000
Subject: [issue19920] TarFile.list() fails on some files
In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za>
Message-ID: <1387267997.98.0.728139682728.issue19920@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file33173/fix_tarfile_list_print_lone_surrogate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19920>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:20:33 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 17 Dec 2013 08:20:33 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1387268433.73.0.790551816115.issue19717@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

I based my implementation on this statement:

"Guido pointed out that it may more useful to resolve the path components until one doesn't exist"

"until one doesn't exist" in this case means P(BASE, 'foo', 'in', 'spam') resolves until BASE / 'foo'.

If different spec is better, I'll change the implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Tue Dec 17 09:30:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 08:30:45 +0000
Subject: [issue19894] zipfile ignores deflate level settings in zipinfo object
In-Reply-To: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>
Message-ID: <1387269045.78.0.969354840409.issue19894@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is new feature and can be added only in 3.5.

----------
assignee: docs at python -> 
components:  -Documentation, Tests
stage: patch review -> needs patch
type: behavior -> enhancement
versions: +Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19894>
_______________________________________

From report at bugs.python.org  Tue Dec 17 10:05:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 09:05:05 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1387271105.36.0.949133602216.issue19717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I believe Guido meant one of standard strategies. Current posixpath.realpath() implementation conforms --canonicalize-missing.
It is not clear which two strategies (from three) should be used in Path.resolve().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:43:23 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 17 Dec 2013 10:43:23 +0000
Subject: [issue19385] dbm.dumb should be consistent when the database is closed
In-Reply-To: <1382683121.03.0.174486602388.issue19385@psf.upfronthosting.co.za>
Message-ID: <1387277003.65.0.578293946372.issue19385@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

If we agree that this should be fixed in 3.4, can somebody commit it before the second beta?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19385>
_______________________________________

From report at bugs.python.org  Tue Dec 17 11:48:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 10:48:18 +0000
Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs
In-Reply-To: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za>
Message-ID: <1387277298.88.0.881484288286.issue20000@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> get_ca_certs() doesn't return the cert although it is used to
> successfully validate a remote cert.

Interesting. Is it because of the way you implemented get_ca_certs()?

> I propose to modify and rename the function and to add a "check_ca" to
> the dict that is returned by getpeercert().

Can you explain? What does "check_ca" mean?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20000>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:09:53 2013
From: report at bugs.python.org (Peter Otten)
Date: Tue, 17 Dec 2013 11:09:53 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
Message-ID: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>


New submission from Peter Otten:

I ran into this when trying to trigger rereading the column names with

$ cat tmp.csv
alpha,beta
1,2
gamma,delta,epsilon
3,4,5
$ python
Python 2.7.2+ (default, Jul 20 2012, 22:15:08) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import csv
>>> with open("tmp.csv") as f:
...     reader = csv.DictReader(f)
...     for i in range(2):
...             print next(reader)
...             reader.fieldnames = None
... 
{'alpha': '1', 'beta': '2'}
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/usr/lib/python2.7/csv.py", line 112, in next
    d = dict(zip(self.fieldnames, row))
TypeError: zip argument #1 must support iteration

reader = csv.DictReader(...)
...
reader.fieldnames = None

I think the easiest fix would be to have it inherit from object:

>>> class DictReader(csv.DictReader, object): pass
... 
>>> with open("tmp.csv") as f:
...     reader = DictReader(f)
...     for i in range(2):
...             print next(reader)
...             reader.fieldnames = None
... 
{'alpha': '1', 'beta': '2'}
{'3': 'gamma', '5': 'epsilon', '4': 'delta'}

----------
messages: 206418
nosy: peter.otten
priority: normal
severity: normal
status: open
title: csv.DictReader classic class has a property with setter
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:14:26 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 17 Dec 2013 11:14:26 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>
Message-ID: <1387278866.82.0.932282078112.issue19997@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Thanks, Vajrasky, I forgot about the fact that open can open file descriptors. Here's a patch which fixes this, also adds a test for BytesIO and uses os.fsencode instead of .encode().

----------
Added file: http://bugs.python.org/file33174/imghdr_files.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:42:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 11:42:12 +0000
Subject: [issue17825] Indentation.offset and SyntaxError.offset mismatch
In-Reply-To: <1366789582.23.0.0218552351895.issue17825@psf.upfronthosting.co.za>
Message-ID: <1387280532.97.0.524497256015.issue17825@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

patch_indenterror_offset_v2.diff LGTM.

----------
stage:  -> commit review
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17825>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:42:50 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 11:42:50 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387280570.77.0.95798729146.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OK, fixed test case attached. Turns out the ipython workaround test was completely wrong and never even loaded multiprocessing, and hence always passed, even with the workaround disabled. So I fixed that test case, and used the same approach for the zipfile, directory and package tests. I also fixed the submodule test to check that explicit relative imports work properly from __mp_main__ in the child processes.

With this updated test cast, the v2 patch handles everything correctly, but there are 4 failures on Linux without the patch. Specifically:

- test_basic_script_no_suffix fails for the spawn and forkserver start methods (the child processes fail to find a spec for __mp_main__)
- test_module_in_package fails for the spawn and forkserver start methods (the explicit relative import from __mp_main__ fails because the import system isn't initialised correctly in the child processes)

The former case is the one Olivier reported in this issue. It's a new case for 3.4, since the spawn start method was previously only available on Windows, where scripts always have an extension.

The latter edge case is the one my "XXX (ncoghlan): The following code makes several bogus assumptions regarding the relationship between __file__ and a module's real name." comment was about.

I believe we could actually adjust earlier versions to handle things as well as this new PEP 451 based approach (by using a combination of __package__ and __file__ rather than __spec__), but that's much harder for me to work on in those versions where the "spawn" start method is only available on Windows :)

----------
Added file: http://bugs.python.org/file33175/test_multiprocessing_main_handling.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:43:10 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 11:43:10 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387280590.98.0.0750183773672.issue19946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file33146/issue19946_pep_451_multiprocessing.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:43:31 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 11:43:31 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387280611.87.0.672112334391.issue19946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file33161/test_multiprocessing_main_handling.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 17 12:53:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 11:53:52 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387281232.09.0.517361557558.issue17976@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. But err_flag is not needed, valid error numbers are all nonzero.

----------
assignee:  -> serhiy.storchaka
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:03:40 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 17 Dec 2013 12:03:40 +0000
Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs
In-Reply-To: <1387277298.88.0.881484288286.issue20000@psf.upfronthosting.co.za>
Message-ID: <52B03D99.2070101@cheimes.de>


Christian Heimes added the comment:

> Interesting. Is it because of the way you implemented get_ca_certs()?

Yes, it's the line

  http://hg.python.org/cpython/file/b78de8029606/Modules/_ssl.c#l3103

that skips all certs that are not recognized as CA certs. I wasn't aware
that OpenSSL supports self-signed certs that way.

> Can you explain? What does "check_ca" mean?

The return value of X509_check_ca().

http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/x509v3/v3_purp.c;h=6c40c7dfc318e4b46fc20d38581ad3656e344b5e;hb=HEAD#l517

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20000>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:07:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 12:07:11 +0000
Subject: [issue20000] SSLContext.get_ca_certs() and self-signed certs
In-Reply-To: <1387220030.99.0.0276464783547.issue20000@psf.upfronthosting.co.za>
Message-ID: <1387282031.65.0.212151546261.issue20000@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20000>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:17:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 12:17:42 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <3dkJJj27DvzNN5@mail.python.org>


Roundup Robot added the comment:

New changeset b6d6f3b4b100 by Nick Coghlan in branch 'default':
Close #19946: use runpy as needed in multiprocessing
http://hg.python.org/cpython/rev/b6d6f3b4b100

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:22:38 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 12:22:38 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387282958.39.0.782506325024.issue19946@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file33163/test_multiprocessing_main_handling.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:26:35 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Tue, 17 Dec 2013 12:26:35 +0000
Subject: [issue20005] Minor typo in operator documentation
Message-ID: <1387283195.64.0.628097556961.issue20005@psf.upfronthosting.co.za>


Changes by Claudiu.Popa <pcmanticore at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: typo_operator.patch
keywords: patch
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in operator documentation
versions: Python 3.4
Added file: http://bugs.python.org/file33176/typo_operator.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20005>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:30:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 12:30:37 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387283437.5.0.107833999242.issue19700@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

On second thoughts, I'm going to close this one - if further runpy changes are needed to resolve issue 19702 (using __spec__.name for pickle when appropriate), let's deal with them there.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:40:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 12:40:53 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <3dkJqS0m9qz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 33c27b76a4d0 by Serhiy Storchaka in branch '2.7':
Issue #17976: Fixed potential problem with file.write() not detecting IO error
http://hg.python.org/cpython/rev/33c27b76a4d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:40:56 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 12:40:56 +0000
Subject: [issue19702] Update pickle to PEP 451
In-Reply-To: <1385624711.1.0.561130815884.issue19702@psf.upfronthosting.co.za>
Message-ID: <1387284056.83.0.737071634757.issue19702@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 19700 means that runpy now ensures that __main__.__spec__ is set appropriately when __main__ is executed via the import system.

Issue 19946 means that multiprocessing now ensures that __main__ is configured correctly in child processes to reference a properly initialised "fake main" to allow pickle compatibility with classes and functions defined in __main__ outside "if __name__ == '__main__'" guards.

The proposal here is that we make the following changes:

- runpy will ensure that when __main__ is executed via the import system, it will also be aliased in sys.modules as __spec__.name
- if __main__.__spec__ is set, pickle will use __spec__.name rather than __name__ to pickle classes, functions and methods defined in __main__
- multiprocessing is updated appropriately to skip creating __mp_main__ in child processes when __main__.__spec__ is set in the parent process

While I still think this is a reasonable idea, I think it qualifies as a new feature, and hence is better postponed to Python 3.5

----------
dependencies: +Handle a non-importable __main__ in multiprocessing
nosy: +larry
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19702>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:41:16 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 12:41:16 +0000
Subject: [issue19702] Update pickle to take advantage of PEP 451
In-Reply-To: <1385624711.1.0.561130815884.issue19702@psf.upfronthosting.co.za>
Message-ID: <1387284076.16.0.400436578073.issue19702@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Update pickle to PEP 451 -> Update pickle to take advantage of PEP 451

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19702>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:42:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 12:42:19 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387284139.25.0.871882570293.issue17976@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Jaakko Moisio for your report and patch.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:48:23 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 12:48:23 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
 as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1387284503.14.0.654695717187.issue9325@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 19982 suggests a different way of refactoring the runpy APIs inspired by PEP 451: passing in a "target" module to be used, rather than creating a temporary one from scratch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9325>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:48:44 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 12:48:44 +0000
Subject: [issue19982] Add a "target" parameter to runpy.run_path and
 runpy.run_module
In-Reply-To: <1387027323.14.0.795736210788.issue19982@psf.upfronthosting.co.za>
Message-ID: <1387284524.75.0.387301324749.issue19982@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Implementing this is actually likely to require non-trivial restructuring of the runpy internals. contextlib.ExitStack may prove useful in making it easier to programmatically select amongst different context managers.

The __mp_main__ helpers in multiprocessing should also be able to take advantage of this once it is available, and it may prove useful in finally providing -m analogues for pdb etc that play nice when an exception occurs (see issue 9325).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19982>
_______________________________________

From report at bugs.python.org  Tue Dec 17 13:54:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 12:54:17 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <3dkK6w6yvxz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 237deaf9ba64 by Serhiy Storchaka in branch '2.7':
Skip test for issue #17976 if /dev/null is not available.
http://hg.python.org/cpython/rev/237deaf9ba64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:06:05 2013
From: report at bugs.python.org (Yongzhi Pan)
Date: Tue, 17 Dec 2013 13:06:05 +0000
Subject: [issue14228] It is impossible to catch sigint on startup in python
 code
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387285565.95.0.0712243886863.issue14228@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <fossilet at users.sourceforge.net>:


----------
nosy: +fossilet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:15:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 13:15:18 +0000
Subject: [issue16404] Uses of PyLong_FromLong that don't check for errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <3dkKb9721nz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset debdfa44f020 by Serhiy Storchaka in branch '2.7':
Issue #16404: Add checks for return value of PyInt_FromLong() in
http://hg.python.org/cpython/rev/debdfa44f020

New changeset 928c0acf7c09 by Serhiy Storchaka in branch '3.3':
Issue #16404: Add checks for return value of PyLong_FromLong() in
http://hg.python.org/cpython/rev/928c0acf7c09

New changeset d489394a73de by Serhiy Storchaka in branch 'default':
Issue #16404: Add checks for return value of PyLong_FromLong() in
http://hg.python.org/cpython/rev/d489394a73de

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16404>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:17:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 13:17:54 +0000
Subject: [issue16404] Uses of PyLong_FromLong that don't check for errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1387286274.91.0.78875821496.issue16404@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16404>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:47:35 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 13:47:35 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1387288055.74.0.676776868637.issue992389@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'm reopening this, since PEP 451 opens up new options for dealing with it (at least for loaders that export the PEP 451 APIs rather than only the legacy loader API, which now includes all the standard loaders other than the ones for builtins and extension modules)

The attached patch doesn't have an automated test and is quite rough around the edges (as the additional check for the parent being in sys.modules confuses a couple of the importlib tests), but it proves the concept by making the following work:

[ncoghlan at lancre py3k]$ cd ../play
[ncoghlan at lancre play]$ mkdir issue992389
[ncoghlan at lancre play]$ cat > issue992389/mod.py
from . import mod
print("Success!")
[ncoghlan at lancre play]$ python3 -c "import issue992389.mod"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./issue992389/mod.py", line 1, in <module>
    from . import mod
ImportError: cannot import name mod
[ncoghlan at lancre play]$ ../py3k/python -c "import issue992389.mod"
Success!

----------
keywords: +patch
nosy: +larry
resolution: duplicate -> 
status: closed -> open
superseder: Modify IMPORT_FROM to fallback on sys.modules -> 
versions: +Python 3.4 -Python 3.3
Added file: http://bugs.python.org/file33177/issue992389_set_parent_module_attribute.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:52:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Dec 2013 13:52:41 +0000
Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules
In-Reply-To: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za>
Message-ID: <1387288361.64.0.652949277668.issue17636@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

With PEP 451 implemented, note that I have reopened issue 992389 - the patch to set the parent module attribute at the same time as setting the sys.module attribute is actually pretty trivial for the PEP 451 loader case, and that now includes all the standard loaders.

I also think that approach will have fewer weird edge cases than this version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17636>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:55:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 13:55:47 +0000
Subject: [issue20006] Sporadic failures of test_weakset
Message-ID: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

test_weakset often fails on FreeBSD. Fo example see http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%202.7/builds/285/steps/test/logs/stdio.

test test_weakset failed -- Traceback (most recent call last):
  File "/usr/home/buildbot/koobs-freebsd10/2.7.koobs-freebsd10/build/Lib/test/test_weakset.py", line 491, in test_weak_destroy_and_mutate_while_iterating
    self.assertTrue(u in s)
AssertionError: False is not true

Second run of this test is successful.

----------
messages: 206435
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Sporadic failures of test_weakset
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 14:59:53 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2013 13:59:53 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387288793.02.0.163567410816.issue20004@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm not clear on this: is this a new feature you'd like to see, or is this documented behavior of a DictReader that's not working?

If it's a new feature, the earliest it can be implemented is in 3.5.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:00:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2013 14:00:42 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387288842.47.0.511269602404.issue17976@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I played with fullwrite.c and now think that the fix is incomplete. fwrite() may succeed to write data into the buffer, but you may get the error on fflush() or fclose().

Try attached fullwrite2.c: fwrite() succeed (written=len, errno=result=0), whereas fclose() fails. If you enable fflush(), it will also fail.

Output:
---
fwrite(hello
) => 6 bytes written/6 [errno=0, ferror=0]
fclose() => -1 [errno=28]
---

The complete fix is maybe to write fflush() before fclose(), or at least raise an exception if fclose() returns a non-zero result. Correctly, file.close() returns a number in case of an error...

But now comes the question of backward compatibility, may such change "break" applications? It's maybe a nice thing to "break" applications if it warns users that they are going to loose data (USB key full, cannot write the whole important document!).

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file33178/fullwrite2.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:01:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2013 14:01:05 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387288865.27.0.139677772976.issue17976@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(I was trying to report the issue upstream.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:02:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 14:02:55 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <1387288975.98.0.952059718862.issue20006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Does it occur only on 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:04:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Dec 2013 14:04:11 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387289051.15.0.609215287628.issue19713@psf.upfronthosting.co.za>


Brett Cannon added the comment:

* Yes, you can commit with the warnings being triggered to get help with resolving them, just expect to potentially do a lot of work to make sure they don't leak out into 3.4 final.

* Just don't deprecate load_module() yet in code. If we can't even get rid of all our usage of the method then it isn't fair to expect users to do the same. Deprecating in the docs is fine, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:07:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 14:07:24 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387289244.17.0.840753625019.issue17976@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Are you have Python code which exposes a bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:08:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 14:08:32 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <1387289312.21.0.110542095782.issue20006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I can't reproduce the failure after more than 2000 test runs.
Also, this failure is weird: the test is supposed to be deterministic.

----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:09:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 14:09:13 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288975.98.0.952059718862.issue20006@psf.upfronthosting.co.za>
Message-ID: <9915317.dOEA50HatW@raxxla>


Serhiy Storchaka added the comment:

> Does it occur only on 2.7?

Don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:14:32 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 14:14:32 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387289672.53.0.0741755891861.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Although this is clearly a bug, we've run into backward compatibility issues in the past with promoting stdlib classic classes to new style, so I'm not sure if the risk of fixing it is worth the benefit.  It is obviously not a problem in Python3.

Eric: I had to stare it for a while to see it...the problem is that because it is a classic class, the setter for fieldnames doesn't *work*, it just replaces the value of 'fieldnames' instead of setting self._fieldnames.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:15:54 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 14:15:54 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <1387289754.72.0.471302151055.issue20006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, it seems the failure can happen because of hash randomization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:29:41 2013
From: report at bugs.python.org (Simon Sapin)
Date: Tue, 17 Dec 2013 14:29:41 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
Message-ID: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>


New submission from Simon Sapin:

When given a file-like object, html5lib calls .read(0) in order to check if the result is bytes or Unicode:

https://github.com/html5lib/html5lib-python/blob/e269a2fd0aafcd83af7cf1e65bba65c0e5a2c18b/html5lib/inputstream.py#L434

When given the result of urllib.client.urlopen(), it parses an empty document because of this bug.

Test case:

>>> from urllib.request import urlopen
>>> response = urlopen('http://python.org')
>>> response.read(0)
b''
>>> len(response.read())
0

For comparison:

>>> response = urlopen('http://python.org')
>>> len(response.read())
20317

The bug is here:

http://hg.python.org/cpython/file/d489394a73de/Lib/http/client.py#l541

'if not n:' assumes that "zero bytes have been read" indicates EOF, which is not the case when we ask for zero bytes.

----------
messages: 206446
nosy: ssapin
priority: normal
severity: normal
status: open
title: .read(0) on http.client.HTTPResponse drops the rest of the content
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:29:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Dec 2013 14:29:42 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387290582.65.0.509234591626.issue17976@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The complete fix is maybe to write fflush() before fclose(), or at least raise an exception if fclose() returns a non-zero result. Correctly, file.close() returns a number in case of an error...

Oh sorry, I missed the line "if (sts == -1) ..." which raises an error.

But I'm still unable to reproduce the glibc bug mentioned by Charles-Fran?ois :

> Yeah, who's volunteering to report it to the glibc?

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:36:46 2013
From: report at bugs.python.org (Simon Sapin)
Date: Tue, 17 Dec 2013 14:36:46 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387291006.62.0.874801807325.issue20007@psf.upfronthosting.co.za>


Simon Sapin added the comment:

Adding a proposed patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file33179/python-issue20007.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:38:11 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 17 Dec 2013 14:38:11 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387291091.73.0.491849994903.issue19518@psf.upfronthosting.co.za>


Larry Hastings added the comment:

So all the PyRun_*Object functions are new in 3.4, and none of them are documented yet?

Option 4 is silly--I don't think we should ship them as public APIs in 3.4 if we're planning to rename them.  I prefer the previous options.

p.s. fwiw I hate "ExName".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:39:57 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 17 Dec 2013 14:39:57 +0000
Subject: [issue19702] Update pickle to take advantage of PEP 451
In-Reply-To: <1385624711.1.0.561130815884.issue19702@psf.upfronthosting.co.za>
Message-ID: <1387291197.66.0.191483842105.issue19702@psf.upfronthosting.co.za>


Larry Hastings added the comment:

So far I agree that this should be postponed to 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19702>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:43:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 14:43:36 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <1387291416.14.0.323007795453.issue20006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch. The failure doesn't occur on 3.x because of f189da5bda26, which clearly looks misled now.

----------
assignee:  -> pitrou
keywords: +patch
Added file: http://bugs.python.org/file33180/issue20006.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:43:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 14:43:45 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <1387291425.3.0.491930409879.issue20006@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests
stage:  -> patch review
versions: +Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:49:46 2013
From: report at bugs.python.org (Jaakko Moisio)
Date: Tue, 17 Dec 2013 14:49:46 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <1387291786.04.0.205776522606.issue17976@psf.upfronthosting.co.za>


Jaakko Moisio added the comment:

The new patch is fine as it is, but my logic behind using err_flag was the following: err_flag was set solely based on the inspection of return value of fwrite and ferror, without referencing to errno. It is of course true that at the same time errno is set to non-zero in any correct C standard library implementation (err_flag != 0 iff err != 0), but as the patch was originally for circumventing a bug in glibc, I decided to be use that extra flag for the purpose.

> But I'm still unable to reproduce the glibc bug mentioned by Charles-Fran?ois :

Yes. It seems that the bug in glibc has been fixed. But at least Python 2.7 is now a little bit better guarded against exotic file IO bugs that might emerge in C standard libraries :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:55:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 14:55:48 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387292148.87.0.0353542318038.issue19518@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> So all the PyRun_*Object functions are new in 3.4, and none of them are documented yet?

Not all. Only following functions are new in 3.4:

Parser/parsetok.c:PyParser_ParseStringObject
Parser/parsetok.c:PyParser_ParseFileObject
Python/future.c:PyFuture_FromASTObject
Python/symtable.c:PySymtable_BuildObject
Python/compile.c:PyAST_CompileObject
Python/_warnings.c:PyErr_WarnExplicitObject
Python/ast.c:PyAST_FromNodeObject
Python/errors.c:PyErr_SyntaxLocationObject
Python/errors.c:PyErr_ProgramTextObject
Python/pythonrun.c:PyRun_InteractiveOneObject
Python/pythonrun.c:Py_CompileStringObject
Python/pythonrun.c:Py_SymtableStringObject
Python/pythonrun.c:PyParser_ASTFromStringObject
Python/pythonrun.c:PyParser_ASTFromFileObject

Following functions existed in 3.3:

Objects/moduleobject.c:PyModule_NewObject
Objects/moduleobject.c:PyModule_GetNameObject
Objects/moduleobject.c:PyModule_GetFilenameObject
Objects/abstract.c:PyObject_CallObject
Objects/bytesobject.c:PyBytes_FromObject
Objects/fileobject.c:PyFile_WriteObject
Objects/memoryobject.c:PyMemoryView_FromObject
Objects/longobject.c:PyLong_FromUnicodeObject
Objects/weakrefobject.c:PyWeakref_GetObject
Objects/exceptions.c:PyUnicodeEncodeError_GetObject
Objects/exceptions.c:PyUnicodeDecodeError_GetObject
Objects/exceptions.c:PyUnicodeTranslateError_GetObject
Objects/unicodeobject.c:PyUnicode_FromObject
Objects/unicodeobject.c:PyUnicode_FromEncodedObject
Objects/unicodeobject.c:PyUnicode_AsDecodedObject
Objects/unicodeobject.c:PyUnicode_AsEncodedObject
Objects/bytearrayobject.c:PyByteArray_FromObject
Python/sysmodule.c:PySys_GetObject
Python/sysmodule.c:PySys_SetObject
Python/errors.c:PyErr_SetObject
Python/errors.c:PyErr_SetFromErrnoWithFilenameObject
Python/import.c:_PyImport_FixupExtensionObject
Python/import.c:_PyImport_FindExtensionObject
Python/import.c:PyImport_AddModuleObject
Python/import.c:PyImport_ExecCodeModuleObject
Python/import.c:PyImport_ImportFrozenModuleObject
Python/import.c:PyImport_ImportModuleLevelObject
Python/modsupport.c:PyModule_AddObject
Python/pyarena.c:PyArena_AddPyObject

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:56:18 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2013 14:56:18 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387292178.03.0.0060135265261.issue20004@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

My (poorly phrased) question really was: is resetting fieldnames documented to force a re-read of the column headers? I don't see that it is, so I'm going to call this a 3.5 enhancement request.

I agree with David that we can't change DictReader to inherit from object in 2.7 without risking some non-obvious failure. Who knows how people have derived from a DictReader, and what they're expecting to work?

If we do want this feature added, I'm not sure resetting fieldnames to None is an obvious interface. Maybe a "reset_field_names(fieldnames=None)" method, or something like it, would make more sense.

To accomplish this today, you can use various itertools functions to split up the input iterator and use two different DictReaders.

----------
type:  -> enhancement
versions: +Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:56:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 14:56:42 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387289754.72.0.471302151055.issue20006@psf.upfronthosting.co.za>
Message-ID: <4452557.lh853qOjJZ@raxxla>


Serhiy Storchaka added the comment:

> Ah, it seems the failure can happen because of hash randomization.

Indeed. With -R switch 1/8 of tests are failed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:58:23 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 17 Dec 2013 14:58:23 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387292303.42.0.222464791208.issue19518@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Are all the functions that use "Object" to indicate "Unicode object instead of string" new in 3.4?  Of those, how many are undocumented?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 15:59:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 14:59:10 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387292350.16.0.567219058283.issue20007@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +orsenthil, serhiy.storchaka
stage:  -> patch review
versions: +Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:03:53 2013
From: report at bugs.python.org (Peter Otten)
Date: Tue, 17 Dec 2013 15:03:53 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387292633.74.0.560978175675.issue20004@psf.upfronthosting.co.za>


Peter Otten added the comment:

Setting the fieldnames attribute of an existing DictReader is not documented. Eric, there is no need for an enhancement (other than for the documentation) as this already works in Python 3 where newstyle classes are the default. The heart of the bug is really the classic class with a property.

I have no idea what a fix could look like that is less intrusive than promoting DictReader to a newstyle class. 

Maybe it would be sufficient to add a comment to the code pointing to my bug report? I've already shown one workaround (object as a mixin); another would be to set the private _fieldnames rather than fieldnames so that the getter will continue to work as designed.

Looking at the current DictReader code and determining why and how it fails will be quite hard for a non-expert ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:04:04 2013
From: report at bugs.python.org (Simon Sapin)
Date: Tue, 17 Dec 2013 15:04:04 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387292644.15.0.670035124141.issue20007@psf.upfronthosting.co.za>


Simon Sapin added the comment:

html5lib issue: https://github.com/html5lib/html5lib-python/issues/127

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:06:49 2013
From: report at bugs.python.org (Simon Sapin)
Date: Tue, 17 Dec 2013 15:06:49 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387292809.53.0.388470357193.issue20007@psf.upfronthosting.co.za>


Simon Sapin added the comment:

I could reproduce on 3.3.3 and tip, but not 3.2.3 or 2.7.6.

----------
versions: +Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:16:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 15:16:12 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1387292303.42.0.222464791208.issue19518@psf.upfronthosting.co.za>
Message-ID: <4978485.xPhiTVIJE3@raxxla>


Serhiy Storchaka added the comment:

> Are all the functions that use "Object" to indicate "Unicode object instead
> of string" new in 3.4?  Of those, how many are undocumented?

Following 5 functions work with PyObject* filenames and have Object-less 
variants which works with char * filenames:

Python/errors.c:PyErr_SetFromErrnoWithFilenameObject
Python/import.c:PyImport_AddModuleObject
Python/import.c:PyImport_ExecCodeModuleObject
Python/import.c:PyImport_ImportFrozenModuleObject
Python/import.c:PyImport_ImportModuleLevelObject

Private _PyImport_FixupExtensionObject and _PyImport_FindExtensionObject have 
no Object-less variants.

All other *Object functions are unrelated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:32:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 15:32:48 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
Message-ID: <3dkNdq5YCNzMrl@mail.python.org>


Roundup Robot added the comment:

New changeset 24a043355050 by Serhiy Storchaka in branch '2.7':
Circumventing a bug in glibc (issue #17976).
http://hg.python.org/cpython/rev/24a043355050

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:33:16 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 17 Dec 2013 15:33:16 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387294396.62.0.420256893926.issue19518@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Are those five functions new in 3.4 and undocumented?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:33:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 15:33:22 +0000
Subject: [issue17976] file.write doesn't raise IOError when it should
In-Reply-To: <1387291786.04.0.205776522606.issue17976@psf.upfronthosting.co.za>
Message-ID: <2699883.SZl4rujpoM@raxxla>


Serhiy Storchaka added the comment:

Agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17976>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:34:43 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 17 Dec 2013 15:34:43 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>
Message-ID: <1387294483.0.0.903909449357.issue19518@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Are we proposing renaming any functions that are either
a) not new in 3.4, or
b) were documented as of 3.4 beta 1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:42:47 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 17 Dec 2013 15:42:47 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387294967.26.0.882086033441.issue19995@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

AFAIK %i and %d are the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:45:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 15:45:44 +0000
Subject: [issue19518] Add new PyRun_xxx() functions to not encode the filename
In-Reply-To: <1387294396.62.0.420256893926.issue19518@psf.upfronthosting.co.za>
Message-ID: <1457253.mBQGYT3DiJ@raxxla>


Serhiy Storchaka added the comment:

> Are those five functions new in 3.4 and undocumented?

PyErr_SetFromErrnoWithFilenameObject exists even in 2.7. Other 4 
PyImport_*Object functions all added in 3.3 (see issue3080). All 5 functions 
are documented.

14 new functions were added in 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19518>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:47:33 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 17 Dec 2013 15:47:33 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387295253.3.0.211168096534.issue19995@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Yes, looking through Objects/unicodeobject.c, 'u', 'i', and 'd' are treated the same everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Tue Dec 17 16:52:44 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 17 Dec 2013 15:52:44 +0000
Subject: [issue19994] re.match does not return or takes long time
In-Reply-To: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>
Message-ID: <1387295564.99.0.590733542182.issue19994@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

It takes a long time due to excessive backtracking.

The regex implementation on PyPI finishes quickly because it contains some extra logic to reduce the chances of that happening, but it could be tricky trying to incorporate that into the existing re module.

Unless someone else wants have a go, it's probably best to mark this as "won't fix".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19994>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:04:10 2013
From: report at bugs.python.org (Jens Timmerman)
Date: Tue, 17 Dec 2013 16:04:10 +0000
Subject: [issue4130] Intel icc 9.1 does not support __int128_t used by ctypes
In-Reply-To: <1224103336.6.0.753228794094.issue4130@psf.upfronthosting.co.za>
Message-ID: <1387296250.6.0.135109238477.issue4130@psf.upfronthosting.co.za>


Jens Timmerman added the comment:

sorry for my confusion, 

libffi's website stated

libffi-3.0.14 was released on TBD. 

I must have missed the TBD part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4130>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:20:13 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 17 Dec 2013 16:20:13 +0000
Subject: [issue19994] re.match does not return or takes long time
In-Reply-To: <1387185364.15.0.621254841933.issue19994@psf.upfronthosting.co.za>
Message-ID: <1387297213.61.0.608764159693.issue19994@psf.upfronthosting.co.za>


Tim Peters added the comment:

Closing this.  Since nobody else "wants have a go" over two decades so far, no point waiting for that ;-)

----------
resolution: invalid -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19994>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:29:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 16:29:46 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387297786.75.0.483961552617.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since it isn't easy to figure out that setting fieldnames to None would do anything useful without looking at the code, I'd say a code comment would be appropriate.  The exception would be someone backporting code from python3, but I think we'll just quietly ignore that possibility ;)

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type: enhancement -> behavior
versions: +Python 2.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:36:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 16:36:22 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387298182.06.0.534425806263.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is a proposed comment wording.

----------
keywords: +patch
Added file: http://bugs.python.org/file33181/csv_dictread_setter_comment.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:42:02 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 17 Dec 2013 16:42:02 +0000
Subject: [issue18283] shutil.which() should support bytes
In-Reply-To: <1371914951.06.0.665120918364.issue18283@psf.upfronthosting.co.za>
Message-ID: <1387298522.97.0.0142118563235.issue18283@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
stage: committed/rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18283>
_______________________________________

From report at bugs.python.org  Tue Dec 17 17:52:05 2013
From: report at bugs.python.org (Peter Otten)
Date: Tue, 17 Dec 2013 16:52:05 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387299125.25.0.411169090556.issue20004@psf.upfronthosting.co.za>


Peter Otten added the comment:

The proposed patch looks fine to me.

And for the record, I don't think setting fieldnames should be promoted in the 3.x documentation. Along the lines of Eric's suggestion I should have written something like

>>> import csv
>>> with open("tmp.csv") as f:
...     for i in range(2):
...             print next(csv.DictReader(f))
... 
{'alpha': '1', 'beta': '2'}
{'epsilon': '5', 'gamma': '3', 'delta': '4'}

which would have spared you the hustle ;)

Thank you for your effort!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:11:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 17:11:51 +0000
Subject: [issue20004] csv.DictReader classic class has a property with setter
In-Reply-To: <1387278593.92.0.0717442259637.issue20004@psf.upfronthosting.co.za>
Message-ID: <1387300311.96.0.472038170499.issue20004@psf.upfronthosting.co.za>


R. David Murray added the comment:

Committed.  Thanks, Peter.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20004>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:30:59 2013
From: report at bugs.python.org (PJ Eby)
Date: Tue, 17 Dec 2013 17:30:59 +0000
Subject: [issue992389] attribute error due to circular import
Message-ID: <1387301459.67.0.676737035568.issue992389@psf.upfronthosting.co.za>


PJ Eby added the comment:

The new patch will have weird results in the case of a parent module that defines an attribute that's later replaced by an import, e.g. if foo/__init__.py defines a variable 'bar' that's a proxy for the foo.bar module.  This is especially problematic if this proxy is used during the process of importing foo.bar

At the very least, this code should NOT be deleting the original foo.bar attribute, but rather restoring its previous value.

All in all, I don't think this is a productive route to take.  It was discussed on Python-dev previously and IIRC I outlined all the other reasons why back then.  The approach in issue17636 is the only one that doesn't change the semantics of any existing, not-currently-broken code.

In contrast, the proposed change here introduces new side-effects and *more* volatile state and temporal coupling.  I don't think this should go in, since the other approach *only* affects execution paths that would currently raise ImportError.

----------
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:34:54 2013
From: report at bugs.python.org (PJ Eby)
Date: Tue, 17 Dec 2013 17:34:54 +0000
Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules
In-Reply-To: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za>
Message-ID: <1387301694.16.0.889709811297.issue17636@psf.upfronthosting.co.za>


PJ Eby added the comment:

Unfortunately, this is not quite true: the weird edge cases for that approach are simply *different*, and harder to diagnose.  ;-)

The approach here can only affect execution paths that would currently raise ImportError; that one can break execution paths that are *currently working*.

As Brett said above, "By declaring what the semantics will be to make the case even possible we are not breaking anything but making something possible."  That is not the case for the approach proposed in the other issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17636>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:52:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 17:52:05 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387302725.33.0.749725088973.issue20007@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 18:52:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 17:52:47 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387302767.03.0.49789879185.issue20007@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/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 19:24:34 2013
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 17 Dec 2013 18:24:34 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1387304674.62.0.335174146229.issue17781@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17781>
_______________________________________

From report at bugs.python.org  Tue Dec 17 20:54:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 19:54:14 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <3dkVRS47Qzz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset ebace0a5a33e by Serhiy Storchaka in branch '2.7':
Issue #20007: HTTPResponse.read(0) no more prematurely closes connection.
http://hg.python.org/cpython/rev/ebace0a5a33e

New changeset 47ae858cd661 by Serhiy Storchaka in branch '3.3':
Issue #20007: HTTPResponse.read(0) no more prematurely closes connection.
http://hg.python.org/cpython/rev/47ae858cd661

New changeset d032245a122c by Serhiy Storchaka in branch 'default':
Issue #20007: HTTPResponse.read(0) no more prematurely closes connection.
http://hg.python.org/cpython/rev/d032245a122c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:02:27 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 17 Dec 2013 20:02:27 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387310547.21.0.876136888458.issue19946@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

Thanks for your hard work Nick!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:05:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 20:05:17 +0000
Subject: [issue20007] .read(0) on http.client.HTTPResponse drops the rest of
 the content
In-Reply-To: <1387290581.03.0.808557642929.issue20007@psf.upfronthosting.co.za>
Message-ID: <1387310717.26.0.241855635585.issue20007@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

2.7 is affected too.

Thank you Simon Sapin for your contribution.

----------
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/issue20007>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:12:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 20:12:52 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1387311172.56.0.914904123903.issue7464@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> test needed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:14:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 20:14:02 +0000
Subject: [issue4492] httplib code thinks it closes connection, but does not
In-Reply-To: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za>
Message-ID: <1387311242.9.0.492113961913.issue4492@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4492>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:17:05 2013
From: report at bugs.python.org (Jim Carroll)
Date: Tue, 17 Dec 2013 20:17:05 +0000
Subject: [issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
In-Reply-To: <1387200881.03.0.963168965941.issue19998@psf.upfronthosting.co.za>
Message-ID: <1387311425.51.0.594767486656.issue19998@psf.upfronthosting.co.za>


Jim Carroll added the comment:

As requested, I've opened the issue with the libffi project:

https://github.com/atgreen/libffi/issues/63

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19998>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:26:33 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 20:26:33 +0000
Subject: [issue12441] _GLOBAL_DEFAULT_TIMEOUT remains as an object() in
 HTTPConnection and the connection hangs
In-Reply-To: <1309346319.84.0.970353674809.issue12441@psf.upfronthosting.co.za>
Message-ID: <1387311993.84.0.46997189066.issue12441@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12441>
_______________________________________

From report at bugs.python.org  Tue Dec 17 21:56:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 20:56:27 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1387313787.83.0.75632181207.issue19524@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't reproduce issue. Python just hangs on read() when socat is used as test server. Perhaps I do something wrong.

----------
nosy: +orsenthil, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.4 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Tue Dec 17 22:21:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Dec 2013 21:21:52 +0000
Subject: [issue16404] Uses of PyLong_FromLong that don't check for errors
In-Reply-To: <1352041027.23.0.922968343734.issue16404@psf.upfronthosting.co.za>
Message-ID: <1387315312.63.0.696719937823.issue16404@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/issue16404>
_______________________________________

From report at bugs.python.org  Tue Dec 17 22:24:33 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 17 Dec 2013 21:24:33 +0000
Subject: [issue20008] Clean up/refactor/make discoverable test_decimal
Message-ID: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za>


New submission from Zachary Ware:

This patch makes extensive changes to test_decimal, with the ultimate goal of making `python -m unittest discover Lib/test/ "test_*.py"` not choke on test_decimal (see issue16748).  Trying to do so uncovered a few other issues, such as some tests not properly cleaning up the context.

Here's a (non-exhaustive) list of what the patch will do:

- Clean up imports, including a repeated import of warnings
- Create a new hierarchy of TestCase subclasses
    - BaseTestCase is an empty subclass of unittest.TestCase to serve
      as a base class for all tests that are meant to test both
      implementations.  This makes it easy to find such tests and
      create the implementation-specific test cases programmatically.
    - DecimalTest defines some methods for all tests:
        - setUp and tearDown, which ensure that the context is set up
          properly and cleaned up properly.  A test that changes the
          context is marked as a failure in tearDown.  These take the
          place of the toplevel init(module) function.
        - assertSignals, formerly toplevel assert_signals.  It has
          also been enhanced to provide the current context if no
          context is given, and to accept strings as signals (which
          are then looked up on the current decimal module to get the
          real exception)
        - assertAndClearFlags, which is a shortcut for
          assertSignals('flags' ...) and clears the flags when done.
          Several tests made no changes to the context except for
          flags, and this was a quick, easy, and convenient way to
          confirm behavior and clean up.
    - CDecimalTest and PyDecimalTest, subclasses of DecimalTest which
      can be inherited from directly by tests that are meant for a
      single implementation (such as C/PyWhitebox, C/PyFunctionality),
      and are inherited by the generated subclasses of the base classes
      (IBMTestCases, FormatTest, etc.)
- Do away with the 'skip_expected' global, use a decorator to skip
  IBMTestCases if the test data can't be found.
- Clean up other toplevel setup code a bit.
- Make vertical spacing more consistent throughout the module.
- Move a couple of tests into `with localcontext()` blocks to avoid
  context pollution.
- Decorate all of CFunctionality with @requires_extra_functionality
  instead of each individual test
- Remove the explicit listing of test classes.
- Remove test_main().
- Add a Doctests base class which runs the doctests via 
  doctest.testmod() and expects a certain number of tests to have been
  run.  Attempts to use doctest.DocTestSuite were stymied by the
  two-headed nature of decimal and _decimal, and would have required a 
  load_tests function to load them anyway.
- Add tearDownModule, which restores the original contexts and checks
  to make sure sys.modules['decimal'] is as expected.
- Convert `if __name__ == '__main__'` argument handling from optparse 
  to argparse.
    - Allow arguments to be passed through to unittest.main().
    - The old method of specifying IBM test case names now requires a
      '--test' or '-t' switch before each set of names (more than one
      -t switch can be present, but each must have at least one name
      following).
    - Add an '--extended'/'-e' switch for switching
      'EXTENDEDERRORTEST', which formerly required editing the file.
- Use unittest.main() for running the script directly.

With the patch test_decimal can be run successfully: directly, by regrtest, or by unittest discovery in Lib/test/; with any acceptable combination of arguments when run directly; with or without _decimal; with or without -OO.  I have not yet been able to test -DEXTRA_FUNCTIONALITY, --without-docstrings, or on any platform but Windows, but I don't expect any issues (of course :).

The patch is against default; 3.3 requires the removal of a usage of subTest and a tweaking of the Doctest expected results.

Any review will be very much appreciated!

Thanks,

Zach

----------
components: Tests
files: test_decimal_cleanup.diff
keywords: needs review, patch
messages: 206482
nosy: ezio.melotti, facundobatista, mark.dickinson, rhettinger, skrah, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up/refactor/make discoverable test_decimal
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33182/test_decimal_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20008>
_______________________________________

From report at bugs.python.org  Tue Dec 17 22:26:38 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 17 Dec 2013 21:26:38 +0000
Subject: [issue16748] Make CPython test package discoverable
In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za>
Message-ID: <1387315598.96.0.527792871071.issue16748@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
dependencies: +Clean up/refactor/make discoverable test_decimal, Fix test discovery for test_codecmaps*.py, Fix test discovery for test_concurrent_futures.py, Support ./python -m unittest in test_socket

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16748>
_______________________________________

From report at bugs.python.org  Tue Dec 17 22:49:55 2013
From: report at bugs.python.org (steven Michalske)
Date: Tue, 17 Dec 2013 21:49:55 +0000
Subject: [issue20009] Property should expose wrapped function.
Message-ID: <1387316995.02.0.931185950843.issue20009@psf.upfronthosting.co.za>


New submission from steven Michalske:

When using the @property decorator the wrapped functions are not exposed for source introspection. (At least I can't see how they are.)

The issue is then that Ipython "%psource" will show the source for the @property as opposed to the function that it wraps.

By implementing the __wrapped__ attribute you can set the wrapped function to fget and then the source for that function can me identified for source introspection.

I perform this hack in code to overcome this issue.

class qproperty(property):
    # Fix for ipython ? and ?? (%pdef, %psource)
    # Omitting the class doc string prevents ipython from showing the
    # doctoring for the property builtin class; I suspect this is a
    # bug.
    def __init__(self, fget=None, fset=None, fdel=None, doc=None):
        super(qproperty, self).__init__(fget, fset, fdel, doc)
        self.__wrapped__ = fget

# Overwrite property with qproperty so that in the future this hack might
# be easily removed.
property = qproperty

This is related to issue #5982.

----------
messages: 206483
nosy: hardkrash
priority: normal
severity: normal
status: open
title: Property should expose wrapped function.
type: enhancement
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20009>
_______________________________________

From report at bugs.python.org  Tue Dec 17 23:38:51 2013
From: report at bugs.python.org (Civa Lin)
Date: Tue, 17 Dec 2013 22:38:51 +0000
Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows
 xp
Message-ID: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za>


New submission from Civa Lin:

On windows xp (Taiwanese) platform...

    c:\> py -c "import time; print(time.strftime('%z', time.localtime()))"

It will raise a UnicodeEncodeError in my system.

I think it's not a +HHMM format and has different behavior with document:
    http://docs.python.org/3/library/time.html#time.strftime

----------
components: Library (Lib), Unicode, Windows
messages: 206484
nosy: civalin, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: time.strftime('%z') didn't make +HHMM return in windows xp
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20010>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:28:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 23:28:43 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <3dkbBz1Xryz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 226c37c209fc by Antoine Pitrou in branch '2.7':
Issue #20006: Fix sporadic failures in test_weakset.
http://hg.python.org/cpython/rev/226c37c209fc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:32:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Dec 2013 23:32:10 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <3dkbGx2v0Rz7Ljk@mail.python.org>


Roundup Robot added the comment:

New changeset a3d86f80c899 by Antoine Pitrou in branch '3.3':
Issue #20006: Fix sporadic failures in test_weakset.
http://hg.python.org/cpython/rev/a3d86f80c899

New changeset 26d92a21f6cf by Antoine Pitrou in branch 'default':
Issue #20006: Fix sporadic failures in test_weakset.
http://hg.python.org/cpython/rev/26d92a21f6cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:32:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Dec 2013 23:32:42 +0000
Subject: [issue20006] Sporadic failures of test_weakset
In-Reply-To: <1387288547.32.0.139263201617.issue20006@psf.upfronthosting.co.za>
Message-ID: <1387323162.16.0.672907350565.issue20006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This was all my fault :) Thanks for reporting!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20006>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:41:25 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Dec 2013 23:41:25 +0000
Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows
 xp
In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za>
Message-ID: <1387323685.59.0.40042221296.issue20010@psf.upfronthosting.co.za>


R. David Murray added the comment:

As the documentation of the module says, we pass this call through to the underlying c library.  What does the Windows documentation say about %z?

A quick google turns up this hit, which seems to indicate it is a platform problem:

http://connect.microsoft.com/VisualStudio/feedback/details/797109/strftime-incorrect-multibyte-encoding-of-timezone-z

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20010>
_______________________________________

From report at bugs.python.org  Wed Dec 18 00:46:53 2013
From: report at bugs.python.org (Civa Lin)
Date: Tue, 17 Dec 2013 23:46:53 +0000
Subject: [issue20010] time.strftime('%z') didn't make +HHMM return in windows
 xp
In-Reply-To: <1387319931.23.0.412917689607.issue20010@psf.upfronthosting.co.za>
Message-ID: <1387324013.19.0.785155538727.issue20010@psf.upfronthosting.co.za>


Civa Lin added the comment:

Oh! Thanks your info!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20010>
_______________________________________

From report at bugs.python.org  Wed Dec 18 01:04:43 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 18 Dec 2013 00:04:43 +0000
Subject: [issue20011] Changing the signature for Parameter's constructor
Message-ID: <1387325083.19.0.919186460465.issue20011@psf.upfronthosting.co.za>


New submission from Antony Lee:

As suggested on python-ideas, this small patch changes the constructor of inspect.Parameter so that "kind" defaults to "POSITIONAL_OR_KEYWORD", which should make code that needs to construct Parameter objects slightly less verbose (as I believe POSITIONAL_OR_KEYWORD is likely the most common kind).

----------
components: Library (Lib)
files: parameter-constructor.patch
keywords: patch
messages: 206490
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Changing the signature for Parameter's constructor
versions: Python 3.5
Added file: http://bugs.python.org/file33183/parameter-constructor.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20011>
_______________________________________

From report at bugs.python.org  Wed Dec 18 03:32:01 2013
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Dec 2013 02:32:01 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1387333921.91.0.6743196516.issue19524@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for looking at this. Perhaps you weren?t pasting the HTTP response into ?socat?. After the six request lines are printed out, I enter the five lines between <HTTP response start> and <HTTP response end>; I didn?t really make this obvious. Otherwise, urlopen() hangs waiting for the response and read() never even gets called.

Here?s a Python-only HTTP server to demonstrate without needing ?socat?. Run this in one terminal:

from http.server import HTTPServer, BaseHTTPRequestHandler
class Handler(BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"
    def do_GET(self):
        self.send_response(200)
        self.send_header("Transfer-Encoding", "chunked")
        self.end_headers()
        self.wfile.write(b"0\r\n\r\n")
HTTPServer(("", 8000), Handler).serve_forever()

. . . and in another terminal:

from urllib.request import urlopen
with urlopen("http://localhost:8000") as response:
    response.read()
import gc; gc.collect()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Wed Dec 18 03:33:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Dec 2013 02:33:10 +0000
Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or
 /usr/sbin
In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>
Message-ID: <3dkgHn3DtHz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset b0fbaed45956 by R David Murray in branch '3.3':
#19855: uuid.get_node now looks on the PATH for executables on unix.
http://hg.python.org/cpython/rev/b0fbaed45956

New changeset 2e856fcb9084 by R David Murray in branch 'default':
Merge: #19855: uuid.get_node now looks on the PATH for executables on unix.
http://hg.python.org/cpython/rev/2e856fcb9084

New changeset 9f9ae5f7c4ae by R David Murray in branch '2.7':
#19855: uuid.get_node now looks on the PATH for executables on unix.
http://hg.python.org/cpython/rev/9f9ae5f7c4ae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19855>
_______________________________________

From report at bugs.python.org  Wed Dec 18 03:40:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Dec 2013 02:40:44 +0000
Subject: [issue19855] uuid._find_mac fails if an executable not in /sbin or
 /usr/sbin
In-Reply-To: <1385910768.71.0.356029979861.issue19855@psf.upfronthosting.co.za>
Message-ID: <1387334444.64.0.526436347251.issue19855@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm on gentoo, so this was causing test runs to fail for me, giving me sufficient motivation to review the patches and commit them :)

Thanks, Serhiy.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19855>
_______________________________________

From report at bugs.python.org  Wed Dec 18 05:56:57 2013
From: report at bugs.python.org (Suzumizaki)
Date: Wed, 18 Dec 2013 04:56:57 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1387342617.93.0.0736492532613.issue9291@psf.upfronthosting.co.za>


Suzumizaki added the comment:

There is possibility that the installation of setuptools fails with
any Windows machine because of this bug. I want change the priority of this issue higher...

I failed the installation of setuptools with Python 2.7.6 on my machine, Windows 8.1 Pro Japanese Edition 64bit, but no problem with both Python 2.7.4 and Python 3.3.3.

----------
nosy: +Suzumizaki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Wed Dec 18 06:05:13 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 18 Dec 2013 05:05:13 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1387343113.5.0.743285261464.issue1100942@psf.upfronthosting.co.za>


Julian Gindi added the comment:

I'm interested in taking over and finishing whatever needs to be completed to move this forward. What else needs to be done? It looks like improved tests are needed, but are there any changes needed to the implementation code?

----------
nosy: +Julian.Gindi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Dec 18 06:15:20 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 Dec 2013 05:15:20 +0000
Subject: [issue19492] Report skipped distutils tests as skipped
In-Reply-To: <1383569864.94.0.187586889245.issue19492@psf.upfronthosting.co.za>
Message-ID: <1387343720.95.0.820170444018.issue19492@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Alright.  Patch looks good, thanks.

----------
assignee: eric.araujo -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19492>
_______________________________________

From report at bugs.python.org  Wed Dec 18 07:10:11 2013
From: report at bugs.python.org (Alexander Boyd)
Date: Wed, 18 Dec 2013 06:10:11 +0000
Subject: [issue20012] Allow Path.relative_to() to accept non-ancestor paths
Message-ID: <1387347011.06.0.0464883312921.issue20012@psf.upfronthosting.co.za>


New submission from Alexander Boyd:

pathlib.Path.relative_to() blows up when given a path that's not an ancestor of the path on which relative_to is being called:

>>> pathlib.Path("/usr/bin").relative_to("/etc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "pathlib.py", line 822, in relative_to
    .format(str(self), str(formatted)))
ValueError: '/usr/bin' does not start with '/etc'

The equivalent with posixpath.relpath (or ntpath.relpath) works just fine:

>>> posixpath.relpath("/usr/bin", "/etc")
'../usr/bin'

It'd be nice if Path.relative_to supported this type of usage.

----------
components: Library (Lib)
messages: 206497
nosy: javawizard, pitrou
priority: normal
severity: normal
status: open
title: Allow Path.relative_to() to accept non-ancestor paths
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20012>
_______________________________________

From report at bugs.python.org  Wed Dec 18 07:24:24 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 06:24:24 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1387347864.28.0.921372049142.issue1100942@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Julian, You need to update the patch from Juarez Bochi and Berker Peksag to the tip.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Dec 18 07:55:45 2013
From: report at bugs.python.org (Anurag Kulkarni)
Date: Wed, 18 Dec 2013 06:55:45 +0000
Subject: [issue20012] Re: Allow Path.relative_to() to accept non-ancestor paths
In-Reply-To: <1387347011.06.0.0464883312921.issue20012@psf.upfronthosting.co.za>
Message-ID: <1387349745.31.0.190734362344.issue20012@psf.upfronthosting.co.za>


Anurag Kulkarni added the comment:

Hey! 
A few changes are required to accomplish what you seek, but results could be severe. Path.relative_to() should return an exception if relative path is not part of the original path. However, I have got a solution for that. I am not that familiar with python and I need you to give me some time. I hope you would acknowledge my efforts.
Regards

----------
nosy: +aukbten
title: Allow Path.relative_to() to accept non-ancestor paths -> Re: Allow Path.relative_to() to accept non-ancestor paths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20012>
_______________________________________

From report at bugs.python.org  Wed Dec 18 08:54:51 2013
From: report at bugs.python.org (Maciej Szulik)
Date: Wed, 18 Dec 2013 07:54:51 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1387353291.79.0.751252480051.issue1100942@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

Julian I'm almost done with this issue. I just need to polish that a little bit and I'll provide working patch withing few hours. Sorry for not writing about that later, but I'm just starting with this and I had some time figuring it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Dec 18 09:34:20 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 18 Dec 2013 08:34:20 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
Message-ID: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>


New submission from Dani?l van Eeden:

When executing DELETE against a SELECTED imap folder the server responds:
---------------------------
a8 SELECT SentMail
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1386063387] UIDs valid
* OK [UIDNEXT 1] Predicted next UID
* OK [NOMODSEQ] No permanent modsequences
a8 OK [READ-WRITE] Select completed (0.001 secs).
a9 delete SentMail
a9 OK Delete completed.
* BYE Selected mailbox was deleted, have to disconnect.
Connection closed by foreign host.
---------------------------

If the same is done with imaplib the exception does not clearly
indicate what happened.

  File "/usr/lib/python2.7/imaplib.py", line 649, in select
    typ, dat = self._simple_command(name, mailbox)
  File "/usr/lib/python2.7/imaplib.py", line 1070, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.7/imaplib.py", line 899, in _command_complete
    raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: SELECT => socket error: EOF

----------
components: Library (Lib)
messages: 206501
nosy: dveeden
priority: normal
severity: normal
status: open
title: imaplib behaviour when deleting selected folder
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 10:41:36 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 18 Dec 2013 09:41:36 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1387359696.16.0.924325095574.issue7464@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

This is still a horrible, horrible, cludge.
I've recently done some work in this area and will suggest a different approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Wed Dec 18 10:49:56 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 09:49:56 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
Message-ID: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> import array
>>> array.array(u'i', [1,2,3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be char, not unicode

In this ticket #13566, Alexandre Vassalotti said:
"We should still fix array in 2.7 to accept unicode object for the typecode though."

So here is the patch to add support for ascii-unicode typecode for array.array constructor.

----------
components: Extension Modules
files: makes_array_accepts_ascii_unicode_typecode.patch
keywords: patch
messages: 206503
nosy: alexandre.vassalotti, vajrasky
priority: normal
severity: normal
status: open
title: Makes array.array constructor accepts ascii-unicode typecode
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file33184/makes_array_accepts_ascii_unicode_typecode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 10:51:31 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 09:51:31 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
 unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1387360291.33.0.171282416051.issue13566@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Alexandre Vassalotti said: "We should still fix array in 2.7 to accept unicode object for the typecode though."

I created issue #20014 (with the patch) for this feature.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13566>
_______________________________________

From report at bugs.python.org  Wed Dec 18 11:13:11 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 10:13:11 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387361591.56.0.815327548179.issue20014@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch with simpler unittest.

----------
Added file: http://bugs.python.org/file33185/makes_array_accepts_ascii_unicode_typecode_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 11:16:07 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 10:16:07 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387361767.76.0.574637033315.issue20014@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33185/makes_array_accepts_ascii_unicode_typecode_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 11:16:19 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 18 Dec 2013 10:16:19 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387361779.24.0.739776682047.issue20014@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33186/makes_array_accepts_ascii_unicode_typecode_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:33:25 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Dec 2013 11:33:25 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za>
Message-ID: <1387366405.33.0.253891062577.issue19619@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Unassigning this one - I don't think the solution we used for 3.4 is appropriate in a maintenance release, but I'm not sure how else to resolve it.

----------
assignee: ncoghlan -> 
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19619>
_______________________________________

From report at bugs.python.org  Wed Dec 18 12:57:24 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 Dec 2013 11:57:24 +0000
Subject: [issue20008] Clean up/refactor/make discoverable test_decimal
In-Reply-To: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za>
Message-ID: <1387367844.47.0.47107486885.issue20008@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Assigning to myself, since my private 100% coverage test suite
would have to be updated as well.

I have just glanced at the patch and only have some superficial
remarks:

In any case, I would prefer a patch without stylistic changes. Elimination of "return" is a personal preference, so are the
whitespace changes.

Listing the tests explicitly is sometimes helpful, e.g. one can
comment out tests when tracking down a refleak.


Curiously enough, testing with a "polluted" context is also useful,
since all functions must handle contexts with flags that are already
set.


Finally, I *suspect* no one is using the command line arguments any
more.  They were probably used heavily during the design phase of
decimal.py.

----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20008>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:25:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 12:25:44 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1387369544.31.0.659595395463.issue19524@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin for clarification. Now I see the problem.

Here is regenerated for Rietveld patch.

Perhaps more safe will be not close socket, but only set the _closed attribute so that it will be closed just after closing SocketIO.

        if h.sock:
            h.sock._closed = True
            h.sock = None

But this is even more tricky.

Yet one approach is to implement __del__() method in the socket.socket class. But this breaks existing tests.

----------
Added file: http://bugs.python.org/file33187/issue19524.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:31:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 12:31:08 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1387369868.78.0.18784564579.issue7464@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide some tests?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:32:02 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Dec 2013 12:32:02 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1387369922.14.0.0971712643172.issue9291@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, that means the issue 15207 fix didn't fix it, since that's in 2.7.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:35:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Dec 2013 12:35:01 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1387370101.93.0.168970945221.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The attached patch just moves the file without leaving an alias behind. It turns out we use this one in a fair few places (mostly for "assert_python_ok").

I'm going to sit on this change for the moment - after reading the docs, it's quite clear that the last couple of functions don't really belong in script_helper, but rather in the pkg_helper module discussed in issue 15376.

So my current plan is to factor that helper out *first*, then when this one lands, the intent of grouping more of the support code that folks working on the test suite might be interested in using together will hopefully be clearer.

----------
dependencies: +Refactor the test_runpy walk_package support code into a common location
Added file: http://bugs.python.org/file33188/issue18576_move_and_document_script_helper.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18576>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:35:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Dec 2013 12:35:14 +0000
Subject: [issue20011] Changing the signature for Parameter's constructor
In-Reply-To: <1387325083.19.0.919186460465.issue20011@psf.upfronthosting.co.za>
Message-ID: <1387370114.47.0.483295709377.issue20011@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you provide a link to the python-ideas discussion, please?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20011>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:37:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Dec 2013 12:37:24 +0000
Subject: [issue18578] Rename and document test.bytecode_helper as
 test.support.bytecode_helper
In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za>
Message-ID: <1387370244.95.0.0504480192825.issue18578@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18578>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:54:44 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Dec 2013 12:54:44 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387371284.09.0.556330755143.issue20013@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks like a bug in the RFC, not including DELETE of current mailbox in the things that cause a transition back to 'authenticated' state.

But yes, a clearer error message would be good.  The code should be handling this correctly, so something odd is going on.  Can you provide an imaplib debug level 5 trace of the session?  That should show the network conversation from imaplib's point of view, as well as a bit about its internal state.

In your imaplib case, I presume the error occurs when you try to issue a new select command?

----------
components: +email
nosy: +barry, r.david.murray
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:55:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 12:55:58 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za>
Message-ID: <1387371358.81.0.349997361521.issue19619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about my comments in msg203841?

See http://comments.gmane.org/gmane.comp.python.devel/143943 for example how hard to get rid of private arguments in public functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19619>
_______________________________________

From report at bugs.python.org  Wed Dec 18 13:56:27 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 12:56:27 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za>
Message-ID: <1387371387.2.0.98217661378.issue19619@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/issue19619>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:04:05 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Dec 2013 13:04:05 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <1387371387.23.0.501494685694.issue19619@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fbm1VFe9XpCxTeK4yYXAuSPQgMDDfR4pwj=EoCZ+BEhQ@mail.gmail.com>


Nick Coghlan added the comment:

I was planning to fix pydoc to not show private keyword only arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19619>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:10:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 13:10:28 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387372228.61.0.977799519775.issue20014@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think a patch can be much simpler. Perhaps make "c" to accept 1-character Unicode objects?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:17:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 13:17:48 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <CADiSq7fbm1VFe9XpCxTeK4yYXAuSPQgMDDfR4pwj=EoCZ+BEhQ@mail.gmail.com>
Message-ID: <3102921.MBxQ2817CR@raxxla>


Serhiy Storchaka added the comment:

If people don't pay attention on explicit warning not to use certain 
parameters, is the lack of documentation will stop them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19619>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:21:55 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 18 Dec 2013 13:21:55 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387372915.46.0.531638701033.issue20013@psf.upfronthosting.co.za>


Changes by Dani?l van Eeden <launchpad at myname.nl>:


Added file: http://bugs.python.org/file33189/test_san.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 14:22:26 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 18 Dec 2013 13:22:26 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387372946.36.0.996303329483.issue20013@psf.upfronthosting.co.za>


Dani?l van Eeden added the comment:

I've replace the user and password in both the test script and the log.

----------
Added file: http://bugs.python.org/file33190/imaplib_issue20013_san.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:17:18 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 18 Dec 2013 14:17:18 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1387376238.16.0.150667687918.issue1100942@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Maciej, cool! I just wanted to move this patch forward because A) it seemed inactive and B) I would love to see this feature make it in :) I guess that means there is nothing that I need to do. Looking forward to this one, good work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:33:11 2013
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 18 Dec 2013 14:33:11 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1387377191.08.0.888735171318.issue1100942@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:37:43 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Dec 2013 14:37:43 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387377463.44.0.226717269242.issue20013@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please try the attached patch and let me know if it improves things.

If it works, figuring out how to write a test for this is going to be the hard part.  The imaplib tests don't have very good coverage, even in python3 where there are at least more of them.

----------
keywords: +patch
Added file: http://bugs.python.org/file33191/check_bye.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:44:50 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Wed, 18 Dec 2013 14:44:50 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387377890.09.0.0228153787467.issue20013@psf.upfronthosting.co.za>


Dani?l van Eeden added the comment:

The patch doesn't seem to change the behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:48:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Dec 2013 14:48:42 +0000
Subject: [issue19492] Report skipped distutils tests as skipped
In-Reply-To: <1383569864.94.0.187586889245.issue19492@psf.upfronthosting.co.za>
Message-ID: <3dkzcT0JVSz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset b3f3e6afe966 by Serhiy Storchaka in branch '3.3':
Issue #19492: Silently skipped distutils tests now reported as skipped.
http://hg.python.org/cpython/rev/b3f3e6afe966

New changeset da3472687566 by Serhiy Storchaka in branch 'default':
Issue #19492: Silently skipped distutils tests now reported as skipped.
http://hg.python.org/cpython/rev/da3472687566

New changeset d5b0bb2a1790 by Serhiy Storchaka in branch '2.7':
Issue #19492: Silently skipped distutils tests now reported as skipped.
http://hg.python.org/cpython/rev/d5b0bb2a1790

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19492>
_______________________________________

From report at bugs.python.org  Wed Dec 18 15:50:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 14:50:37 +0000
Subject: [issue19492] Report skipped distutils tests as skipped
In-Reply-To: <1383569864.94.0.187586889245.issue19492@psf.upfronthosting.co.za>
Message-ID: <1387378237.34.0.383060232814.issue19492@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Arfrever, Zachary and ?ric for reviews.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19492>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:33:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Dec 2013 15:33:33 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387380813.79.0.84560006848.issue20013@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  The BYE isn't issued until the next command is successfully transmitted.  I'd call that a broken server, but obviously it's what you have to deal with, so we should handle it.

Try this version.

----------
Added file: http://bugs.python.org/file33192/check_bye.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:40:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2013 15:40:05 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>
Message-ID: <1387381205.15.0.556749838946.issue19997@psf.upfronthosting.co.za>


STINNER Victor added the comment:

imghdr_bytes.patch should use os.fsencode() to encode the filename, not filename.encode().

(You may use a valid sound file of the Python suite test instead of generating an invalid sounf file.)

imghdr_files.patch looks overkill. I don't think that it's useful to support integer file descriptor. Being able to pass an open file is enough. imghdr_bytes.patch is fine.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:41:59 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 18 Dec 2013 15:41:59 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>
Message-ID: <1387381319.08.0.710758788329.issue19997@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Hi, Victor! The second patch does use os.fsencode. I'll update the first one with this change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:53:25 2013
From: report at bugs.python.org (Derek Wilson)
Date: Wed, 18 Dec 2013 15:53:25 +0000
Subject: [issue8220] site.py's Quitter pollutes builtins with exit and quit
 for non-interactive use
In-Reply-To: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>
Message-ID: <1387382005.61.0.0899444994694.issue8220@psf.upfronthosting.co.za>


Derek Wilson added the comment:

could this be reconsidered for 3.5+? most of the legacy code that you were worried about breaking would not port without tonnes of work anyway.

it would also be nice to modify quitter's repr actually exit (so you don't get that ridiculously annoying "Use exit() or Ctrl-D (i.e. EOF) to exit" message). but that would be dangerous to do if it were not available only in the interactive interpreter. while that is my motivation for wanting quitter out of the global namespace, i do understand that is a different ticket. which i will submit. :-)

----------
nosy: +underrun
versions: +Python 3.5 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8220>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:58:07 2013
From: report at bugs.python.org (Tim Golden)
Date: Wed, 18 Dec 2013 15:58:07 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1387369922.14.0.0971712643172.issue9291@psf.upfronthosting.co.za>
Message-ID: <52B1C60C.9060306@timgolden.me.uk>


Tim Golden added the comment:

I'll try to look at this soonish. Thanks for bringing it back to the
surface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Wed Dec 18 16:59:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 15:59:26 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
Message-ID: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In most cases when str object required, unicode object is allowed too. "s" and "z" codes (with modifiers) in PyArg_Parse*() accept both str and unicode instances. But "c" code accepts only 1-character str, not unicode. This makes harder writing version-agnostic code with imported unicode_literals (2.7 functions require bytes literals, 3.x functions require unicode literals) and breaks pickle compatibility (see issue13566).

This change will affect:

* str.ljust(), str.rjust() and str.center();
* '%c' % char;
* mmap.write_byte();
* array constructor and item setter for 'c' type;
* datetime.isoformat();
* bsddb.set_re_delim() and bsddb.set_re_pad();
* msvcrt.putch() and msvcrt.ungetch();
* swi.block.padstring().

----------
components: Interpreter Core
files: getargs_c_unicode.patch
keywords: patch
messages: 206529
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Allow 1-character ASCII unicode where 1-character str is required
versions: Python 2.7
Added file: http://bugs.python.org/file33193/getargs_c_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:00:10 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Dec 2013 16:00:10 +0000
Subject: [issue8220] site.py's Quitter pollutes builtins with exit and quit
 for non-interactive use
In-Reply-To: <1269442357.88.0.102314417571.issue8220@psf.upfronthosting.co.za>
Message-ID: <1387382410.87.0.950358371153.issue8220@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I still don't think it's worth the potential breakage to remove these from the built-in namespace; there is enough code in Python 3 to not warrant breaking them, nor making any porting harder for those still on Python 2. You can ask on python-dev, though, to see how other core devs feel because I don't feel strongly enough to block it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8220>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:00:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 16:00:59 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387382459.85.0.282989835544.issue20014@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue20015 for more general and simple solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:02:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 16:02:15 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
 unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1387382535.58.0.552079096773.issue13566@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue20015 for more general approach.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13566>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:02:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2013 16:02:38 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za>
Message-ID: <1387382558.11.0.105243866751.issue20015@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't like the heuristic of "ASCII only" characters. Accepting that may lead to bugs if later you pass a non-ASCII character.

And is it not too late to change that in Python 2.7? Version released 3 years ago and widely used in production.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:04:13 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 Dec 2013 16:04:13 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za>
Message-ID: <1387382653.3.0.667449250385.issue20015@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I guess it makes porting to Python 3 easier, but can we do this in a
stable release?

----------
nosy: +benjamin.peterson, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:07:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Dec 2013 16:07:27 +0000
Subject: [issue20012] Re: Allow Path.relative_to() to accept non-ancestor paths
In-Reply-To: <1387347011.06.0.0464883312921.issue20012@psf.upfronthosting.co.za>
Message-ID: <1387382847.63.0.295086956018.issue20012@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That's by design. If /etc is a symlink to e.g. /mnt/etc, the proposed result is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20012>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:08:33 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2013 16:08:33 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
 unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1387382913.03.0.291937470405.issue13566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> If you pickle an array object on python 3 the typecode is encoded as a unicode string rather than as a byte string.  This makes python 2 reject the pickle.

Pickles files of Python 3 are supposed to be compatible with Python 2?

It looks very tricky to produce pickle files compatible with both versions.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13566>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:10:15 2013
From: report at bugs.python.org (Derek Wilson)
Date: Wed, 18 Dec 2013 16:10:15 +0000
Subject: [issue20016] make site.py Quitter call itself on repr
Message-ID: <1387383015.85.0.019158387414.issue20016@psf.upfronthosting.co.za>


New submission from Derek Wilson:

calling exit() or quit() is actually very cumbersome especially as most other commandline tools that have a command interface allow you to exit or quit by typing exit or quit and not by calling a function.

if quitter's builtins are only available in the interactive interpreter this seems like it would be perfectly safe. now that we are looking at 3.x going forward, perhaps we can reopen this: http://bugs.python.org/issue8220

----------
components: Extension Modules
files: quit_from_repr.patch
keywords: patch
messages: 206537
nosy: underrun
priority: normal
severity: normal
status: open
title: make site.py Quitter call itself on repr
versions: Python 3.5
Added file: http://bugs.python.org/file33194/quit_from_repr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20016>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:33:28 2013
From: report at bugs.python.org (Hugo.Lol)
Date: Wed, 18 Dec 2013 16:33:28 +0000
Subject: [issue20017] SimpleHTTPServer: UnicodeDecodeError on Windows 8
 (64-bit)
Message-ID: <1387384408.95.0.919714643908.issue20017@psf.upfronthosting.co.za>


New submission from Hugo.Lol:

Running Windows 8 (64-bit) and Python 2.7.6 (64-bit).

> python -m SimpleHTTPServer
Traceback (most recent call last):
  File "C:\Python27\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python27\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Python27\lib\SimpleHTTPServer.py", line 27, in <module>
    class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  File "C:\Python27\lib\SimpleHTTPServer.py", line 208, in SimpleHTTPRequestHand
ler
    mimetypes.init() # try to read system mime.types
  File "C:\Python27\lib\mimetypes.py", line 358, in init
    db.read_windows_registry()
  File "C:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
    for subkeyname in enum_types(hkcr):
  File "C:\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 2: ordinal
not in range(128)

----------
components: Unicode, Windows
messages: 206538
nosy: Hugo.Lol, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: SimpleHTTPServer: UnicodeDecodeError on Windows 8 (64-bit)
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20017>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:34:51 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2013 16:34:51 +0000
Subject: [issue20017] SimpleHTTPServer: UnicodeDecodeError on Windows 8
 (64-bit)
In-Reply-To: <1387384408.95.0.919714643908.issue20017@psf.upfronthosting.co.za>
Message-ID: <1387384491.56.0.805452090375.issue20017@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue is a duplicate of #9291.

----------
resolution:  -> fixed
status: open -> closed
superseder:  -> mimetypes initialization fails on Windows because of non-Latin characters in registry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20017>
_______________________________________

From report at bugs.python.org  Wed Dec 18 17:35:35 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Dec 2013 16:35:35 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1387384535.21.0.8221264886.issue9291@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Issue #20017 has been marked as a duplicate of this issue. Copy of the message:

Running Windows 8 (64-bit) and Python 2.7.6 (64-bit).

> python -m SimpleHTTPServer
Traceback (most recent call last):
  File "C:\Python27\lib\runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Python27\lib\runpy.py", line 72, in _run_code
    exec code in run_globals
  File "C:\Python27\lib\SimpleHTTPServer.py", line 27, in <module>
    class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  File "C:\Python27\lib\SimpleHTTPServer.py", line 208, in SimpleHTTPRequestHand
ler
    mimetypes.init() # try to read system mime.types
  File "C:\Python27\lib\mimetypes.py", line 358, in init
    db.read_windows_registry()
  File "C:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
    for subkeyname in enum_types(hkcr):
  File "C:\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd7 in position 2: ordinal
not in range(128)

----------
nosy: +Hugo.Lol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Wed Dec 18 18:00:21 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 18 Dec 2013 17:00:21 +0000
Subject: [issue20016] make site.py Quitter call itself on repr
In-Reply-To: <1387383015.85.0.019158387414.issue20016@psf.upfronthosting.co.za>
Message-ID: <1387386021.19.0.356199577181.issue20016@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

-1 that would be weird behavior; typing a function name shouldn't run it. Python on the command line is still Python.

----------
nosy: +Ramchandra Apte

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20016>
_______________________________________

From report at bugs.python.org  Wed Dec 18 18:17:27 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Wed, 18 Dec 2013 17:17:27 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>
Message-ID: <1387387047.2.0.45774276893.issue19997@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Added the new version.

> (You may use a valid sound file of the Python suite test instead of generating an invalid sounf file.)

Oh, that's sndhdr, currently imghdr doesn't have valid image files in the Python suite test (there is another issue for adding a test file for this module). If it's required, sure, I'll add a few.

----------
Added file: http://bugs.python.org/file33195/imghdr_files_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Wed Dec 18 18:33:00 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 18 Dec 2013 17:33:00 +0000
Subject: [issue20011] Changing the signature for Parameter's constructor
In-Reply-To: <1387325083.19.0.919186460465.issue20011@psf.upfronthosting.co.za>
Message-ID: <1387387980.72.0.128129665991.issue20011@psf.upfronthosting.co.za>


Antony Lee added the comment:

Nobody replied so far...
https://mail.python.org/pipermail/python-ideas/2013-December/024538.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20011>
_______________________________________

From report at bugs.python.org  Wed Dec 18 18:39:47 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 Dec 2013 17:39:47 +0000
Subject: [issue20016] make site.py Quitter call itself on repr
In-Reply-To: <1387383015.85.0.019158387414.issue20016@psf.upfronthosting.co.za>
Message-ID: <1387388387.1.0.336117424093.issue20016@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Sorry, it is a deliberate choice to not have reprs have side-effects, espercially as important as quitting the interpreter.  The repr of quit/exit is used in places such as pydoc help; it would be bad to quit when the user wants to see documentation, for example.

----------
components: +Library (Lib) -Extension Modules
nosy: +eric.araujo
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20016>
_______________________________________

From report at bugs.python.org  Wed Dec 18 18:39:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 17:39:56 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
In-Reply-To: <1387382558.11.0.105243866751.issue20015@psf.upfronthosting.co.za>
Message-ID: <1413415.D7Yls91GN1@raxxla>


Serhiy Storchaka added the comment:

> I don't like the heuristic of "ASCII only" characters. Accepting that may
> lead to bugs if later you pass a non-ASCII character.

What behavior you propose for non-ASCII values?

> And is it not too late to change that in Python 2.7? Version released 3
> years ago and widely used in production.

Python 3 released 5 years ago, but many peoples still support and write 
new software on Python 2. While 2.7 in use, new 2.7 versions which 
help porting and interoperability with Python 3 will be desirable.

See also issue19099.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:02:27 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 18 Dec 2013 18:02:27 +0000
Subject: [issue20008] Clean up/refactor/make discoverable test_decimal
In-Reply-To: <1387315472.11.0.523562380055.issue20008@psf.upfronthosting.co.za>
Message-ID: <1387389747.72.0.229472245916.issue20008@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Stefan Krah wrote:
> In any case, I would prefer a patch without stylistic changes.
> Elimination of "return" is a personal preference, so are the
> whitespace changes.

The returns were removed in #19572, to reduce false positives in searching for silently skipped tests.  I have no strong opinion on them beyond that; if you want them back I can put them back :)

The whitespace removals are just to make the test module consistent with itself, and I personally think it looks better with the removals.  I can put the blank lines back too if need be.  I don't think there are any stylistic changes that aren't also code changes beyond the blank lines removed.

> Listing the tests explicitly is sometimes helpful, e.g. one can
> comment out tests when tracking down a refleak.

The same can be accomplished by either deleting the test case after it is created (which wouldn't take much more editing of the file than commenting it out), or by using e.g. `python -m test.test_decimal CFormatTest CWhitebox PyDoctests` to run a particular set of tests without having to edit the file at all.  It would also be simple enough to add another command line switch to only run the tests on the specified implementation.

> Curiously enough, testing with a "polluted" context is also useful,
> since all functions must handle contexts with flags that are already
> set.

True, but the real problem I ran into was tests changing the precision of the context, not changing it back, and the next test expecting the original precision (or a test expects a changed precision but gets the original).  I'm fine with losing all of the new 'assertAndClearFlags' calls and the checking of flags (and even traps) in tearDown, but the precision changes cause headaches dependent upon test execution order.  In fact, the only reason the tests pass right now is because of their ordering; if you random.shuffle(test_classes) before run_unittest(*test_classes), a few different failures pop up.

Another option would be to add another command line option to set random flags before each test.

(Note that I'm not terribly attached to either of the new command line options I've suggested in this message.  They're just ideas I've had while thinking about your message, and have an idea how either could be implemented pretty easily if anyone else thought it was worthwhile since the command line parsing structure is already there.  I don't plan to do anything with them without agreement from others.)

> Finally, I *suspect* no one is using the command line arguments any
> more.  They were probably used heavily during the design phase of
> decimal.py.

That may well be.  It doesn't hurt anything to keep them, but it would make the patch quite a bit simpler to remove them.  It might be useful in future though, and doesn't add that much more complexity to the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20008>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:22:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Dec 2013 18:22:49 +0000
Subject: [issue20005] Minor typo in operator documentation
Message-ID: <3dl4MX2Yfgz7LjW@mail.python.org>


New submission from Roundup Robot:

New changeset f0eed36bab4c by Zachary Ware in branch '2.7':
Issue #20005: Fix typo in operator docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/f0eed36bab4c

New changeset 17244b5df8b6 by Zachary Ware in branch '3.3':
Issue #20005: Fix typo in operator docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/17244b5df8b6

New changeset a4a00e220e08 by Zachary Ware in branch 'default':
Closes #20005: Fix typo in operator docs.  Patch by Claudiu Popa.
http://hg.python.org/cpython/rev/a4a00e220e08

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20005>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:23:31 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 18 Dec 2013 18:23:31 +0000
Subject: [issue20005] Minor typo in operator documentation
In-Reply-To: <3dl4MX2Yfgz7LjW@mail.python.org>
Message-ID: <1387391011.32.0.320953858545.issue20005@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report and patch!

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20005>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:52:35 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Wed, 18 Dec 2013 18:52:35 +0000
Subject: [issue20018] Replace dead URL with link to mirror
Message-ID: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>


New submission from Jeroen Van Goey:

The header of a cookie file generated by _MozillaCookieJar.py contains a link to the spec: http://www.netscape.com/newsref/std/cookie_spec.html

This URL no longer exists (redirects to the AOL homepage). Attached patch replaces the link with a mirror where the original text is hosted.

----------
assignee: docs at python
components: Documentation
files: _MozillaCookieJar.diff
keywords: patch
messages: 206549
nosy: docs at python, jeroen-vangoey, loewis
priority: normal
severity: normal
status: open
title: Replace dead URL with link to mirror
type: enhancement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33196/_MozillaCookieJar.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20018>
_______________________________________

From report at bugs.python.org  Wed Dec 18 19:53:25 2013
From: report at bugs.python.org (Jeroen Van Goey)
Date: Wed, 18 Dec 2013 18:53:25 +0000
Subject: [issue20018] Replace dead URL with link to mirror
In-Reply-To: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>
Message-ID: <1387392805.85.0.293241071654.issue20018@psf.upfronthosting.co.za>


Jeroen Van Goey added the comment:

Added patch file for Python 3.3

----------
Added file: http://bugs.python.org/file33197/cookiejar.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20018>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:17:53 2013
From: report at bugs.python.org (Cory Benfield)
Date: Wed, 18 Dec 2013 21:17:53 +0000
Subject: [issue19996] httplib infinite read on invalid header
In-Reply-To: <1387194945.4.0.440069571587.issue19996@psf.upfronthosting.co.za>
Message-ID: <1387401473.08.0.398234669245.issue19996@psf.upfronthosting.co.za>


Cory Benfield added the comment:

Ok, here's a patch for 2.7 as well.

I decided to allow the empty header names in rfc822.py as well, if only because I wanted the changed parsing code to match. If anyone thinks that's an excessive change, I'll happily remove it.

----------
Added file: http://bugs.python.org/file33198/hdrs_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19996>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:36:37 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 18 Dec 2013 21:36:37 +0000
Subject: [issue19902] logging docs don't document integer constants
In-Reply-To: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>
Message-ID: <1387402597.89.0.361188030875.issue19902@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

The levels are documented here:

http://docs.python.org/howto/logging.html#logging-levels

----------
nosy: +vinay.sajip
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19902>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:37:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Dec 2013 21:37:19 +0000
Subject: [issue20018] Replace dead URL with link to mirror
In-Reply-To: <1387392755.61.0.550067417471.issue20018@psf.upfronthosting.co.za>
Message-ID: <3dl8gy53ZXz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 656a40666937 by Benjamin Peterson in branch '3.3':
update url to spec (closes #20018)
http://hg.python.org/cpython/rev/656a40666937

New changeset c0dc1400866a by Benjamin Peterson in branch '2.7':
update url to spec (closes #20018)
http://hg.python.org/cpython/rev/c0dc1400866a

New changeset 5f5e1d408c0c by Benjamin Peterson in branch 'default':
merge 3.3 (#20018)
http://hg.python.org/cpython/rev/5f5e1d408c0c

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20018>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:37:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 21:37:39 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387402659.76.0.0894413821896.issue18879@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately last patch causes resource leak on 3.3+.

$ ./python -Wall -m test.regrtest test_tempfile
[1/1] test_tempfile
1 test OK.
sys:1: ResourceWarning: gc: 5 uncollectable objects at shutdown; use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:57:25 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 21:57:25 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1387403845.28.0.0101272398039.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Marc-Andre, do you have comments or objections?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Wed Dec 18 22:58:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 21:58:50 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1387403930.87.0.236753450319.issue19020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is your opinion, Terry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Wed Dec 18 23:02:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 22:02:08 +0000
Subject: [issue19380] Optimize parsing of regular expressions
In-Reply-To: <1382645659.73.0.868235602026.issue19380@psf.upfronthosting.co.za>
Message-ID: <1387404128.12.0.525773297528.issue19380@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could someone please make a review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19380>
_______________________________________

From report at bugs.python.org  Wed Dec 18 23:08:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Dec 2013 22:08:55 +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: <1387404535.5.0.472462424816.issue2175@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +christian.heimes
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Wed Dec 18 23:16:53 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 Dec 2013 22:16:53 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1387403845.28.0.0101272398039.issue5815@psf.upfronthosting.co.za>
Message-ID: <52B21ECE.3040908@egenix.com>


Marc-Andre Lemburg added the comment:

On 18.12.2013 22:57, Serhiy Storchaka wrote:
> 
> Marc-Andre, do you have comments or objections?

Your last patch looks fine, but I don't have time to test it.

Regarding the broken *devanagari* entries in the alias table:
I think we should remove or correct those.

The purpose of normalize() is to return a valid libc locale
identifier and if the values in the alias table are clearly
wrong and don't work with libc, there's little point in keeping
them, even if the X11 file still lists them with the wrong
notation.

If we can fix them so that they do work with libc, let's do that.
If we can't let's remove them. In both cases, please add a comment
mentioning the case and why things were changed/removed.

Hope that helps. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:01:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 18 Dec 2013 23:01:42 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387407702.15.0.364729411361.issue19946@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The commit broken a couple of buildbots like all Windows bots and OpenIndiana.

----------
nosy: +christian.heimes
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:08:47 2013
From: report at bugs.python.org (Wes)
Date: Wed, 18 Dec 2013 23:08:47 +0000
Subject: [issue20019] platform.py line _sys_version function
Message-ID: <1387408127.09.0.79406077892.issue20019@psf.upfronthosting.co.za>


New submission from Wes:

Marc-Andre,
I'm on a Macbook pro OSX Mountain Lion

I've been automating virtual environment builds locally and remotely, but it seems that when my "pip install -r requirements.txt" tries to run and download.py in pip/ runs it invokes "platform.py".  I'm getting a user-agent issue from the _sys_version function.  Here is the error:



  File "/Users/me/anaconda/lib/python2.7/platform.py", line 1500, in python_implementation
    return _sys_version()[0]

  File "/Users/me/anaconda/lib/python2.7/platform.py", line 1464, in _sys_version
    repr(sys_version))
ValueError: failed to parse CPython sys.version: '2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]'


I've found the following stack that also references this error:

http://stackoverflow.com/questions/19105255/praw-failed-to-parse-cpython-sys-version-when-creating-reddit-object

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 206560
nosy: lemburg, wesmadrigal
priority: normal
severity: normal
status: open
title: platform.py line _sys_version function
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:17:13 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 Dec 2013 23:17:13 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <1387408127.09.0.79406077892.issue20019@psf.upfronthosting.co.za>
Message-ID: <1387408633.53.0.923763440705.issue20019@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I have tried this with a stock Python 2.7.6 version and don't get an error:

>>> platform._sys_version('2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]')
('CPython', '2.7.5', '', '', 'default', 'Sep 12 2013 21:33:34', 'GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)')

The stackoverflow posting you mentioned obviously uses a Python version that was modified in incompatible ways, so it doesn't apply here.

Are you running an Apple version of Python or one that was installed using the python.org installer ?

----------
components: +Library (Lib) -2to3 (2.x to 3.x conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:39:45 2013
From: report at bugs.python.org (Wes)
Date: Wed, 18 Dec 2013 23:39:45 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <1387408633.53.0.923763440705.issue20019@psf.upfronthosting.co.za>
Message-ID: <CADQwG8taOwe9DRV8H6TnAsCYRDtfreC+LT9sNxj1+9Y-DVaatA@mail.gmail.com>


Wes added the comment:

Marc

Thanks for getting back to me so quickly on this.  I'm running an apple
version of python from the looks of it.  I was running an Anaconda version
at the time I posted this script, but I just reset my $PATH variable to use
the mac factory python and still got the error.

Python 2.7.5 (default, Sep 12 2013, 21:33:34)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

On Wed, Dec 18, 2013 at 5:17 PM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg added the comment:
>
> I have tried this with a stock Python 2.7.6 version and don't get an error:
>
> >>> platform._sys_version('2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC
> 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)]')
> ('CPython', '2.7.5', '', '', 'default', 'Sep 12 2013 21:33:34', 'GCC 4.2.1
> Compatible Apple LLVM 5.0 (clang-500.0.68)')
>
> The stackoverflow posting you mentioned obviously uses a Python version
> that was modified in incompatible ways, so it doesn't apply here.
>
> Are you running an Apple version of Python or one that was installed using
> the python.org installer ?
>
> ----------
> components: +Library (Lib) -2to3 (2.x to 3.x conversion tool)
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20019>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:46:43 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 18 Dec 2013 23:46:43 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <CADQwG8taOwe9DRV8H6TnAsCYRDtfreC+LT9sNxj1+9Y-DVaatA@mail.gmail.com>
Message-ID: <52B233DD.2080701@egenix.com>


Marc-Andre Lemburg added the comment:

On 19.12.2013 00:39, Wes wrote:
> 
> Marc
> 
> Thanks for getting back to me so quickly on this.  I'm running an apple
> version of python from the looks of it.  I was running an Anaconda version
> at the time I posted this script, but I just reset my $PATH variable to use
> the mac factory python and still got the error.
> 
> Python 2.7.5 (default, Sep 12 2013, 21:33:34)
> [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.

That looks pretty much the same.

I suspect that either Apple changed something in their Python
version or that pip is picking up a non-standard platform.py
from somewhere.

Could you check platform.__file__ and sys.version ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:52:16 2013
From: report at bugs.python.org (Wes)
Date: Wed, 18 Dec 2013 23:52:16 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <52B233DD.2080701@egenix.com>
Message-ID: <CADQwG8s__6-b9iFB-k-LHhOkCbO8BxMtYyEmxP2wScLY7qdZAw@mail.gmail.com>


Wes added the comment:

Marc,

Here was the initial output:

>>> platform.__file__
'/Users/wesmadrigal/anaconda/lib/python2.7/platform.pyc'
>>> import sys
>>> sys.version
'2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Nov 11 2013, 10:49:09) \n[GCC
4.0.1 (Apple Inc. build 5493)]'

Here is what I had when I reverted back to the standard $PATH that comes
stock in Mac OSX Mountain Lion on this new Macbook Pro:

>>> platform.__file__
'/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.pyc'
>>> import sys
>>> sys.version
'2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple LLVM
5.0 (clang-500.0.68)]'

On Wed, Dec 18, 2013 at 5:46 PM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg added the comment:
>
> On 19.12.2013 00:39, Wes wrote:
> >
> > Marc
> >
> > Thanks for getting back to me so quickly on this.  I'm running an apple
> > version of python from the looks of it.  I was running an Anaconda
> version
> > at the time I posted this script, but I just reset my $PATH variable to
> use
> > the mac factory python and still got the error.
> >
> > Python 2.7.5 (default, Sep 12 2013, 21:33:34)
> > [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
> > Type "help", "copyright", "credits" or "license" for more information.
>
> That looks pretty much the same.
>
> I suspect that either Apple changed something in their Python
> version or that pip is picking up a non-standard platform.py
> from somewhere.
>
> Could you check platform.__file__ and sys.version ?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20019>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 00:53:47 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Dec 2013 23:53:47 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <1387408127.09.0.79406077892.issue20019@psf.upfronthosting.co.za>
Message-ID: <1387410827.35.0.629933045509.issue20019@psf.upfronthosting.co.za>


Ned Deily added the comment:

The version string does not match either the Apple-supplied Python in 10.8 (Mountain Lion) nor that of a python.org Python.  The "anaconda" directory name suggests this is probably a Python from the Anaconda Scientific distribution.  There have been other issues with _sys_version as reported on their bug tracker; see https://github.com/ContinuumIO/anaconda-issues/search?q=_sys_version&type=Issues

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 01:08:12 2013
From: report at bugs.python.org (Wes)
Date: Thu, 19 Dec 2013 00:08:12 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <1387410827.35.0.629933045509.issue20019@psf.upfronthosting.co.za>
Message-ID: <CADQwG8uPQ0LPfzR-bT_O3nYeVFDQxmS8UU0=UObwiFwvn8F6=w@mail.gmail.com>


Wes added the comment:

I just commented out the _sys_version_parser regular expression in
anaconda/lib/python2.7/platform.py on line 1363 and replaced it with the
_sys_version_parser from /usr/lib/python2.7/platform.py and everything
worked fine.

On Wed, Dec 18, 2013 at 5:53 PM, Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily added the comment:
>
> The version string does not match either the Apple-supplied Python in 10.8
> (Mountain Lion) nor that of a python.org Python.  The "anaconda"
> directory name suggests this is probably a Python from the Anaconda
> Scientific distribution.  There have been other issues with _sys_version as
> reported on their bug tracker; see
> https://github.com/ContinuumIO/anaconda-issues/search?q=_sys_version&type=Issues
>
> ----------
> nosy: +ned.deily
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20019>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 01:08:52 2013
From: report at bugs.python.org (Wes)
Date: Thu, 19 Dec 2013 00:08:52 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <CADQwG8uPQ0LPfzR-bT_O3nYeVFDQxmS8UU0=UObwiFwvn8F6=w@mail.gmail.com>
Message-ID: <CADQwG8uKztWWSQHdw1CXZe3g4zr-EK9v+3cCKSkEGgxtLPdreA@mail.gmail.com>


Wes added the comment:

The shitty part is, you pretty much need anaconda to run iPython notebook
on a mac.

On Wed, Dec 18, 2013 at 6:08 PM, Wes Madrigal <wesley7879 at gmail.com> wrote:

> I just commented out the _sys_version_parser regular expression in
> anaconda/lib/python2.7/platform.py on line 1363 and replaced it with the
> _sys_version_parser from /usr/lib/python2.7/platform.py and everything
> worked fine.
>
>
> On Wed, Dec 18, 2013 at 5:53 PM, Ned Deily <report at bugs.python.org> wrote:
>
>>
>> Ned Deily added the comment:
>>
>> The version string does not match either the Apple-supplied Python in
>> 10.8 (Mountain Lion) nor that of a python.org Python.  The "anaconda"
>> directory name suggests this is probably a Python from the Anaconda
>> Scientific distribution.  There have been other issues with _sys_version as
>> reported on their bug tracker; see
>> https://github.com/ContinuumIO/anaconda-issues/search?q=_sys_version&type=Issues
>>
>> ----------
>> nosy: +ned.deily
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue20019>
>> _______________________________________
>>
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 01:14:06 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 19 Dec 2013 00:14:06 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <CADQwG8s__6-b9iFB-k-LHhOkCbO8BxMtYyEmxP2wScLY7qdZAw@mail.gmail.com>
Message-ID: <52B23A47.1090409@egenix.com>


Marc-Andre Lemburg added the comment:

On 19.12.2013 00:52, Wes wrote:
> 
> Marc,
> 
> Here was the initial output:
> 
>>>> platform.__file__
> '/Users/wesmadrigal/anaconda/lib/python2.7/platform.pyc'
>>>> import sys
>>>> sys.version
> '2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Nov 11 2013, 10:49:09) \n[GCC
> 4.0.1 (Apple Inc. build 5493)]'

The part '|Anaconda 1.8.0 (x86_64)|' in that string is not standard
Python conform and as a result, the platform.py parser fails.

You'll have to open a ticket with the Anaconda vendor to get this
fixed.

> Here is what I had when I reverted back to the standard $PATH that comes
> stock in Mac OSX Mountain Lion on this new Macbook Pro:
> 
>>>> platform.__file__
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.pyc'
>>>> import sys
>>>> sys.version
> '2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple LLVM
> 5.0 (clang-500.0.68)]'

This should parse correctly with the stock platform.py parser.

The only explanation I have is that the platform.py installed
on your machine is not the original one that comes with the
Python 2.7.5 we distribute from python.org.

I don't have a Mac OSX notebook available to check, so can't
really help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 01:20:57 2013
From: report at bugs.python.org (Wes)
Date: Thu, 19 Dec 2013 00:20:57 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <52B23A47.1090409@egenix.com>
Message-ID: <CADQwG8sY5vF77LvkA8N4WiYho4=iLKhP9=mCtBXtpzKu-jc-gA@mail.gmail.com>


Wes added the comment:

Marc,

Thanks for your help.

What I did was just copied the _sys_version_parser from the standard python
platform.py into the anaconda version of platform.py and it fixed the
issue.  So it looks like Anaconda made a change to your regular expression.

Thanks for getting on the issue so quick and staying with it, though.

On Wed, Dec 18, 2013 at 6:14 PM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg added the comment:
>
> On 19.12.2013 00:52, Wes wrote:
> >
> > Marc,
> >
> > Here was the initial output:
> >
> >>>> platform.__file__
> > '/Users/wesmadrigal/anaconda/lib/python2.7/platform.pyc'
> >>>> import sys
> >>>> sys.version
> > '2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Nov 11 2013, 10:49:09) \n[GCC
> > 4.0.1 (Apple Inc. build 5493)]'
>
> The part '|Anaconda 1.8.0 (x86_64)|' in that string is not standard
> Python conform and as a result, the platform.py parser fails.
>
> You'll have to open a ticket with the Anaconda vendor to get this
> fixed.
>
> > Here is what I had when I reverted back to the standard $PATH that comes
> > stock in Mac OSX Mountain Lion on this new Macbook Pro:
> >
> >>>> platform.__file__
> >
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.pyc'
> >>>> import sys
> >>>> sys.version
> > '2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple
> LLVM
> > 5.0 (clang-500.0.68)]'
>
> This should parse correctly with the stock platform.py parser.
>
> The only explanation I have is that the platform.py installed
> on your machine is not the original one that comes with the
> Python 2.7.5 we distribute from python.org.
>
> I don't have a Mac OSX notebook available to check, so can't
> really help.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20019>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From mal at egenix.com  Thu Dec 19 01:13:59 2013
From: mal at egenix.com (M.-A. Lemburg)
Date: Thu, 19 Dec 2013 01:13:59 +0100
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <CADQwG8s__6-b9iFB-k-LHhOkCbO8BxMtYyEmxP2wScLY7qdZAw@mail.gmail.com>
References: <CADQwG8s__6-b9iFB-k-LHhOkCbO8BxMtYyEmxP2wScLY7qdZAw@mail.gmail.com>
Message-ID: <52B23A47.1090409@egenix.com>

On 19.12.2013 00:52, Wes wrote:
> 
> Marc,
> 
> Here was the initial output:
> 
>>>> platform.__file__
> '/Users/wesmadrigal/anaconda/lib/python2.7/platform.pyc'
>>>> import sys
>>>> sys.version
> '2.7.6 |Anaconda 1.8.0 (x86_64)| (default, Nov 11 2013, 10:49:09) \n[GCC
> 4.0.1 (Apple Inc. build 5493)]'

The part '|Anaconda 1.8.0 (x86_64)|' in that string is not standard
Python conform and as a result, the platform.py parser fails.

You'll have to open a ticket with the Anaconda vendor to get this
fixed.

> Here is what I had when I reverted back to the standard $PATH that comes
> stock in Mac OSX Mountain Lion on this new Macbook Pro:
> 
>>>> platform.__file__
> '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/platform.pyc'
>>>> import sys
>>>> sys.version
> '2.7.5 (default, Sep 12 2013, 21:33:34) \n[GCC 4.2.1 Compatible Apple LLVM
> 5.0 (clang-500.0.68)]'

This should parse correctly with the stock platform.py parser.

The only explanation I have is that the platform.py installed
on your machine is not the original one that comes with the
Python 2.7.5 we distribute from python.org.

I don't have a Mac OSX notebook available to check, so can't
really help.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Thu Dec 19 01:47:59 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 Dec 2013 00:47:59 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1387414079.59.0.506079920686.issue19020@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

What I think:

1. Perhaps I should have noticed that
        self.tk.call(_flatten((self._w, cmd)))):
has 3 '('s and 4 ')'s and looked at the previous line for the complete expression.

2. Perhaps Python should switch os.sep ('\\') and os.altsep ('/') on Windows and otherwise 'sanitize', as needed, all file names it gets from Windows, so it always uses '/' internally as the path separator on Windows as well as *nix. The current situation has been a constant headache. (Example: until patched this year, patchcheck.py did not work completely on Windows.) Beyond the scope of this issue.

3. Without waiting for 2. to happen, perhaps Idle should do so. Another example of the \ problem: if one recursively searches c:/programs/python34/lib/idlelib, the output window will put out entries with mixed usage:
 c:/programs/python34/lib/idlelib\idle_test\test_rstrip.py:
This is confusing to read and not much useful when copied for pasting.
Also beyond the scope of this issue.

4. Without waiting for 3, and given that tk is (just sometimes?) cooking strings as if they were literals, Idle should at least sanitize (\ to /) filenames it sends to tk to avoid cooking altogether. Is tk also replacing the 2 char sequence \t with the tab char?

4a. I suspect the tk cooking behavior should be documented better than it is. I was not aware of it.

5. Making the tkinter tests pass (when written correctly) is enough to justify a patch. Better soon than just before release.

You did not directly say whether your patch fixes the Idle 0.py problem, but I presume the change to _configure() is intended to. In any case, I will try to test this on my system tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Thu Dec 19 03:36:37 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 19 Dec 2013 02:36:37 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387420597.89.0.647586221775.issue20014@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Thanks, Serhiy, for the review! Here is the patch to avoid refleaking and avoid literal u'' string.

If your ticket, #20015, is accepted, then we can throw away the fix and use only unit test in this ticket.

----------
Added file: http://bugs.python.org/file33199/makes_array_accepts_ascii_unicode_typecode_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Thu Dec 19 03:59:31 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Dec 2013 02:59:31 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1387421970.93.0.756932627221.issue8075@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Well can someone at least drop the priority from high?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Thu Dec 19 04:03:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Thu, 19 Dec 2013 03:03:39 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1387422219.09.0.384922163224.issue8075@psf.upfronthosting.co.za>


Changes by Tim Peters <tim at python.org>:


----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Thu Dec 19 04:15:18 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Dec 2013 03:15:18 +0000
Subject: [issue777588] asyncore is broken for windows if connection is refused
Message-ID: <1387422918.72.0.264891952755.issue777588@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is it worth leaving this open given the arrival of the new asyncio module in Python 3.4?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue777588>
_______________________________________

From report at bugs.python.org  Thu Dec 19 04:43:59 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 19 Dec 2013 03:43:59 +0000
Subject: [issue19920] TarFile.list() fails on some files
In-Reply-To: <1386437860.38.0.0478693655005.issue19920@psf.upfronthosting.co.za>
Message-ID: <1387424639.48.0.667531421764.issue19920@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Thanks, Serhiy, for your review. Here is the patch to address your concern.

----------
Added file: http://bugs.python.org/file33200/fix_tarfile_list_print_lone_surrogate_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19920>
_______________________________________

From report at bugs.python.org  Thu Dec 19 04:55:20 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 03:55:20 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387425320.75.0.291541921569.issue19946@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The problem on Windows at least is that the skips for the 'fork' and 'forkserver' start methods aren't firing due to setUpClass being improperly set up in MultiProcessingCmdLineMixin: it's not decorated as a classmethod and the 'u' is lower-case instead of upper.  Just fixing that makes for some unusual output ("skipped '"fork" start method not available'" with no indication of which test was skipped) and a variable number of tests depending on available start methods, so a better fix is to just do the check in setUp.

Unrelated to the failure, but we're also in the process of moving away from using test_main(), preferring unittest.main().

The attached patch addresses both, passes on Windows and Linux, and I suspect should help on OpenIndiana as well judging by the tracebacks it's giving.

----------
nosy: +zach.ware
Added file: http://bugs.python.org/file33201/issue19946.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:05:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 04:05:25 +0000
Subject: [issue20020] "modernize" the modulefinder module
Message-ID: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za>


New submission from Eric Snow:

The modulefinder module (Lib/modulefinder.py) provides a ModuleFinder class (plus 2 helpers) you can use to see what modules a script imports (directly or indirectly).  The module's implementation is centered on the old imp.find_/load_module() API (which has been deprecated).  The implementation should be refactored to reflect/make use of the newer import-related APIs.

The documented API for ModuleFinder is very small.  However, it has quite a few methods that are "public" in the sense that their names do not start with an underscore.  This will make any kind of refactoring trickier.

----------
components: Library (Lib)
messages: 206576
nosy: eric.snow
priority: low
severity: normal
status: open
title: "modernize" the modulefinder module
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20020>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:11:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 04:11:25 +0000
Subject: [issue20021] "modernize" makeopcodetargets.py
Message-ID: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za>


New submission from Eric Snow:

Python/makeopcodetargets.py uses deprecated imp APIs.  It should be refactored to use newer import-related APIs.

----------
components: Library (Lib)
messages: 206577
nosy: eric.snow
priority: low
severity: normal
status: open
title: "modernize" makeopcodetargets.py
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20021>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:13:34 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 04:13:34 +0000
Subject: [issue20022] "modernize" the Mac bundlebuilder.py script
Message-ID: <1387426414.21.0.655267134142.issue20022@psf.upfronthosting.co.za>


New submission from Eric Snow:

Mac/Tools/bundlebuilder.py uses deprecated imp APIs.  It should be refactored to use the current import-related APIs.

----------
messages: 206578
nosy: eric.snow
priority: low
severity: normal
status: open
title: "modernize" the Mac bundlebuilder.py script
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20022>
_______________________________________

From report at bugs.python.org  Thu Dec 19 05:58:04 2013
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Thu, 19 Dec 2013 04:58:04 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1387429084.8.0.732074164919.issue9291@psf.upfronthosting.co.za>


Takayuki SHIMIZUKAWA added the comment:

This issue affects mercurial too.
http://bz.selenic.com/show_bug.cgi?id=3624

----------
nosy: +shimizukawa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Thu Dec 19 06:46:30 2013
From: report at bugs.python.org (paul j3)
Date: Thu, 19 Dec 2013 05:46:30 +0000
Subject: [issue19959] argparse.FileType does not expand tilde "~"
In-Reply-To: <1386844263.55.0.374493919931.issue19959@psf.upfronthosting.co.za>
Message-ID: <1387431990.2.0.122596221547.issue19959@psf.upfronthosting.co.za>


paul j3 added the comment:

Normally the unix shell takes care of this expansion.  If I call a simple script that prints sys.argv and runs a simple parser, I get:

    2135:~/mypy$ python2.7 filetypetest.py ~/mypy/test.txt
    ['filetypetest.py', '/home/paul/mypy/test.txt']
    Namespace(file=<open file '/home/paul/mypy/test.txt', mode 'r'...)

I have to quote the argument '~/mypy/test.blog' to bypass this expansion.

This is under Linux (bash).  Is Windows or Mac different?

My impression is that `FileType` has been provided as an example of a custom `type`, as opposed to a comprehensive file handler.  But I can't quote a developer on this.  

http://bugs.python.org/issue13824 is a bug report that worries that 'argparse.FileType opens a file and never closes it'.  There are some comments there about whether it is appropriate to expand on the capabilities of FileType.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19959>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:08:25 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 06:08:25 +0000
Subject: [issue19700] Update runpy for PEP 451
In-Reply-To: <1385141125.22.0.359014382795.issue19700@psf.upfronthosting.co.za>
Message-ID: <1387433304.99.0.468758602198.issue19700@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for working this out, Nick!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19700>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:10:18 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 06:10:18 +0000
Subject: [issue19710] Make sure documentation for PEP 451 is finished
In-Reply-To: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>
Message-ID: <1387433418.33.0.93447602486.issue19710@psf.upfronthosting.co.za>


Eric Snow added the comment:

If anyone notices any issues with the doc changes, please open a new issue.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19710>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:13:24 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 06:13:24 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387433604.13.0.709491921872.issue19713@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file33172/issue19713-deprecation-warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Thu Dec 19 07:20:57 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 06:20:57 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387434057.94.0.695022689998.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's an updated patch that does most of the deprecations and adjustments/silencings to accommodate the deprecations.  The main things left to adjust are many importlib tests and pkgutil/test_pkgutil.

I'm still on the fence about deprecation warnings for module_repr().  We have to keep the methods around for backward-compatibility and module.__repr__ uses them if they exist.  So there really isn't a good place to put a deprecation warning for now.  Thoughts?

----------
Added file: http://bugs.python.org/file33202/issue19713-deprecation-warnings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:06:15 2013
From: report at bugs.python.org (=?utf-8?q?Dani=C3=ABl_van_Eeden?=)
Date: Thu, 19 Dec 2013 07:06:15 +0000
Subject: [issue20013] imaplib behaviour when deleting selected folder
In-Reply-To: <1387355660.84.0.595349398689.issue20013@psf.upfronthosting.co.za>
Message-ID: <1387436775.78.0.298323021879.issue20013@psf.upfronthosting.co.za>


Dani?l van Eeden added the comment:

Without the patch:
Traceback (most recent call last):
  File "./test.py", line 10, in <module>
    s.select('INBOX')
  File "/usr/lib/python2.7/imaplib.py", line 649, in select
    typ, dat = self._simple_command(name, mailbox)
  File "/usr/lib/python2.7/imaplib.py", line 1070, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.7/imaplib.py", line 899, in _command_complete
    raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: SELECT => socket error: EOF

With the patch:
Traceback (most recent call last):
  File "./test.py", line 10, in <module>
    s.select('INBOX')
  File "/usr/lib/python2.7/imaplib.py", line 649, in select
    typ, dat = self._simple_command(name, mailbox)
  File "/usr/lib/python2.7/imaplib.py", line 1075, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib/python2.7/imaplib.py", line 899, in _command_complete
    raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: SELECT => Selected mailbox was deleted, have to disconnect.

I'm really happy with this new behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20013>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:31:56 2013
From: report at bugs.python.org (follower)
Date: Thu, 19 Dec 2013 07:31:56 +0000
Subject: [issue19902] logging docs don't document integer constants
In-Reply-To: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>
Message-ID: <1387438316.43.0.832997757743.issue19902@psf.upfronthosting.co.za>


follower added the comment:

Thanks for pointing out that link. It's good to know the information is documented somewhere.

However, given that <http://docs.python.org/2/library/logging.html> is described as "the API reference" and seems to be the canonical logging library reference (rather than a tutorial) it would be appropriate to--and I would expect it to--include the constants information in it.

Thus I would request you reconsider the "invalid" resolution on this basis. Thanks.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19902>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:43:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 07:43:39 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1387439019.93.0.632922059137.issue19020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sanitizing backslashes will not help when file names (or other returned strings, see msg202496) contains spaces or curly braces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:48:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 07:48:53 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1387439333.01.0.0407225006769.issue19020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

And of cause we can't "sanitize" filenames which contains backslash on Unix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Thu Dec 19 08:57:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 07:57:04 +0000
Subject: [issue18877] tkinter askopenfilenames does not work in Windows
 library folder
In-Reply-To: <1377802367.69.0.551472579776.issue18877@psf.upfronthosting.co.za>
Message-ID: <1387439824.25.0.721314588271.issue18877@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Already applied in issue3015.

----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> tkinter with wantobjects=False has been broken for some time

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18877>
_______________________________________

From report at bugs.python.org  Thu Dec 19 09:45:29 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 19 Dec 2013 08:45:29 +0000
Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1387442729.57.0.727696274213.issue16074@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Is there any possibility this ticket could be committed in Python 3.4? If yes, it would be good because we would have a good foundation for creating better error message in Python 3.5.

Anyway, I check Python's competitors' behaviour.

Ruby displays both files.

irb(main):001:0> File.symlink('a.txt', 'b')
Errno::EEXIST: File exists @ sys_fail2 - (a.txt, b)
	from (irb):1:in `symlink'
	from (irb):1
	from /home/ethan/Documents/code/ruby/localruby/bin/irb:11:in `<main>'

Perl omits the files.

  DB<8> print symlink("a.txt", "b");
0
  DB<9> print $!;
File exists

PHP omits the files.

php -r "symlink('b', 'a');"
PHP Warning:  symlink(): File exists in Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0
PHP   2. symlink() Command line code:1

Warning: symlink(): File exists in Command line code on line 1

Call Stack:
    0.0001     225688   1. {main}() Command line code:0
    0.0001     226392   2. symlink() Command line code:1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16074>
_______________________________________

From report at bugs.python.org  Thu Dec 19 10:06:27 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 19 Dec 2013 09:06:27 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <1387408127.09.0.79406077892.issue20019@psf.upfronthosting.co.za>
Message-ID: <1387443987.2.0.231934042172.issue20019@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Closing, since there's nothing much we can do about the problem.

----------
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 10:32:40 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Dec 2013 09:32:40 +0000
Subject: [issue20022] "modernize" the Mac bundlebuilder.py script
In-Reply-To: <1387426414.21.0.655267134142.issue20022@psf.upfronthosting.co.za>
Message-ID: <1387445560.84.0.761277087158.issue20022@psf.upfronthosting.co.za>


Ned Deily added the comment:

bundlebuild.py is a deprecated legacy tool that has been superseded by the third-party py2app.  AFAIK, its only use in Python 3 is to build PythonLauncher.app; it is not included in a Python installation.  Rather than refactor it, its use should be eliminated in Mac/PythonLauncher/Makefile.in.

----------
assignee:  -> ned.deily
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20022>
_______________________________________

From report at bugs.python.org  Thu Dec 19 10:48:54 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 09:48:54 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1387446534.5.0.101610174612.issue14455@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I'm working on an update for your patch that addresses these comments:

* I don't like supporting 128 bit integers because Apple's public APIs
  don't support those values. That is, the value 'kCFNumberSInt128Type'
  is not in a public header for the OSX 10.9 SDK.

* The test_int method that you introduced tests conversions to and from XML,
  and doesn't test the problem with negative values in binary plists.

* I don't understand why test_int converts a value to a binary plist twice,
  that is the 'data2 = plistlib.dumps(pl2)' bit.

* I'm adding negative integers to the _create method as well, with the 
  corresponding changes to the binary TESTDATA dictionary.

* I don't understand your comment about the writePlistToBytes documentation,
  there was no versionchanged in the documentation.  The version changed 
  for dump was wrong, that should be versionadded (and the other new functions
  should have a versionadded as well)

* I agree that this change should be mentioned in What's New.

* I agree that _write_object should raise TypeError

BTW. What about out-of-range integer values? Those currently raise struct.error, I'd prefer to raise TypeError instead because the use of the
struct module should be an implementation detail.

And a final question: integers with '2 ** 63 <= value < 2 ** 64' (e.g. values that are in the range of uint64_t but not in the range of int64_t) can be written to a binary plist, but will be read back as a negative value (which is the same behavior as in Apple's code). Should we warn about this in the documentation?

I'll post an updated patch later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:05:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 10:05:52 +0000
Subject: [issue20023] _csv.Dialect() does not check type for delimiter,
 escapechar and quotechar fields
Message-ID: <1387447552.86.0.0617469678586.issue20023@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Example:

$ ./python -c "import _csv; _csv.Dialect(escapechar=b'x')"
python: Python/ceval.c:4262: call_function: Assertion `(x != ((void *)0) && !PyErr_Occurred()) || (x == ((void *)0) && PyErr_Occurred())' failed.
Abandon (core dumped)

Attached patch should fix this issue and adds a unit test.

Note: I found this issue using Fusil the fuzzer.

----------
files: csv.patch
keywords: patch
messages: 206593
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: _csv.Dialect() does not check type for delimiter, escapechar and quotechar fields
versions: Python 3.4
Added file: http://bugs.python.org/file33203/csv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20023>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:33:38 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 10:33:38 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1387449218.08.0.295118367305.issue14455@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The attached patch should fix the open issues:

* Negative integers are supported (based on Serhiy's patch), but without
  support for 128-bit integer (as per my previous comment)

* Test updates for this

* Updated version tags in the documentation

* Documented the odd behavior for 64-bit unsigned values larger than the
  largest 64-bit signed value.

* Raise TypeError when trying to write an object that isn't supported
  (with test)

* Raise OverflowError when trying to write an integer that cannot be 
  represented in a binary plist

* Add entry to "What's New"

----------
Added file: http://bugs.python.org/file33204/negative_int_support.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:37:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 10:37:11 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1387446534.5.0.101610174612.issue14455@psf.upfronthosting.co.za>
Message-ID: <1712236.fbKhKac9jU@raxxla>


Serhiy Storchaka added the comment:

> * I don't like supporting 128 bit integers because Apple's public APIs
>   don't support those values. That is, the value 'kCFNumberSInt128Type'
>   is not in a public header for the OSX 10.9 SDK.

At least we should support integers from -2**63 to 2**64-1 (signed and 
unsigned 64-bit).

> * The test_int method that you introduced tests conversions to and from XML,
> and doesn't test the problem with negative values in binary plists.

Indeed.

> * I don't understand why test_int converts a value to a binary plist twice,
>   that is the 'data2 = plistlib.dumps(pl2)' bit.

I have copied this from test_bytes(). I suppose that pl2 can be int subclass. 
Agree, for now this check is redundant.

> * I don't understand your comment about the writePlistToBytes documentation,
> there was no versionchanged in the documentation.  The version changed for
> dump was wrong, that should be versionadded (and the other new functions
> should have a versionadded as well)

http://hg.python.org/cpython/file/673ca119dbd0/Doc/library/plistlib.rst#l165

> BTW. What about out-of-range integer values? Those currently raise
> struct.error, I'd prefer to raise TypeError instead because the use of the
> struct module should be an implementation detail.

Agree. Especially if OSX SDK doesn't support deserialization of integers 
larger than 64-bit. Perhaps we should add this check for XML format too. And 
document this limitation.

> And a final question: integers with '2 ** 63 <= value < 2 ** 64' (e.g.
> values that are in the range of uint64_t but not in the range of int64_t)
> can be written to a binary plist, but will be read back as a negative value
> (which is the same behavior as in Apple's code). Should we warn about this
> in the documentation?

These values should be written as 128-bit integers (token b'\x14').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:43:38 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 19 Dec 2013 10:43:38 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1387449818.25.0.667610585347.issue7464@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

Here it is.
Notice the incredible nesting depth in python 2.7.
The socket itself is found at
response.fp._sock.fp._sock
There are two socket._fileobjects in use!

----------
Added file: http://bugs.python.org/file33205/httpleak.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:55:41 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 19 Dec 2013 10:55:41 +0000
Subject: [issue20023] _csv.Dialect() does not check type for delimiter,
 escapechar and quotechar fields
In-Reply-To: <1387447552.86.0.0617469678586.issue20023@psf.upfronthosting.co.za>
Message-ID: <1387450541.41.0.668537027476.issue20023@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Bear in the mind, the bug is only reproducible with debug flag (--with-pydebug).

Victor, we have a more complete solution for this problem in #18829.

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20023>
_______________________________________

From report at bugs.python.org  Thu Dec 19 11:58:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 10:58:44 +0000
Subject: [issue20023] _csv.Dialect() does not check type for delimiter,
 escapechar and quotechar fields
In-Reply-To: <1387447552.86.0.0617469678586.issue20023@psf.upfronthosting.co.za>
Message-ID: <1387450724.73.0.74621077288.issue20023@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue18829.

----------
resolution:  -> duplicate
superseder:  -> csv produces confusing error message when passed a non-string delimiter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20023>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:01:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 11:01:00 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1387450860.4.0.792540474498.issue18829@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/issue18829>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:06:51 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Dec 2013 11:06:51 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387451211.22.0.318082146069.issue19713@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Please don't emit a deprecation warning for loaders that only implement load_module - there are still things load_module can do that create/exec can't, and it's still possible it will remain the long term API for those use cases.

Plus builtins and extensions are still loaded with load_module - we can't deprecate an API we're still using.

I'm actually still -0 on doing any programmatic deprecations in 3.4 at all. What maintenance burden are we eliminating for ourselves that justifies the pain we're inflicting on users? I want import system specialists to be *excited* about PEP 451, but if we deprecate everything and *force* them to migrate immediately (rather than giving them until 3.5 before they get warnings), they're going to hate it :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:10:04 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 11:10:04 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1387451404.73.0.683852008426.issue14455@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Attached a script (using PyObjC) that demonstrates the behavior of Apple's Foundation framework with large integers. The same behavior should occur when the script is rewritten in Objective-C.

----------
Added file: http://bugs.python.org/file33206/apple-behavior-with-large-integers.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:10:20 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 11:10:20 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1387451420.65.0.612567823942.issue14455@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file33207/negative_int_support-2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:13:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 11:13:31 +0000
Subject: [issue20024] Py_BuildValue() can call Python code with an exception
 set
Message-ID: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3.4, an assertion now checks that no exception is set when arbitrary Python code is called. Python code may suppress the exception.

When Py_BuildValue() is used to build a tuple and an error when the creation of an item failed, the function may execute indirectly Python code with an exception set.

Attached patch works around the issue by storing the current exception in a variable and then restore it. It changes the behaviour if more than one exception is raised: at the end, its the first exception which is passed to the caller. I prefer to get the first exception instead of the following exceptions, because following exceptions may be caused by the first exception. See for example the parser bug below for an example of a second exception caused by the first exception.

--

Example with the parser module:

            PyObject *err = Py_BuildValue("os", elem,
                                          "Illegal node construct.");
            PyErr_SetObject(parser_error, err);

The "o" is not a valid format and so a SystemError is raised, but then the UTF-8 decoder tries to raise a second exception, an UnicodeDecodeError, because the decoders is called with an invalid bytes string (elem variable, instead of the "Illegal node construct." string, because "o" format didn't increment the argument pointer). The bug is obvious in the parser module, but the problem is more general than that.

Gdb traceback of the parser bug:

python: Objects/typeobject.c:741: type_call: Assertion `!PyErr_Occurred()' failed.

Program received signal SIGABRT, Aborted.
0x000000301c0359e9 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.17-19.fc19.x86_64
(gdb) where
#0  0x000000301c0359e9 in raise () from /lib64/libc.so.6
#1  0x000000301c0370f8 in abort () from /lib64/libc.so.6
#2  0x000000301c02e956 in __assert_fail_base () from /lib64/libc.so.6
#3  0x000000301c02ea02 in __assert_fail () from /lib64/libc.so.6
#4  0x00000000004dae18 in type_call (type=0x906780 <_PyExc_UnicodeDecodeError>, args=('utf-8', b'\xc8\x87\xe0\xf7\xff\x7f', 2, 3, 'invalid continuation byte'), kwds=0x0)
    at Objects/typeobject.c:741
#5  0x000000000045fb75 in PyObject_Call (func=<type at remote 0x906780>, arg=('utf-8', b'\xc8\x87\xe0\xf7\xff\x7f', 2, 3, 'invalid continuation byte'), kw=0x0)
    at Objects/abstract.c:2067
#6  0x000000000045fd0f in call_function_tail (callable=<type at remote 0x906780>, args=('utf-8', b'\xc8\x87\xe0\xf7\xff\x7f', 2, 3, 'invalid continuation byte'))
    at Objects/abstract.c:2104
#7  0x000000000045ff94 in _PyObject_CallFunction_SizeT (callable=<type at remote 0x906780>, format=0x669e19 "sy#nns") at Objects/abstract.c:2150
#8  0x000000000048643d in PyUnicodeDecodeError_Create (encoding=0x67e312 "utf-8", object=0x7ffff6ddcf40 "\310\207\340\367\377\177", length=6, start=2, end=3, 
    reason=0x67f1c1 "invalid continuation byte") at Objects/exceptions.c:1960
#9  0x000000000050fe7c in make_decode_exception (exceptionObject=0x7fffffff9090, encoding=0x67e312 "utf-8", input=0x7ffff6ddcf40 "\310\207\340\367\377\177", length=6, 
    startpos=2, endpos=3, reason=0x67f1c1 "invalid continuation byte") at Objects/unicodeobject.c:4009
#10 0x0000000000510015 in unicode_decode_call_errorhandler_writer (errors=0x0, errorHandler=0x7fffffff9098, encoding=0x67e312 "utf-8", 
    reason=0x67f1c1 "invalid continuation byte", input=0x7fffffff90b8, inend=0x7fffffff90b0, startinpos=0x7fffffff90a8, endinpos=0x7fffffff90a0, 
    exceptionObject=0x7fffffff9090, inptr=0x7fffffff9088, writer=0x7fffffff90c0) at Objects/unicodeobject.c:4157
#11 0x00000000005163a8 in PyUnicode_DecodeUTF8Stateful (s=0x7ffff6ddcf42 "\340\367\377\177", size=6, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:4798
#12 0x0000000000506198 in PyUnicode_FromStringAndSize (u=0x7ffff6ddcf40 "\310\207\340\367\377\177", size=6) at Objects/unicodeobject.c:1840
#13 0x00000000005da9d2 in do_mkvalue (p_format=0x7fffffff92e0, p_va=0x7fffffff92c8, flags=0) at Python/modsupport.c:319
#14 0x00000000005d9e50 in do_mktuple (p_format=0x7fffffff92e0, p_va=0x7fffffff92c8, endchar=0, n=2, flags=0) at Python/modsupport.c:164
#15 0x00000000005db067 in va_build_value (format=0x7ffff750f34b "os", va=0x7fffffff9310, flags=0) at Python/modsupport.c:455
#16 0x00000000005dae8c in Py_BuildValue (format=0x7ffff750f34b "os") at Python/modsupport.c:410
#17 0x00007ffff750641c in build_node_children (tuple=(1467, -415088696226, 183475025091, 3, -85006798, 915338703290779849), root=0x7ffff7f7f6b8, line_num=0x7fffffff95cc)
    at /home/haypo/prog/python/default/Modules/parsermodule.c:788

----------
files: py_buildvalue_failed.patch
keywords: patch
messages: 206602
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Py_BuildValue() can call Python code with an exception set
versions: Python 3.4
Added file: http://bugs.python.org/file33208/py_buildvalue_failed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20024>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:14:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 11:14:21 +0000
Subject: [issue20024] Py_BuildValue() can call Python code with an exception
 set
In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za>
Message-ID: <1387451661.61.0.54194006563.issue20024@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file33209/parsermodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20024>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:14:39 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 11:14:39 +0000
Subject: [issue20024] Py_BuildValue() can call Python code with an exception
 set
In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za>
Message-ID: <1387451679.82.0.500656857951.issue20024@psf.upfronthosting.co.za>


STINNER Victor added the comment:

parsermodule.patch: fix usage of Py_BuildValue() in the parser module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20024>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:28:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 11:28:30 +0000
Subject: [issue20025] ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check
 if num is negative
Message-ID: <1387452510.42.0.848389239504.issue20025@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() should raise a ValueError, not a SystemError, if num is negative.

Attached patch fixes that.

----------
files: ssl_rand.patch
keywords: patch
messages: 206604
nosy: christian.heimes, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check if num is negative
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33210/ssl_rand.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20025>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:50:52 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 19 Dec 2013 11:50:52 +0000
Subject: [issue20025] ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check
 if num is negative
In-Reply-To: <1387452510.42.0.848389239504.issue20025@psf.upfronthosting.co.za>
Message-ID: <1387453852.27.0.988990183296.issue20025@psf.upfronthosting.co.za>


Christian Heimes added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20025>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:51:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 11:51:34 +0000
Subject: [issue19902] logging docs don't document integer constants
In-Reply-To: <1386285391.99.0.345532984259.issue19902@psf.upfronthosting.co.za>
Message-ID: <3dlWdd5vzbz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 16bfddf5a091 by Vinay Sajip in branch '2.7':
Issue #19902: Added list of logging levels.
http://hg.python.org/cpython/rev/16bfddf5a091

New changeset e812094d42f9 by Vinay Sajip in branch '3.3':
Issue #19902: Added list of logging levels.
http://hg.python.org/cpython/rev/e812094d42f9

New changeset 45bd58a15bb9 by Vinay Sajip in branch 'default':
Closes #19902: Merged update from 3.3.
http://hg.python.org/cpython/rev/45bd58a15bb9

----------
nosy: +python-dev
resolution: invalid -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19902>
_______________________________________

From report at bugs.python.org  Thu Dec 19 12:54:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 11:54:34 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <3dlWj538H7z7Lk4@mail.python.org>


Roundup Robot added the comment:

New changeset 460961e80e31 by Nick Coghlan in branch 'default':
Issue #19946: appropriately skip new multiprocessing tests
http://hg.python.org/cpython/rev/460961e80e31

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:20:25 2013
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 19 Dec 2013 12:20:25 +0000
Subject: [issue20020] "modernize" the modulefinder module
In-Reply-To: <1387425925.56.0.593354940747.issue20020@psf.upfronthosting.co.za>
Message-ID: <1387455625.61.0.00103939843701.issue20020@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I have written a new modulefinder based on importlib.  It is not a refactoring of the old one, so it is no plug-in replacement.  Instead it has some new features:

- Better logging output
- collects dependencies (self._depgraph maps module names to callers)
- when run as script, the command line syntax are easier to understand (although parsing is still done by getopt; argparse would be event better)
- The Module proxies that modulefinder collects give better access to the module's attributes, including the byte code

It is not yet tested in the wild but I will use it for the Python3 py2exe implementation.

If anyone wants to take a look the current version is here:

http://code.google.com/p/ctypes-stuff/source/browse/trunk/mf/py2exe/mf3.py

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20020>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:20:51 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 12:20:51 +0000
Subject: [issue20022] "modernize" the Mac bundlebuilder.py script
In-Reply-To: <1387426414.21.0.655267134142.issue20022@psf.upfronthosting.co.za>
Message-ID: <1387455651.08.0.928659523073.issue20022@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Removing bundle builder should be easy enough if it is only used to create the PythonLauncher application bundle: that bundle does not contain python code at all and constructing it is just a matter of copying files to the right location.

The attached patch should do the trick. The patch is very rough, but does work.

----------
Added file: http://bugs.python.org/file33211/python-launcher-no-bundlebuilder.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20022>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:21:06 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 12:21:06 +0000
Subject: [issue20022] "modernize" the Mac bundlebuilder.py script
In-Reply-To: <1387426414.21.0.655267134142.issue20022@psf.upfronthosting.co.za>
Message-ID: <1387455666.17.0.494088980295.issue20022@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
keywords: +needs review, patch
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20022>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:58:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 12:58:50 +0000
Subject: [issue20026] sqlite: handle correctly invalid isolation_level
Message-ID: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The C function pysqlite_connection_init() doesn't check if pysqlite_connection_set_isolation_level() failed or not.

Attached patch fixes that.

----------
files: sqlite.patch
keywords: patch
messages: 206610
nosy: haypo
priority: normal
severity: normal
status: open
title: sqlite: handle correctly invalid isolation_level
versions: Python 3.4
Added file: http://bugs.python.org/file33212/sqlite.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20026>
_______________________________________

From report at bugs.python.org  Thu Dec 19 13:59:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 12:59:22 +0000
Subject: [issue20026] sqlite: handle correctly invalid isolation_level
In-Reply-To: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>
Message-ID: <1387457962.72.0.00183779685017.issue20026@psf.upfronthosting.co.za>


STINNER Victor added the comment:

$ python
Python 3.4.0b1 (default:298d98486794+, Dec 19 2013, 13:45:07) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> con=sqlite3.connect(":memory:", isolation_level=3)
python: Objects/typeobject.c:741: type_call: Assertion `!PyErr_Occurred()' failed.
Program terminated with signal SIGABRT, Aborted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20026>
_______________________________________

From report at bugs.python.org  Thu Dec 19 14:07:28 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 19 Dec 2013 13:07:28 +0000
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1349389263.57.0.925729224322.issue16136@psf.upfronthosting.co.za>
Message-ID: <1387458448.91.0.953930796553.issue16136@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Unless somebody says otherwise I'm going to remove VMS-related code over the course of the next couple of days.

PEP 11 says:
Name: VMS (issue 16136)
Unsupported in: Python 3.3
Code removed in: Python 3.4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16136>
_______________________________________

From report at bugs.python.org  Thu Dec 19 15:30:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 14:30:26 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <3dlb8x0lQ6z7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 5ed75e36be8e by Serhiy Storchaka in branch '2.7':
Issue #18829: csv.Dialect() now checks type for delimiter, escapechar and
http://hg.python.org/cpython/rev/5ed75e36be8e

New changeset 52d03fbdf67a by Serhiy Storchaka in branch '3.3':
Issue #18829: csv.Dialect() now checks type for delimiter, escapechar and
http://hg.python.org/cpython/rev/52d03fbdf67a

New changeset 6b17803bfddd by Serhiy Storchaka in branch 'default':
Issue #18829: csv.Dialect() now checks type for delimiter, escapechar and
http://hg.python.org/cpython/rev/6b17803bfddd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Thu Dec 19 15:35:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 14:35:44 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1387463744.71.0.611775814195.issue18829@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Vajrasky for your patch. I have simplified and fixed (escapechar can be empty) it. Reverted ValueError back to TypeError because ord() raises TypeError for non-1-character strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18829>
_______________________________________

From report at bugs.python.org  Thu Dec 19 15:36:18 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 14:36:18 +0000
Subject: [issue18829] csv produces confusing error message when passed a
 non-string delimiter
In-Reply-To: <1377435383.74.0.241640816854.issue18829@psf.upfronthosting.co.za>
Message-ID: <1387463778.86.0.281364662505.issue18829@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/issue18829>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:06:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 15:06:55 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1387465615.45.0.0677733183.issue14455@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't test on OSX, but I see that Apple's code can write any 128-bit integers and read signed and unsigned 64-bit integers.

Can Apple's utilities read this file? What is a result?

----------
Added file: http://bugs.python.org/file33213/18446744073709551615.plist

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:08:07 2013
From: report at bugs.python.org (gudge)
Date: Thu, 19 Dec 2013 15:08:07 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387465687.07.0.174588845039.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

1) Can I get a list of failures. The summary of test results which I compare on my machine.

2) 

-----------------------------------------------------------------------------------------------------
>>> import ssl
>>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
1178649000.0
>>> from datetime import datetime
>>> datetime.utcfromtimestamp(1178668800)
datetime.datetime(2007, 5, 9, 0, 0)
>>> import time
>>> time.gmtime(1178668800)
time.struct_time(tm_year=2007, tm_mon=5, tm_mday=9, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=129, tm_isdst=0)
>>> import calender
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'calender'
>>> import callendar
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'callendar'
>>> import calendar
>>> calendar.timegm(time.strptime("May 9 00:00:00 2007 GMT", "%b %d %H:%M:%S %Y GMT"))
1178668800
----------------------------------------------------------------------------------------------------

I am running a VM on windows host machine.
In your comment ou have specified:

>>> import ssl
    >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
    1178694000.0

It should be `1178668800`:

But I get also get the same answer with the Python build from latest sources?
Therefore I do not get you?

3)
    3 tests omitted:
        test___all__ test_site test_urllib2net
    348 tests OK.
    3 tests failed:
        test_codecs test_distutils test_ioctl
    2 tests altered the execution environment:
        test___all__ test_site
    33 tests skipped:
        test_bz2 test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
        test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
        test_dbm_ndbm test_devpoll test_gzip test_idle test_kqueue
        test_lzma test_msilib test_ossaudiodev test_readline test_smtpnet
        test_socketserver test_sqlite test_ssl test_startfile test_tcl
        test_timeout test_tk test_ttk_guionly test_ttk_textonly
        test_urllibnet test_winreg test_winsound test_xmlrpc_net
        test_zipfile64 test_zlib


Are these results fine. These results are with no changes. 
How can I make all tests (skipped and omiited pass)

What about the 3 tests which failed. Are these known failures?

4) 

 Now say I have to pull time again to get the latest code. Does it help
to do a make. Or I will have o do configure again.

5) I had posted a query on core-metorship? No answers? Not that I am entitled to.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:20:31 2013
From: report at bugs.python.org (gudge)
Date: Thu, 19 Dec 2013 15:20:31 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387466431.04.0.905113029328.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Sorry I think I did not read msg205774 (1st comment) correctly.
It clearly says:

"cert_time_to_seconds() uses `time.mktime()` [1] to convert utc time tuple to seconds since epoch. `mktime()` works with local time. It should use `calendar.timegm()` analog instead."

So the function cert_time_to_seconds() has to be fixed?

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:22:09 2013
From: report at bugs.python.org (Wes)
Date: Thu, 19 Dec 2013 15:22:09 +0000
Subject: [issue20019] platform.py line _sys_version function
In-Reply-To: <1387443987.2.0.231934042172.issue20019@psf.upfronthosting.co.za>
Message-ID: <CADQwG8tnzgi9GTi_v-8ezCSj1tjuMudU4Ju5qy8yEYKhsvD07g@mail.gmail.com>


Wes added the comment:

I'll submit this to Continuum Analytics so they know it's their issue.

On Thu, Dec 19, 2013 at 3:06 AM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg added the comment:
>
> Closing, since there's nothing much we can do about the problem.
>
> ----------
> resolution:  -> invalid
> status: open -> closed
> versions: +3rd party -Python 2.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20019>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20019>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:22:57 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 19 Dec 2013 15:22:57 +0000
Subject: [issue14455] plistlib unable to read json and binary plist files
In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za>
Message-ID: <1387466577.43.0.054281779563.issue14455@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Conversion to XML results in:

$ plutil -convert xml1 -o - 18446744073709551615.plist 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>a</key>
	<integer>18446744073709551615</integer>
</dict>
</plist>

This is the same as what I get with my latest patch:

>>> import plistlib
>>> plistlib.load(open('18446744073709551615.plist', 'rb'))
__main__:1: ResourceWarning: unclosed file <_io.BufferedReader name='18446744073709551615.plist'>
{'a': 18446744073709551615}

(and I have check that I can create a binary plist with a negative integer in this shell session)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14455>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:23:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Dec 2013 15:23:42 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387466622.03.0.613871744078.issue19940@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> So the function cert_time_to_seconds() has to be fixed?

Yes!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:32:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 15:32:01 +0000
Subject: [issue20026] sqlite: handle correctly invalid isolation_level
In-Reply-To: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>
Message-ID: <1387467121.26.0.490903920492.issue20026@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> haypo
components: +Library (Lib)
nosy: +serhiy.storchaka
stage:  -> commit review
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20026>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:40:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 15:40:57 +0000
Subject: [issue20025] ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check
 if num is negative
In-Reply-To: <1387452510.42.0.848389239504.issue20025@psf.upfronthosting.co.za>
Message-ID: <1387467657.33.0.556629774542.issue20025@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> haypo
stage:  -> commit review
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20025>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:41:56 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 15:41:56 +0000
Subject: [issue20026] sqlite: handle correctly invalid isolation_level
In-Reply-To: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>
Message-ID: <3dlclR2lmJz7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 11a161cf0e5d by Victor Stinner in branch '3.3':
Issue #20026: Fix the sqlite module to handle correctly invalid isolation level
http://hg.python.org/cpython/rev/11a161cf0e5d

New changeset f9b6c8ef55b6 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #20026: Fix the sqlite module to handle correctly invalid
http://hg.python.org/cpython/rev/f9b6c8ef55b6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20026>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:45:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 15:45:05 +0000
Subject: [issue20026] sqlite: handle correctly invalid isolation_level
In-Reply-To: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>
Message-ID: <3dlcq43zbpzQZj@mail.python.org>


Roundup Robot added the comment:

New changeset 572e4b054899 by Victor Stinner in branch '2.7':
Issue #20026: Fix the sqlite module to handle correctly invalid isolation level
http://hg.python.org/cpython/rev/572e4b054899

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20026>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:45:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 15:45:26 +0000
Subject: [issue20026] sqlite: handle correctly invalid isolation_level
In-Reply-To: <1387457930.38.0.260350520356.issue20026@psf.upfronthosting.co.za>
Message-ID: <1387467926.32.0.0221251669213.issue20026@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> pending
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20026>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:46:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 15:46:01 +0000
Subject: [issue20023] _csv.Dialect() does not check type for delimiter,
 escapechar and quotechar fields
In-Reply-To: <1387447552.86.0.0617469678586.issue20023@psf.upfronthosting.co.za>
Message-ID: <1387467961.12.0.613843847879.issue20023@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20023>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:47:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 15:47:50 +0000
Subject: [issue20025] ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check
 if num is negative
In-Reply-To: <1387452510.42.0.848389239504.issue20025@psf.upfronthosting.co.za>
Message-ID: <3dlctF6cnWz7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 68ec8949dbf1 by Victor Stinner in branch '3.3':
Issue #20025: ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() now raise a
http://hg.python.org/cpython/rev/68ec8949dbf1

New changeset c1d2c90ece99 by Victor Stinner in branch 'default':
(Merge 3.3) Issue #20025: ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() now
http://hg.python.org/cpython/rev/c1d2c90ece99

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20025>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:48:47 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 15:48:47 +0000
Subject: [issue20025] ssl.RAND_bytes() and ssl.RAND_pseudo_bytes() don't check
 if num is negative
In-Reply-To: <1387452510.42.0.848389239504.issue20025@psf.upfronthosting.co.za>
Message-ID: <1387468127.48.0.691952340233.issue20025@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20025>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:52:33 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 15:52:33 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387468353.21.0.956402837931.issue19967@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch to address Guido's comments.

----------
Added file: http://bugs.python.org/file33214/asyncio_log_traceback-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Thu Dec 19 16:56:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 15:56:50 +0000
Subject: [issue20024] Py_BuildValue() can call Python code with an exception
 set
In-Reply-To: <1387451611.0.0.792673049242.issue20024@psf.upfronthosting.co.za>
Message-ID: <1387468610.06.0.07983764352.issue20024@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20024>
_______________________________________

From report at bugs.python.org  Thu Dec 19 17:14:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 16:14:53 +0000
Subject: [issue19983] Ctrl-C at startup can end in a Py_FatalError call
In-Reply-To: <1387074538.57.0.560740834981.issue19983@psf.upfronthosting.co.za>
Message-ID: <1387469693.37.0.41362390211.issue19983@psf.upfronthosting.co.za>


STINNER Victor added the comment:

init_error.patch: modify Py_Initialize() to exit with exit(1) instead of abort(), to not call the sytem fault handler (ex: dump a coredump on Linux, or open a popup on Windows).

The patch calls also initsigs() before initfsencoding(), because initfsencoding() may call Python code (encodings implemented in Python).

Example with gdb (to simulate a CTRL+c during Python startup):

$ gdb ./python
(gdb) b initfsencoding 
(gdb) run
Breakpoint 1, initfsencoding (interp=0x971420) at Python/pythonrun.c:972
(gdb) signal SIGINT
(gdb) cont
Python initialization error: Unable to get the locale encoding
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 2152, in _find_and_load
KeyboardInterrupt
[Inferior 1 (process 15566) exited with code 01]

The process exited with exit code 1, not with SIGABRT.

----------
keywords: +patch
Added file: http://bugs.python.org/file33215/init_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19983>
_______________________________________

From report at bugs.python.org  Thu Dec 19 17:56:41 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 16:56:41 +0000
Subject: [issue19997] imghdr.what doesn't accept bytes paths
In-Reply-To: <1387198093.92.0.388328564702.issue19997@psf.upfronthosting.co.za>
Message-ID: <1387472201.26.0.862716811879.issue19997@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
dependencies: +Add unittests for imghdr module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19997>
_______________________________________

From report at bugs.python.org  Thu Dec 19 18:47:51 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 Dec 2013 17:47:51 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387475271.5.0.603464916087.issue19967@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

So the new patch is fine, but I still think it's confusing that the _tb_logger variable has a different type depending on the Python version.  If you really don't want to fix this, just go ahead and check in, it's not a blocker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Thu Dec 19 19:12:43 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 18:12:43 +0000
Subject: [issue19493] Report skipped ctypes tests as skipped
In-Reply-To: <1383569878.45.0.454771857446.issue19493@psf.upfronthosting.co.za>
Message-ID: <1387476763.76.0.402689890466.issue19493@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


Added file: http://bugs.python.org/file33216/skip_tests_ctypes.v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19493>
_______________________________________

From report at bugs.python.org  Thu Dec 19 19:26:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 18:26:05 +0000
Subject: [issue19493] Report skipped ctypes tests as skipped
In-Reply-To: <1383569878.45.0.454771857446.issue19493@psf.upfronthosting.co.za>
Message-ID: <1387477565.17.0.844049513247.issue19493@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new patch addressing your review comment, Serhiy.  It also addresses some failures on Windows in test_values: Win_ValuesTestCase depends on 'pydll' being defined in the module toplevel and shadowing ctypes.pydll; this definition was removed some years ago (before ctypes was merged into Python).  I replaced each instance of 'pydll' with 'pythonapi', which makes the tests pass (with appropriate update to test_frozentable's expectations), but I don't understand all of ctypes well enough to be sure that it is definitely the correct fix.

Also, a few long lines that were already touched have been split (without messing with other long lines) and a couple of tests have been converted from "def X_test" to "def test_X" with an unconditional skip.  Another empty file has also been removed: test_errcheck is completely commented out except for a couple of imports, so it is removed entirely.  The test that calls doctest.testmod in test_objects has been adjusted to fail the test if any of the doctests fail, and to not care about sys.version.  Finally, test_wintypes has been rearranged to skip the test class rather than the module on non-Windows platforms to keep the same number of tests between platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19493>
_______________________________________

From report at bugs.python.org  Thu Dec 19 19:38:12 2013
From: report at bugs.python.org (gudge)
Date: Thu, 19 Dec 2013 18:38:12 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387478292.99.0.452020806799.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Patch is uploaded.
I will also copy paste it.

I have created the patch with git. Let me know if it is okay with you.
 If it is unacceptable I will try and create one for mercury

Patch:
------------------------------------------------------------------
diff --combined Doc/library/ssl.rst
index a6ce5d6,30cb732..0000000
--- a/Doc/library/ssl.rst
+++ b/Doc/library/ssl.rst
@@@ -366,7 -366,7 +366,7 @@@ Certificate handlin
  
       >>> import ssl
       >>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
 -     1178694000.0
 +     1178668800 
       >>> import time
       >>> time.ctime(ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT"))
       'Wed May  9 00:00:00 2007'
diff --combined Lib/ssl.py
index f81ef91,052a118..0000000
--- a/Lib/ssl.py
+++ b/Lib/ssl.py
@@@ -852,8 -852,7 +852,8 @@@ def cert_time_to_seconds(cert_time)
      a Python time value in seconds past the epoch."""
  
      import time
 -    return time.mktime(time.strptime(cert_time, "%b %d %H:%M:%S %Y GMT"))
 +    import calendar 
 +    return calendar.timegm(time.strptime(cert_time, "%b %d %H:%M:%S %Y GMT"))
  
  PEM_HEADER = "-----BEGIN CERTIFICATE-----"
  PEM_FOOTER = "-----END CERTIFICATE-----"

-----------------------------------------------------------------

Test Results:
358 tests OK.
1 test failed:
    test_compileall
1 test altered the execution environment:
    test___all__
28 tests skipped:
    test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
    test_codecmaps_kr test_codecmaps_tw test_curses test_dbm_gnu
    test_dbm_ndbm test_devpoll test_idle test_kqueue test_lzma
    test_msilib test_ossaudiodev test_smtpnet test_socketserver
    test_sqlite test_startfile test_tcl test_timeout test_tk
    test_ttk_guionly test_ttk_textonly test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64
------------------------------------------------------------------------

Doc changes won't effect the code. The tests would not fail. 
How would I check if the doc changes are coming up fine in the 
final version.

>>> import ssl
>>> ssl.cert_time_to_seconds("May  9 00:00:00 2007 GMT")
1178668800


I do not have a printer curretly. I will sign the license agreement 
in a few days.

----------
Added file: http://bugs.python.org/file33217/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Thu Dec 19 19:59:41 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 18:59:41 +0000
Subject: [issue18576] Rename and document test.script_helper as
 test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1387479581.26.0.996605680034.issue18576@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/issue18576>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:11:45 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 19:11:45 +0000
Subject: [issue16492] Add a load_parents argument to importlib.find_loader()
In-Reply-To: <1353163131.46.0.896555939151.issue16492@psf.upfronthosting.co.za>
Message-ID: <1387480305.03.0.365240387561.issue16492@psf.upfronthosting.co.za>


Eric Snow added the comment:

find_loader() is now deprecated and we're going to support auto-importing parent modules in find_spec() (see #19944)

----------
nosy: +eric.snow
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> Make importlib.find_spec load packages as needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16492>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:12:28 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 19:12:28 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1387480348.04.0.508854878248.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've closed #16492 in favor of this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:21:55 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 19:21:55 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <3dljdF74MNz7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 3d805bee06e2 by Serhiy Storchaka in branch '2.7':
Issue #5815: Fixed support for locales with modifiers.  Fixed support for
http://hg.python.org/cpython/rev/3d805bee06e2

New changeset 28883e89f335 by Serhiy Storchaka in branch '3.3':
Issue #5815: Fixed support for locales with modifiers.  Fixed support for
http://hg.python.org/cpython/rev/28883e89f335

New changeset b50971bccfc3 by Serhiy Storchaka in branch 'default':
Issue #5815: Fixed support for locales with modifiers.  Fixed support for
http://hg.python.org/cpython/rev/b50971bccfc3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:22:23 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 19:22:23 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <1387480943.58.0.378451386835.issue19648@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The patch looks good to me, but I can't claim to know enough about pickle to say whether the tests are correct.  Alexandre or Antoine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:27:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 19:27:01 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1387481221.23.0.375671498329.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed without devanagari special case and tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:33:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Dec 2013 19:33:29 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1387478292.99.0.452020806799.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387481605.2306.4.camel@fsol>


Antoine Pitrou added the comment:

Answering to your questions:

> I have created the patch with git. Let me know if it is okay with you.

Yes, it's ok.
Also, please don't copy / paste it. Uploading is enough.

> Doc changes won't effect the code. The tests would not fail. 
> How would I check if the doc changes are coming up fine in the 
> final version.

The devguide has detailed documentation about how to modify and build
the documentation :)
http://docs.python.org/devguide/documenting.html#building-the-documentation

As for the tests:

1. for this issue you should probably concentrate on test_ssl: to run it
in verbose mode, "./python -m test -v test_ssl"
(please read http://docs.python.org/devguide/runtests.html)

2. you will need to add a new test to test_ssl, to check that this bug
is indeed fixed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:37:41 2013
From: report at bugs.python.org (Marc Schlaich)
Date: Thu, 19 Dec 2013 19:37:41 +0000
Subject: [issue777588] asyncore is broken for windows if connection is refused
Message-ID: <1387481861.5.0.725319138892.issue777588@psf.upfronthosting.co.za>


Changes by Marc Schlaich <marc.schlaich at googlemail.com>:


----------
nosy:  -schlamar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue777588>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:42:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 19:42:08 +0000
Subject: [issue20027] Fixed support for Indian locales
Message-ID: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The locales alias table contains invalid entries for devanagari modifiers (see issue5815):

    'ks_in at devanagari':                     'ks_IN at devanagari.UTF-8',
    'sd':                                   'sd_IN at devanagari.UTF-8',

Here is a patch which fixes aliases for these locales.

----------
components: Library (Lib)
files: locale_aliases.patch
keywords: patch
messages: 206636
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fixed support for Indian locales
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33218/locale_aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:47:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 19:47:43 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <3dlkC22r8xz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 2737c0e7ba71 by Zachary Ware in branch '2.7':
Issue #19683: Removed empty tests from test_minidom.
http://hg.python.org/cpython/rev/2737c0e7ba71

New changeset 5e510117b71a by Zachary Ware in branch '3.3':
Issue #19683: Removed empty tests from test_minidom.  Patch by Ajitesh Gupta.
http://hg.python.org/cpython/rev/5e510117b71a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:48:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 19:48:42 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1387482522.95.0.441416403081.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For devanagari modifier opened new issue20027.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:49:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 19:49:09 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387482549.86.0.847097511344.issue20027@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file33218/locale_aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:49:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 19:49:41 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387482581.19.0.792879955915.issue20027@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file33219/locale_devanagari.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:55:31 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 19:55:31 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1387482931.39.0.687292939873.issue19683@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the removal patch, Ajitesh!

Julian, are you still working on implementing the tests on default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:56:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 19:56:22 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387482982.36.0.547079503487.issue19967@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"So the new patch is fine, but I still think it's confusing that the _tb_logger variable has a different type depending on the Python version."

To be honest, I'm also concerned by this strange variable :-) Here is a new fix which reuses the name used in the first patch (_traceback).

----------
Added file: http://bugs.python.org/file33220/asyncio_log_traceback-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Thu Dec 19 20:57:19 2013
From: report at bugs.python.org (Julian Gindi)
Date: Thu, 19 Dec 2013 19:57:19 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1387483039.23.0.752057893899.issue19683@psf.upfronthosting.co.za>


Julian Gindi added the comment:

I have not started yet, wasn't completely sure of the status of this. I'll get going filling in those tests to the best of my ability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:18:54 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 20:18:54 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1387484334.19.0.50262618081.issue19683@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Alright, sounds good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:19:07 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 20:19:07 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1387484347.9.0.0503148539068.issue19683@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
versions: +Python 3.4 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:21:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 20:21:44 +0000
Subject: [issue19493] Report skipped ctypes tests as skipped
In-Reply-To: <1383569878.45.0.454771857446.issue19493@psf.upfronthosting.co.za>
Message-ID: <1387484504.09.0.617966028757.issue19493@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can't say anything about pydll, other changes LGTM. Except that I'm not sure that test_wintypes needs a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19493>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:22:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 20:22:09 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387484529.1.0.859622357267.issue19967@psf.upfronthosting.co.za>


STINNER Victor added the comment:

asyncio_log_traceback-5.patch: new try :-)

----------
Added file: http://bugs.python.org/file33221/asyncio_log_traceback-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:24:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Dec 2013 20:24:29 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1387484669.01.0.381867244168.issue5815@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbot failure:

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.3/builds/1314/steps/test/logs/stdio

======================================================================
ERROR: test_locale_alias (test.test_locale.NormalizeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.3.murray-gentoo-wide/build/Lib/test/test_locale.py", line 374, in test_locale_alias
    with self.subTest(locale=(localename, alias)):
AttributeError: 'NormalizeTest' object has no attribute 'subTest'

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:32:49 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 20:32:49 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <3dllC46CdZz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset e0675408f4af by Serhiy Storchaka in branch '2.7':
Don't use sebTest() in tests for issue #5815.
http://hg.python.org/cpython/rev/e0675408f4af

New changeset ed16f6695638 by Serhiy Storchaka in branch '3.3':
Don't use sebTest() in tests for issue #5815.
http://hg.python.org/cpython/rev/ed16f6695638

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:34:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Dec 2013 20:34:17 +0000
Subject: [issue5815] locale.getdefaultlocale() missing corner case
In-Reply-To: <1240424446.58.0.284100987299.issue5815@psf.upfronthosting.co.za>
Message-ID: <1387485257.08.0.744291340175.issue5815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, thanks Victor.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5815>
_______________________________________

From report at bugs.python.org  Thu Dec 19 21:36:10 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 Dec 2013 20:36:10 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387485370.95.0.741015408968.issue19967@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Looks good. I can fix that long line myself. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Thu Dec 19 22:34:11 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 21:34:11 +0000
Subject: [issue19493] Report skipped ctypes tests as skipped
In-Reply-To: <1383569878.45.0.454771857446.issue19493@psf.upfronthosting.co.za>
Message-ID: <1387488851.69.0.666721585778.issue19493@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'd prefer to keep the change to test_wintypes, simply because I was rather surprised to find an extra test being run on Windows.

As for the pydll/pythonapi issue, any thoughts from Amaury, Meador, or Alexander?  The relevant change that removed the definition of pydll in test_values can be found here[1].  That also makes me wonder why exactly the test is named "*Win*_ValuesTestCase" and whether it actually needs a skip or just a rename, since there doesn't appear to me to be anything related to Windows about the test.


[1] http://ctypes.cvs.sourceforge.net/viewvc/ctypes/ctypes/ctypes/test/test_values.py?hideattic=0&r1=1.1.2.1&r2=1.1.2.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19493>
_______________________________________

From report at bugs.python.org  Thu Dec 19 22:35:05 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 19 Dec 2013 21:35:05 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387488905.1.0.192927069726.issue19946@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The OpenIndiana tests are still failing. OpenIndiana doesn't support forkserver because it doesn't implement the send handle feature. The patch skips the forkserver tests if HAVE_SEND_HANDLE is false.

----------
Added file: http://bugs.python.org/file33222/skip_forkserver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Thu Dec 19 22:40:04 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 Dec 2013 21:40:04 +0000
Subject: [issue17202] Add .bat line to .hgeol
In-Reply-To: <1360824086.93.0.558513852083.issue17202@psf.upfronthosting.co.za>
Message-ID: <1387489204.42.0.653879697655.issue17202@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Any objections to proceeding with this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17202>
_______________________________________

From report at bugs.python.org  Thu Dec 19 22:43:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Dec 2013 21:43:21 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <3dlmmS6x7Gz7LjY@mail.python.org>


Roundup Robot added the comment:

New changeset 5e9728ebb1d3 by Victor Stinner in branch 'default':
Close #19967: Thanks to the PEP 442, asyncio.Future can use a destructor in
http://hg.python.org/cpython/rev/5e9728ebb1d3

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Thu Dec 19 23:00:13 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 Dec 2013 22:00:13 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1387488905.1.0.192927069726.issue19946@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eP_avr4j+yZORC=U7HDpCpxmRqXTFUf+4RBuCFNxt6BA@mail.gmail.com>


Nick Coghlan added the comment:

I think that needs to be fixed on the multiprocessing side rather than just
in the tests - we shouldn't create a concrete context for a start method
that isn't going to work on that platform. Finding that kind of discrepancy
was part of my rationale for basing the skips on the available contexts
(although my main motivation was simplicity).

There may also be docs implications in describing which methods are
supported on different platforms (although I haven't looked at how that is
currently documented).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Thu Dec 19 23:54:12 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 19 Dec 2013 22:54:12 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387493652.4.0.631099465751.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm glad you spoke up, Nick.  Holding off on the DeprecationWarnings is fine with me.  It's not like we are going to drop support for the APIs before Python 4!  That said, DeprecationWarnings are disabled by default.  So how big a deal do you think it is to leave the warnings in (minus loader.load_module)?  I simply don't have a sense of how often people would be running with all warnings enabled (and not want that to let them know about these deprecations).

The latest patch already yanks most of the load_module() warnings.  It had slipped my mind in the first patch.  Of the warnings that are left, I'd still like to leave them in for:

* importlib.find_loader()
* NamespaceLoader (still not sure what to think about that class)
* loader.module_repr() (if I can figure out a good way to make it work) since it will end up being a 3.3-only feature
* importlib.util.set_loader()
* importlib.util.set_package()

That basically leaves removing warnings for finders (and maybe one or two others I missed):

* finder.find_module()
* finder.find_loader()

As I said, I'm fine with doing so (or even pulling all the warnings).  I simply thought of the warnings as a service to Python users to make them aware of the deprecations if they chose to check.  However, I haven't been doing this nearly as long as you. :)  So I'll readily concede that I may be missing something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Fri Dec 20 01:38:03 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 20 Dec 2013 00:38:03 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <CADiSq7eP_avr4j+yZORC=U7HDpCpxmRqXTFUf+4RBuCFNxt6BA@mail.gmail.com>
Message-ID: <52B39168.7050105@gmail.com>


Richard Oudkerk added the comment:

On 19/12/2013 10:00 pm, Nick Coghlan wrote:
> I think that needs to be fixed on the multiprocessing side rather than just
> in the tests - we shouldn't create a concrete context for a start method
> that isn't going to work on that platform. Finding that kind of discrepancy
> was part of my rationale for basing the skips on the available contexts
> (although my main motivation was simplicity).
>
> There may also be docs implications in describing which methods are
> supported on different platforms (although I haven't looked at how that is
> currently documented).
>
If by "concrete context" you mean _concrete_contexts['forkserver'], then 
that is supposed to be private.  If you write

     ctx = multiprocessing.get_context('forkserver')

then this will raise ValueError if the forkserver method is not 
available.  You can also use

    'forkserver' in multiprocessing.get_all_start_methods()

to check if it is available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 20 02:09:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Dec 2013 01:09:26 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387501766.52.0.762073937439.issue19967@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think this patch is bad and should be reverted. It always calls traceback.format_exception() which is an expensive operation, while the _TracebackLogger takes care to call it only when necessary.

----------
assignee:  -> haypo
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Fri Dec 20 02:19:37 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 01:19:37 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1387501766.52.0.762073937439.issue19967@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJK=+K1D7yB3nkqMgYG=v0TfC_hc9phuPy05FEYCxnN_A@mail.gmail.com>


Guido van Rossum added the comment:

Eew. You're right. Sorry I didn't see this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Fri Dec 20 02:52:48 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Dec 2013 01:52:48 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1387493652.4.0.631099465751.issue19713@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eD2Kw+aVBJ0iOsM79f6ozbNEbYBK+c8_Sc8BVfrG=U4g@mail.gmail.com>


Nick Coghlan added the comment:

Test suites enable deprecation warnings by default, and many projects
have a "no warnings allowed" rule. By adding programmatic deprecation
warnings for the old APIs where there's no other way to it in a 3.3
compatible way, we make things more difficult for people that still
need to support 3.3. I'm OK with doing that when there's a concrete
payoff in significantly reducing our maintenance burden, eliminating
an attractive nuisance (I took that as far as removing
contextlib.nested entirely before coming up with ExitStack as a
replacement), or when there's a concrete benefit to the *user* in
migrating, but otherwise lean towards the "I want major Python
upgrades to be exciting, not annoying" school of thought most of the
time.

And yes, I'm biased through working on package stuff - all of that
needs to straddle 2.6+ and 3.2+ due to platform support requirements,
and I want people to be free to work on metadata 2.0 rather than
figuring out how to avoid new deprecation warnings :)

Your updated list of suggested near-term deprecations sounds a lot
more reasonable to me - that stuff is all 3.3 specific, and the
packaging ecosystem hasn't really adjusted to those yet anyway (given
the heavy 2.6+ and 3.2+ bias). It was mostly the method deprecations
that bothered me, since providing the "lowest common denominator" APIs
is the easiest way to implement cross version compatible finders and
loaders.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Fri Dec 20 02:58:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Dec 2013 01:58:02 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387504682.27.0.910992230876.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, I should have looked more closely at the docs to see if there was a public API for that before poking around in the package internals.

In that case, I suggest we change this bit in the test:

    # We look inside the context module to find out which
    # start methods we can check
    from multiprocessing.context import _concrete_contexts

to use the appropriate public API:

    # Need to know which start methods we should test
    import multiprocessing
    AVAILABLE_START_METHODS = set(multiprocessing.get_all_start_methods())

And then adjust the skip check to look in AVAILABLE_START_METHODS rather than _concrete_contexts.

I'll make that change tonight if nobody beats me to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 20 03:23:31 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2013 02:23:31 +0000
Subject: [issue19713] Deprecate various things in importlib thanks to PEP 451
In-Reply-To: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>
Message-ID: <1387506211.82.0.889382682103.issue19713@psf.upfronthosting.co.za>


Eric Snow added the comment:

Sounds good.  Thanks for the explanation.  It sounds like you're effectively concerned just with finder.find_module() and loader.load_module() (which is fine with me).  Everything else (including some of the ABCs) is 3.3-only.  For the sake of simplicity I could also leave the warnings off finder.find_loader() as well (if you want).

Sorry for all the fuss.  I've never *really* deprecated anything before. :)  This has been really helpful.  I see the value in the warnings (when things are going to be removed later vs. "there's something better"), but also see your point about the pain warnings can cause (especially when we don't have concrete plans for removal).  What a weird balance.

p.s. If only I had a time machine to put PendingDeprecationWarnings on those 3.3-only APIs!  <wink>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19713>
_______________________________________

From report at bugs.python.org  Fri Dec 20 03:38:03 2013
From: report at bugs.python.org (Alan Justino)
Date: Fri, 20 Dec 2013 02:38:03 +0000
Subject: [issue3566] httplib persistent connections violate MUST in RFC2616
 sec 8.1.4.
In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za>
Message-ID: <1387507083.95.0.691184840038.issue3566@psf.upfronthosting.co.za>


Alan Justino added the comment:

Seems to affect 2.7 too.

----------
nosy: +alanjds
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3566>
_______________________________________

From report at bugs.python.org  Fri Dec 20 04:03:22 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Dec 2013 03:03:22 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1387508602.51.0.459801271158.issue19524@psf.upfronthosting.co.za>


Martin Panter added the comment:

How is it safer to manually set ?h.sock._closed?? Playing with the internals of HTTPConnection is one thing, but playing with the internals of the socket object as well does not seem necessary.

Also the ResourceWarning is warning that the socket and connection were closed by the garbage collector at some arbitrary point. I don?t think a new __del__() method is going to help. Sorry to be so negative :)

Related issues:
Issue 18144: FD leak in urllib2 (probably an exact dupe)
Issue 11563: test_urllibnet is triggering a ResourceWarning (bug closed, but real issue was only side-stepped IMO)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Fri Dec 20 05:38:14 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 04:38:14 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
Message-ID: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Python 3.4.0b1 (default:13a505260f17, Dec 20 2013, 12:02:44) 
[GCC 4.7.2] on linux
>>> import _csv
>>> import csv
>>> _csv.Dialect(quotechar=b'+')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: "quotechar" must be string, not bytes

Hey, that's not true. Quotechar can be None.

>>> _csv.Dialect(quotechar=None)
<_csv.Dialect object at 0x7f64a8534790>

>>> _csv.Dialect(quotechar="cutecat")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: "quotechar" must be an 1-character string

That's not strictly true. Quotechar can be 0-character string in certain situation.

>>> _csv.Dialect(quotechar="", quoting=csv.QUOTE_NONE)
<_csv.Dialect object at 0x7f64a85345f0>

Python 2.7 suffers the same issue.

----------
components: Library (Lib)
messages: 206663
nosy: r.david.murray, serhiy.storchaka, vajrasky
priority: normal
severity: normal
status: open
title: Confusing error message when giving invalid quotechar in initializing csv dialect
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 06:03:54 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Dec 2013 05:03:54 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1387515834.61.0.836653152973.issue19977@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/issue19977>
_______________________________________

From report at bugs.python.org  Fri Dec 20 06:13:28 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2013 05:13:28 +0000
Subject: [issue16000] test_curses should use unittest
In-Reply-To: <1348263086.74.0.172285441847.issue16000@psf.upfronthosting.co.za>
Message-ID: <1387516408.13.0.709769495706.issue16000@psf.upfronthosting.co.za>


Zachary Ware added the comment:

It's only taken me 6 months, but I'm looking at this issue again :)

Ed, basically the only reason I used setUpModule was because it was a very direct translation from test_main to setUpModule--only the name and signature changed, the skip and initialization code stayed exactly the same.  It does make more sense for it to be in setUpClass, though, so that's done in the new patch.

Thanks for pointing out the typo, fixed.

----------
Added file: http://bugs.python.org/file33223/issue16000.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16000>
_______________________________________

From report at bugs.python.org  Fri Dec 20 06:37:38 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 20 Dec 2013 05:37:38 +0000
Subject: [issue20009] Property should expose wrapped function.
In-Reply-To: <1387316995.02.0.931185950843.issue20009@psf.upfronthosting.co.za>
Message-ID: <1387517858.95.0.64351669645.issue20009@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ncoghlan
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20009>
_______________________________________

From report at bugs.python.org  Fri Dec 20 07:37:34 2013
From: report at bugs.python.org (akira)
Date: Fri, 20 Dec 2013 06:37:34 +0000
Subject: [issue20029] asyncio.SubprocessProtocol is missing
Message-ID: <1387521454.41.0.193901809521.issue20029@psf.upfronthosting.co.za>


New submission from akira:

`SubprocessProtocol` is documented  to be accessible as `asyncio.SubprocessProtocol` [1] but it is not included in `asyncio.protocols.__all__` [2] that leads to `AttributeError`:

    python3.4 -c "import asyncio; asyncio.SubprocessProtocol"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    AttributeError: 'module' object has no attribute 'SubprocessProtocol'

The following works as expected:

    python3.4 -c "import asyncio; asyncio.protocols.SubprocessProtocol"

No error.

[1]: http://docs.python.org/3.4/library/asyncio-protocol.html#asyncio.SubprocessProtocol

[2]: http://hg.python.org/cpython/file/13a505260f17/Lib/asyncio/protocols.py#l3

----------
components: Library (Lib)
messages: 206665
nosy: akira
priority: normal
severity: normal
status: open
title: asyncio.SubprocessProtocol is missing
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20029>
_______________________________________

From report at bugs.python.org  Fri Dec 20 07:48:26 2013
From: report at bugs.python.org (akira)
Date: Fri, 20 Dec 2013 06:48:26 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387522106.54.0.692172628848.issue19940@psf.upfronthosting.co.za>


akira added the comment:

gudge, have you seen http://bugs.python.org/msg205860 (the locale issue)?

If you can't fix it; say so, I'll open another issue after this issue is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:29:15 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 07:29:15 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
In-Reply-To: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>
Message-ID: <1387524555.25.0.797952300801.issue20028@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch for Python 3.3 and 3.4.

----------
keywords: +patch
Added file: http://bugs.python.org/file33224/fix_handling_invalid_quotechar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:36:27 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 07:36:27 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
In-Reply-To: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>
Message-ID: <1387524987.04.0.920619746497.issue20028@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the preliminary patch for Python 2.7.

----------
Added file: http://bugs.python.org/file33225/fix_handling_invalid_quotechar_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:43:48 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 07:43:48 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
In-Reply-To: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>
Message-ID: <1387525428.78.0.210786540309.issue20028@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33224/fix_handling_invalid_quotechar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:44:05 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 07:44:05 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
In-Reply-To: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>
Message-ID: <1387525445.98.0.765735471563.issue20028@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33226/fix_handling_invalid_quotechar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:44:13 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 07:44:13 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
In-Reply-To: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>
Message-ID: <1387525453.87.0.984385544444.issue20028@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Removed file: http://bugs.python.org/file33225/fix_handling_invalid_quotechar_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 08:44:25 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 20 Dec 2013 07:44:25 +0000
Subject: [issue20028] Confusing error message when giving invalid quotechar in
 initializing csv dialect
In-Reply-To: <1387514294.66.0.0650917642902.issue20028@psf.upfronthosting.co.za>
Message-ID: <1387525465.85.0.157868931388.issue20028@psf.upfronthosting.co.za>


Changes by Vajrasky Kok <sky.kok at speaklikeaking.com>:


Added file: http://bugs.python.org/file33227/fix_handling_invalid_quotechar_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20028>
_______________________________________

From report at bugs.python.org  Fri Dec 20 09:45:07 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 20 Dec 2013 08:45:07 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387529107.59.0.602417787609.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

Unless there are objections, I'll commit this in the next day or two.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:02:25 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Fri, 20 Dec 2013 09:02:25 +0000
Subject: [issue20030] unittest.TestLoader.discover return value incorrectly
 documented.
Message-ID: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

Here: http://docs.python.org/3/library/unittest.html#unittest.TestLoader.discover

it states that "Find and return all test modules ..."

This implies that in order to get a test suite, one has to iterate over the return value of unittest.TestLoader.discover and call loadTestsFromModule for each module.

But, the type of the result of unittest.TestLoader.discover returns: <class 'unittest.suite.TestSuite'>

----------
assignee: docs at python
components: Documentation
messages: 206670
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: unittest.TestLoader.discover return value incorrectly documented.
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20030>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:08:19 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Fri, 20 Dec 2013 09:08:19 +0000
Subject: [issue20031] unittest.TextTestRunner missing run() documentation.
Message-ID: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

Here: http://docs.python.org/3/library/unittest.html

1) unittest.TextTestRunner is missing documentation for its public run method.

2) There are references to the TestRunner class sprinkled through out the above page, yet no link or documentation as to what that class actually is and does.

----------
assignee: docs at python
components: Documentation
messages: 206671
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: unittest.TextTestRunner missing run() documentation.
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20031>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:23:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Dec 2013 09:23:58 +0000
Subject: [issue20031] unittest.TextTestRunner missing run() documentation.
In-Reply-To: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>
Message-ID: <1387531438.04.0.782285182011.issue20031@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20031>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:24:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Dec 2013 09:24:21 +0000
Subject: [issue20030] unittest.TestLoader.discover return value incorrectly
 documented.
In-Reply-To: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za>
Message-ID: <1387531461.81.0.229217768576.issue20030@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti, michael.foord
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20030>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:24:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Dec 2013 09:24:32 +0000
Subject: [issue20031] unittest.TextTestRunner missing run() documentation.
In-Reply-To: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>
Message-ID: <1387531472.01.0.900305686807.issue20031@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20031>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:55:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 09:55:04 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
Message-ID: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>


New submission from STINNER Victor:

asyncio.Future.set_exception(exc) sets the exception attribute to exc, but exc.__traceback__ refers to frames and the current frame probably referes to the future instance.

Tell me if I'm wrong, but it looks like a reference cycle:
fut -- fut.exception --> exception --exception.__traceback__ -> traceback --traceback.tb_frame --> frame --frame.fb_locals --> fut

The frame class got a new clear() method in Python 3.4:
http://docs.python.org/dev/reference/datamodel.html#frame.clear

Maybe because of the PEP 442, the reference cycle is no more an issue. In fact, the following example calls fut destructor immediatly, at "fut = None" line.
---
import asyncio

fut = asyncio.Future()
try:
    raise ValueError()
except Exception as err:
    fut.set_exception(err)
fut = None
---

Attached patch breaks explicitly the reference cycle by scheduling a call to traceback.clear_frames() using call_soon(). The patch depends on asyncio_defer_format_tb.patch which is attached to the issue #19967.

----------
files: asyncio_break_ref_cycle.patch
keywords: patch
messages: 206672
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio.Future.set_exception() creates a reference cycle
versions: Python 3.4
Added file: http://bugs.python.org/file33228/asyncio_break_ref_cycle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:55:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 09:55:28 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387533328.06.0.922737653156.issue19967@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I think this patch is bad and should be reverted. It always calls traceback.format_exception() which is an expensive operation, while the _TracebackLogger takes care to call it only when necessary.

Oh, I didn't notice that, and I agree that the new code is inefficient.

Since the Future object does not release the reference to the exception after result() or exception() has been called, there is no need to preformat the exception. It can be done in the destructor.

Attached asyncio_defer_format_tb.patch implements that.

Future.set_exception() creates a reference cycle. I created the issue #20032 to discuss that.

----------
resolution: fixed -> 
Added file: http://bugs.python.org/file33229/asyncio_defer_format_tb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Fri Dec 20 10:57:13 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 09:57:13 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387533433.36.0.763419760419.issue20032@psf.upfronthosting.co.za>


STINNER Victor added the comment:

asyncio_break_ref_cycle.patch does not fix the issue on Python 3.3 (for Tulip).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:05:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 11:05:01 +0000
Subject: [issue20033] Fix makelocalealias.py for Python 3
Message-ID: <1387537501.53.0.333984460427.issue20033@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When Tools/i18n/makelocalealias.py was ported to Python 3 some things were not fixed.

1. locale.alias is opened as binary file in Python 2, but as text file (with locale encoding) in Python 3. This can cause fail when the script runs in UTF-8 locale because locale.alias contains non-ASCII locales ('bokm?l' and 'fran?ais', encoded in Latin1).

2. In Python 2 %r formatting always produce ASCII output. In Python 3 %a should be used to produce the same output.

Proposed patch fixes these minor bugs.

----------
components: Demos and Tools
files: locale_py3k.patch
keywords: patch
messages: 206675
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix makelocalealias.py for Python 3
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33230/locale_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20033>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:19:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 11:19:10 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387538350.72.0.64732603696.issue20027@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file33231/locale_devanagari_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:22:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 11:22:50 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387538570.86.0.897845855378.issue20027@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file33219/locale_devanagari.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 12:36:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 11:36:45 +0000
Subject: [issue20034] Update locale alias table
Message-ID: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch updates locale alias table to most recent locale.alias file (from X.org 7.7 distribution).

----------
components: Library (Lib)
files: locale_aliases_77.patch
keywords: patch
messages: 206676
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Update locale alias table
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33232/locale_aliases_77.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:18:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Dec 2013 12:18:00 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <3dm89g0xMcz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 00d09afb57ca by Nick Coghlan in branch 'default':
Issue #19946: use public API for multiprocessing start methods
http://hg.python.org/cpython/rev/00d09afb57ca

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:19:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Dec 2013 12:19:14 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387541954.93.0.546648254577.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Pending a clean bill of health from the stable buildbots :)

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 20 13:47:47 2013
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 20 Dec 2013 12:47:47 +0000
Subject: [issue19736] posixmodule.c: Add flags for statvfs.f_flag to constant
 list
In-Reply-To: <1385222125.46.0.688361383331.issue19736@psf.upfronthosting.co.za>
Message-ID: <1387543667.3.0.221545031195.issue19736@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19736>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:23:45 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 Dec 2013 13:23:45 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>
Message-ID: <52B444D8.7020306@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.12.2013 12:36, Serhiy Storchaka wrote:
> 
> Proposed patch updates locale alias table to most recent locale.alias file (from X.org 7.7 distribution).

Looks good.

BTW, regarding the devanagari cases:

There is some recent activity in glibc related to these. Here's a
patch that adds the  sd_IN at devanagari locale to glibc:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/sd_IN at devanagari.diff?cvsroot=glibc&r1=NONE&r2=1.1

So they will start working once platforms adopt the new
glibc versions.

The @-modifier is applied to the locale, not the encoding, because
the locale uses a different script, as opposed to limiting itself
to part of an encoding. This looks reasonable, even though I'm
not sure it conforms to standards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:26:32 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 Dec 2013 13:26:32 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387538350.76.0.241967489278.issue20027@psf.upfronthosting.co.za>
Message-ID: <52B44580.4050207@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.12.2013 12:19, Serhiy Storchaka wrote:
> 
> Added file: http://bugs.python.org/file33231/locale_devanagari_2.patch

See my message on issue20034:

There is some recent activity in glibc related to these. Here's a
patch that adds the  sd_IN at devanagari locale to glibc:
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/sd_IN at devanagari.diff?cvsroot=glibc&r1=NONE&r2=1.1

So they will start working once platforms adopt the new
glibc versions.

The @-modifier is applied to the locale, not the encoding, because
the locale uses a different script, as opposed to limiting itself
to part of an encoding. This looks reasonable, even though I'm
not sure it conforms to standards.

Since all this is still very much in flux, perhaps we ought
to wait a bit more and let the dust settle ?!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 14:44:58 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 Dec 2013 13:44:58 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>
Message-ID: <1387547098.21.0.524413743428.issue20034@psf.upfronthosting.co.za>


Berker Peksag added the comment:

See also issue 16555.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:32:36 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Dec 2013 14:32:36 +0000
Subject: [issue15599] test_threaded_import fails sporadically on Windows and
 FreeBSD
In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za>
Message-ID: <1387549956.16.0.875354684258.issue15599@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Another recent instance of the parallel meta path failure:

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7740/steps/test/logs/stdio

----------
keywords: +buildbot -patch
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15599>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:33:20 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 20 Dec 2013 14:33:20 +0000
Subject: [issue19946] Handle a non-importable __main__ in multiprocessing
In-Reply-To: <1386680939.38.0.901272834161.issue19946@psf.upfronthosting.co.za>
Message-ID: <1387550000.21.0.146672008285.issue19946@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Now passing on all the stable buildbots (the two red Windows bots are for other issues, such as issue 15599 for the threaded import test failure)

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19946>
_______________________________________

From report at bugs.python.org  Fri Dec 20 15:55:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 14:55:29 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387551329.95.0.75949233797.issue20027@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ubuntu 12.04 supports Kashmiri and Sindhi locales (requires language-pack-sd-base and language-pack-sd-base packages).

$ locale -a
...
ks_IN
ks_IN at devanagari
ks_IN.utf8
ks_IN.utf8 at devanagari
...
sd_IN
sd_IN at devanagari
sd_IN.utf8
sd_IN.utf8 at devanagari
...

Current Python doesn't support all of these locales:

$ LC_ALL=ks_IN ./python -c 'import locale; print(locale.getlocale())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 556, in getlocale
    return _parse_localename(localename)
  File "/home/serhiy/py/cpython/Lib/locale.py", line 465, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: ks_IN
$ LC_ALL=ks_IN at devanagari ./python -c 'import locale; print(locale.getlocale())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 556, in getlocale
    return _parse_localename(localename)
  File "/home/serhiy/py/cpython/Lib/locale.py", line 465, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: ks_IN at devanagari
$ LC_ALL=ks_IN.utf8 ./python -c 'import locale; print(locale.getlocale())'
('ks_IN', 'utf8')
$ LC_ALL=ks_IN.utf8 at devanagari ./python -c 'import locale; print(locale.getlocale())'
('ks_IN', 'UTF-8')
$ LC_ALL=sd_IN ./python -c 'import locale; print(locale.getlocale())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 556, in getlocale
    return _parse_localename(localename)
  File "/home/serhiy/py/cpython/Lib/locale.py", line 465, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: sd_IN
$ LC_ALL=sd_IN at devanagari ./python -c 'import locale; print(locale.getlocale())'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 556, in getlocale
    return _parse_localename(localename)
  File "/home/serhiy/py/cpython/Lib/locale.py", line 465, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: sd_IN at devanagari
$ LC_ALL=sd_IN.utf8 ./python -c 'import locale; print(locale.getlocale())'
('sd_IN', 'utf8')
$ LC_ALL=sd_IN.utf8 at devanagari ./python -c 'import locale; print(locale.getlocale())'
('sd_IN', 'utf8')

After applying the patch Python supports all ks_IN and sd_IN locales.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:06:02 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 Dec 2013 15:06:02 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387551329.95.0.75949233797.issue20027@psf.upfronthosting.co.za>
Message-ID: <52B45CD2.9010501@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.12.2013 15:55, Serhiy Storchaka wrote:
> 
> After applying the patch Python supports all ks_IN and sd_IN locales.

Well, yes, but only because you are removing the @-modifiers. I don't
think that's correct, since e.g. the string formatting used for
numbers is different with the modifier.

If you keep the modifiers, but move them to the end of the locale
string you should get the correct behavior, e.g.

-    'sd':                                   'sd_IN at devanagari.UTF-8',
+    'sd':                                   'sd_IN.UTF-8 at devanagari',

(modulo perhaps the spelling of "UTF-8")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:12:39 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 15:12:39 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <52B444D8.7020306@egenix.com>
Message-ID: <2264132.NrardW6zsV@raxxla>


Serhiy Storchaka added the comment:

> Looks good.

Should these patch be applied only to 3.4 or to all maintained 
releases? I suppose the later, because alias table which is not 
conform recent systems configuration is a bug.

> BTW, regarding the devanagari cases:

This patch only updates the devanagari cases in conform to 
locale.alias file. *Issue20027 should fix support of these cases.*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:24:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 15:24:10 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <52B45CD2.9010501@egenix.com>
Message-ID: <1781450.QVIuIuhGfQ@raxxla>


Serhiy Storchaka added the comment:

> Well, yes, but only because you are removing the @-modifiers. I don't
> think that's correct, since e.g. the string formatting used for
> numbers is different with the modifier.

All the @-modifiers except euro are applied to the locale, not the encoding. 
And Python removes all the @-modifiers, e.g. latin and cyrillic which specify 
the script.

> If you keep the modifiers, but move them to the end of the locale
> string you should get the correct behavior, e.g.
> 
> -    'sd':                                   'sd_IN at devanagari.UTF-8',
> +    'sd':                                   'sd_IN.UTF-8 at devanagari',
> 
> (modulo perhaps the spelling of "UTF-8")

Recent the locale.alias file changes these entities:

sd:						sd_IN.UTF-8
sd_IN.utf8:					sd_IN.UTF-8
sd at devanagari:					sd_IN at devanagari.UTF-8
sd_IN at devanagari:				sd_IN at devanagari.UTF-8
sd_IN at devanagari.utf8:				sd_IN at devanagari.UTF-8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 16:49:48 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 Dec 2013 15:49:48 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <2264132.NrardW6zsV@raxxla>
Message-ID: <52B46714.1080706@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.12.2013 16:12, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> Looks good.
> 
> Should these patch be applied only to 3.4 or to all maintained 
> releases? I suppose the later, because alias table which is not 
> conform recent systems configuration is a bug.

Agreed.

>> BTW, regarding the devanagari cases:
> 
> This patch only updates the devanagari cases in conform to 
> locale.alias file. *Issue20027 should fix support of these cases.*

Ok.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 17:03:47 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 Dec 2013 16:03:47 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1781450.QVIuIuhGfQ@raxxla>
Message-ID: <52B46A59.2060609@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.12.2013 16:24, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> Well, yes, but only because you are removing the @-modifiers. I don't
>> think that's correct, since e.g. the string formatting used for
>> numbers is different with the modifier.
> 
> All the @-modifiers except euro are applied to the locale, not the encoding. 
> And Python removes all the @-modifiers, e.g. latin and cyrillic which specify 
> the script.

That's not quite correct. The modifiers are used to determine the
correct mapping, so you'll often find them on the left side, but
not necessarily on the right side.

There are several cases where the modifiers are kept around,
since they have implications on the way number or dates are
formatted.

For the Indian "devanagari" locales we have to keep them,
because the locale formatting of number and dates depends
on them.

>> If you keep the modifiers, but move them to the end of the locale
>> string you should get the correct behavior, e.g.
>>
>> -    'sd':                                   'sd_IN at devanagari.UTF-8',
>> +    'sd':                                   'sd_IN.UTF-8 at devanagari',
>>
>> (modulo perhaps the spelling of "UTF-8")
> 
> Recent the locale.alias file changes these entities:
> 
> sd:						sd_IN.UTF-8
> sd_IN.utf8:					sd_IN.UTF-8
> sd at devanagari:					sd_IN at devanagari.UTF-8
> sd_IN at devanagari:				sd_IN at devanagari.UTF-8
> sd_IN at devanagari.utf8:				sd_IN at devanagari.UTF-8

I'm not sure I can parse this comment :-)

Looking at issue20034 I think we are saying that the new updated
local.alias file contains these entries:

sd:						sd_IN.UTF-8
sd_IN.utf8:					sd_IN.UTF-8
sd at devanagari:					sd_IN at devanagari.UTF-8
sd_IN at devanagari:				sd_IN at devanagari.UTF-8
sd_IN at devanagari.utf8:				sd_IN at devanagari.UTF-8

So my example is wrong with the new locale.alias file. Instead,
sd will map directly to sd_IN.UTF-8.

Still, I think the makelocalalias.py script should correct
the non-standard locale names from sd_IN at devanagari.UTF-8
to sd_IN.UTF-8 at devanagari in order to match the output
of "locale -a".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 17:24:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Dec 2013 16:24:28 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>
Message-ID: <3dmFf35YRLz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 81f8375e60ce by Serhiy Storchaka in branch '2.7':
Issue #20034: Updated alias mapping to most recent locale.alias file
http://hg.python.org/cpython/rev/81f8375e60ce

New changeset ed62c4c70c4d by Serhiy Storchaka in branch '3.3':
Issue #20034: Updated alias mapping to most recent locale.alias file
http://hg.python.org/cpython/rev/ed62c4c70c4d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 17:27:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 16:27:01 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>
Message-ID: <1387556821.38.0.411863919056.issue20034@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks for your review, Marc-Andre.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 17:30:50 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2013 16:30:50 +0000
Subject: [issue20035] Suppress 'os.environ was modified' warning on Tcl/Tk
 tests
Message-ID: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch refactors tkinter._fix's main logic into a function called 'fix_environ' which is called unconditionally on import, and adds a function 'unfix_environ' to undo the effects of fix_environ.  fix/unfix_environ are then used in all test files that import tkinter (test___all__, test_tcl, test_tk, test_ttk_guionly, test_ttk_textonly, test_idle) to ensure that the environment is properly set to allow Tcl to load and to suppress regrtest's warning that os.environ has been modified.

Since tkinter._fix is an implementation detail, I assume this change isn't against the 'no new features' policy of all currently open branches, but if this needs to wait until 3.5, that's ok with me.

----------
components: Tests, Tkinter
files: suppress_environ_warning.diff
keywords: patch
messages: 206692
nosy: zach.ware
priority: low
severity: normal
stage: patch review
status: open
title: Suppress 'os.environ was modified' warning on Tcl/Tk tests
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33233/suppress_environ_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20035>
_______________________________________

From report at bugs.python.org  Fri Dec 20 17:51:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Dec 2013 16:51:44 +0000
Subject: [issue20034] Update locale alias table
In-Reply-To: <1387539405.64.0.71303309039.issue20034@psf.upfronthosting.co.za>
Message-ID: <3dmGFW43lSz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 72e68af9e2fa by Serhiy Storchaka in branch 'default':
Issue #20034: Updated alias mapping to most recent locale.alias file
http://hg.python.org/cpython/rev/72e68af9e2fa

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20034>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:01:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 17:01:21 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387558881.05.0.612646605565.issue20032@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Do you have an example of code that behaves differently with this patch?  I can't find any.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:07:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 17:07:58 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387559278.09.0.367961292043.issue20027@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch to tip. The makelocalalias.py script now corrects
the non-standard locale names.

----------
Added file: http://bugs.python.org/file33234/locale_devanagari_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:08:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 17:08:17 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1387559297.06.0.233634025479.issue20027@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file33231/locale_devanagari_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:27:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Dec 2013 17:27:05 +0000
Subject: [issue20035] Suppress 'os.environ was modified' warning on Tcl/Tk
 tests
In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za>
Message-ID: <1387560425.15.0.978818997801.issue20035@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks fragile. What if some test will import tkinter after other test "unfix" the environment? I suggest unload the tkinter._fix module in unfix_environ(). Then next import should implicitly fix the environment. And explicit fix_environ() will be not needed.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20035>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:45:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Dec 2013 17:45:33 +0000
Subject: [issue20035] Suppress 'os.environ was modified' warning on Tcl/Tk
 tests
In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za>
Message-ID: <1387561533.06.0.650888710381.issue20035@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/issue20035>
_______________________________________

From report at bugs.python.org  Fri Dec 20 18:47:18 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Dec 2013 17:47:18 +0000
Subject: [issue20035] Suppress 'os.environ was modified' warning on Tcl/Tk
 tests
In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za>
Message-ID: <1387561638.07.0.268158384101.issue20035@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I like that idea, though I'm a bit wary of messing around is sys.modules.  Is there another way to unload a module that I'm not aware of?

Here's a new patch that does that.

----------
Added file: http://bugs.python.org/file33235/suppress_environ_warning.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20035>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:11:01 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 20 Dec 2013 18:11:01 +0000
Subject: [issue20036] Running same doctests not possible on both py3 and py2
Message-ID: <1387563061.69.0.696193662364.issue20036@psf.upfronthosting.co.za>


New submission from Maries Ionel Cristian:

One of these doesn't work depending on how you write the exception name.


 python3 -mdoctest src/tete.rst  
 python -mdoctest src/tete.rst   

One cannot put an ellipsis in the exception name so you see how this is a problem.

----------
components: Demos and Tools, Library (Lib)
files: tete.py
messages: 206698
nosy: ionel.mc
priority: normal
severity: normal
status: open
title: Running same doctests not possible on both py3 and py2
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file33236/tete.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20036>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:11:12 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 20 Dec 2013 18:11:12 +0000
Subject: [issue20036] Running same doctests not possible on both py3 and py2
In-Reply-To: <1387563061.69.0.696193662364.issue20036@psf.upfronthosting.co.za>
Message-ID: <1387563072.43.0.295698561104.issue20036@psf.upfronthosting.co.za>


Changes by Maries Ionel Cristian <ionel.mc at gmail.com>:


Added file: http://bugs.python.org/file33237/tete.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20036>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:16:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Dec 2013 18:16:05 +0000
Subject: [issue20036] Running same doctests not possible on both py3 and py2
In-Reply-To: <1387563061.69.0.696193662364.issue20036@psf.upfronthosting.co.za>
Message-ID: <1387563365.44.0.101401353648.issue20036@psf.upfronthosting.co.za>


R. David Murray added the comment:

This has already been addressed in issue 7490.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IGNORE_EXCEPTION_DETAIL should ignore the module name

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20036>
_______________________________________

From report at bugs.python.org  Fri Dec 20 19:17:47 2013
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Fri, 20 Dec 2013 18:17:47 +0000
Subject: [issue20036] Running same doctests not possible on both py3 and py2
In-Reply-To: <1387563061.69.0.696193662364.issue20036@psf.upfronthosting.co.za>
Message-ID: <1387563467.91.0.873393846601.issue20036@psf.upfronthosting.co.za>


Maries Ionel Cristian added the comment:

Oooops, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20036>
_______________________________________

From report at bugs.python.org  Fri Dec 20 20:09:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Dec 2013 19:09:31 +0000
Subject: [issue20036] Running same doctests not possible on both py3 and py2
In-Reply-To: <1387563061.69.0.696193662364.issue20036@psf.upfronthosting.co.za>
Message-ID: <1387566571.2.0.186815892302.issue20036@psf.upfronthosting.co.za>


R. David Murray added the comment:

No problem.  It's not necessarily *obvious* what one needs to do to make this work, so missing it isn't too surprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20036>
_______________________________________

From report at bugs.python.org  Fri Dec 20 21:35:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Dec 2013 20:35:36 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1387571736.87.0.0499771802152.issue19717@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, given the diversity of possible behaviours, it starts to seem like it should maybe be discussed on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Fri Dec 20 22:38:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Dec 2013 21:38:04 +0000
Subject: [issue20029] asyncio.SubprocessProtocol is missing
In-Reply-To: <1387521454.41.0.193901809521.issue20029@psf.upfronthosting.co.za>
Message-ID: <1387575484.67.0.7572622.issue20029@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gvanrossum, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20029>
_______________________________________

From report at bugs.python.org  Fri Dec 20 22:47:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Dec 2013 21:47:02 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387576022.04.0.411244859696.issue20032@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

+            self._loop.call_soon(traceback.clear_frames,
+                                 self._exception.__traceback__)

This will keep the traceback alive until called by the event loop, even if self._exception is cleared in the meantime...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:13:33 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 22:13:33 +0000
Subject: [issue20029] asyncio.SubprocessProtocol is missing
In-Reply-To: <1387521454.41.0.193901809521.issue20029@psf.upfronthosting.co.za>
Message-ID: <1387577613.28.0.256546254395.issue20029@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I propose that we fix the code.  There are also some documented Transport classes that aren't listed in __all__.

I'll submit the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20029>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:15:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 22:15:01 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387577701.69.0.296311867455.issue20032@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Do you have an example of code that behaves differently with this patch?  I can't find any.

I didn't check in the Python standard library, but the reference cycle is obvious, and I hate such issue. It introduces tricky issues like memory leaks.

Here is an example to demonstrate the issue. The "DELETE OBJECT" message is never displayed, so the object is never deleted (memory leak).

Comment "fut.set_exception(err)" line to delete the object, or apply attached patch.

----------
Added file: http://bugs.python.org/file33238/never_deleted.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:17:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Dec 2013 22:17:35 +0000
Subject: [issue20029] asyncio.SubprocessProtocol is missing
In-Reply-To: <1387521454.41.0.193901809521.issue20029@psf.upfronthosting.co.za>
Message-ID: <3dmPTV34bdzRwm@mail.python.org>


Roundup Robot added the comment:

New changeset 0a135e790ce5 by Guido van Rossum in branch 'default':
asyncio: Export all abstract protocol and transport classes. Fixes issue #20029.
http://hg.python.org/cpython/rev/0a135e790ce5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20029>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:19:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 22:19:07 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
Message-ID: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached crash.py script does crash Python.

Python traceback on the crash:

(gdb) py-bt
Traceback (most recent call first):
  File "/home/haypo/prog/python/default/Lib/tokenize.py", line 431, in open
    text = TextIOWrapper(buffer, encoding, line_buffering=True)
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 126, in updatecache
    with tokenize.open(fullname) as fp:
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 41, in getlines
    return updatecache(filename, module_globals)
  File "/home/haypo/prog/python/default/Lib/linecache.py", line 15, in getline
    lines = getlines(filename, module_globals)
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
    line = linecache.getline(filename, lineno, f.f_globals)
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 18, in _format_list_iter
    for filename, lineno, name, line in extracted_list:
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 153, in _format_exception_iter
    yield from _format_list_iter(_extract_tb_iter(tb, limit=limit))
  File "/home/haypo/prog/python/default/Lib/traceback.py", line 181, in format_exception
    return list(_format_exception_iter(etype, value, tb, limit, chain))
  File "/home/haypo/prog/python/default/Lib/asyncio/futures.py", line 178, in __del__
    exc.__traceback__)
  Garbage-collecting

End of the C traceback:

#46 0x00000000005aa742 in PyEval_CallObjectWithKeywords (func=<method at remote 0x7ffff19e79f8>, arg=(), kw=0x0) at Python/ceval.c:4107
#47 0x00000000004ee268 in slot_tp_finalize (
    self=<Future(_state='FINISHED', _exception=ValueError(), _loop=<_UnixSelectorEventLoop(_selector=<EpollSelector(_epoll=<select.epoll at remote 0x7ffff0dd3a18>, _fd_to_key={9: <SelectorKey at remote 0x7fffeefaa0e0>}, _map=<_SelectorMapping(_selector=<...>) at remote 0x7ffff18eae90>) at remote 0x7ffff18ea1f8>, _running=False, _signal_handlers={}, _default_executor=None, _ssock=<socket at remote 0x7fffef7e6e68>, _internal_fds=1, _scheduled=[], _ready=<collecti---Type <return> to continue, or q <return> to quit---
ons.deque at remote 0x7ffff18c56e0>, _csock=<socket at remote 0x7fffeefb5958>) at remote 0x7ffff18ea190>, _log_traceback=True, _callbacks=[]) at remote 0x7ffff18ea0c0>) at Objects/typeobject.c:5954
#48 0x000000000043b530 in finalize_garbage (collectable=0x7fffffffdc90, old=0x8eea20 <generations+64>) at Modules/gcmodule.c:793
#49 0x000000000043bce5 in collect (generation=2, n_collected=0x0, n_uncollectable=0x0, nofail=1) at Modules/gcmodule.c:1009
#50 0x000000000043cff4 in _PyGC_CollectNoFail () at Modules/gcmodule.c:1625
#51 0x00000000005cd873 in PyImport_Cleanup () at Python/import.c:383
#52 0x000000000041e898 in Py_Finalize () at Python/pythonrun.c:622
#53 0x000000000043a65c in Py_Main (argc=2, argv=0x970020) at Modules/main.c:800
#54 0x000000000041aad9 in main (argc=2, argv=0x7fffffffe0b8) at ./Modules/python.c:69

----------
files: crash.py
messages: 206707
nosy: haypo
priority: normal
severity: normal
status: open
title: Calling traceback.format_exception() during Pyhon shutdown does crash Python
versions: Python 3.4
Added file: http://bugs.python.org/file33239/crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:22:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 22:22:02 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387578122.76.0.242110484608.issue20037@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Begin of the C traceback:

#0  0x00000000004bf70a in PyModule_GetState (m=0x0) at Objects/moduleobject.c:292
#1  0x00000000006373b6 in textiowrapper_init (self=0x7ffff1073790, args=(<_io.BufferedReader at remote 0x7fffefa094b8>, 'utf-8'), 
    kwds={'line_buffering': True}) at ./Modules/_io/textio.c:855
#2  0x00000000004daf26 in type_call (type=0x94d700 <PyTextIOWrapper_Type>, args=(<_io.BufferedReader at remote 0x7fffefa094b8>, 'utf-8'), 
    kwds={'line_buffering': True}) at Objects/typeobject.c:759

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:23:30 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 22:23:30 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387577701.69.0.296311867455.issue20032@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLJHCGpxq1VPExyhUAmvg2bHb4AbzYGrXtrdQ1ZiRgikA@mail.gmail.com>


Guido van Rossum added the comment:

The cycle will be cleaned up (and the message printed) when the
garbage collector runs next. Your demo doesn't do anything else, so it
never allocates memory, so it never runs gc.collect(). But that's only
because it's a toy program.

Maybe it's time to look into
http://code.google.com/p/tulip/issues/detail?id=42 ? (It proposes to
run gc.collect() occasionally when the loop is idle.)

I am also concerned about Antoine's point -- the patch may actually
*prolong* the life of the traceback.

On Fri, Dec 20, 2013 at 2:15 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor added the comment:
>
>> Do you have an example of code that behaves differently with this patch?  I can't find any.
>
> I didn't check in the Python standard library, but the reference cycle is obvious, and I hate such issue. It introduces tricky issues like memory leaks.
>
> Here is an example to demonstrate the issue. The "DELETE OBJECT" message is never displayed, so the object is never deleted (memory leak).
>
> Comment "fut.set_exception(err)" line to delete the object, or apply attached patch.
>
> ----------
> Added file: http://bugs.python.org/file33238/never_deleted.py
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20032>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:24:48 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 22:24:48 +0000
Subject: [issue20029] asyncio.SubprocessProtocol is missing
In-Reply-To: <1387521454.41.0.193901809521.issue20029@psf.upfronthosting.co.za>
Message-ID: <1387578288.78.0.555301685402.issue20029@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

There's one issue left: the docs need to document BaseProtocol.

----------
assignee:  -> haypo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20029>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:27:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Dec 2013 22:27:53 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <CAP7+vJLJHCGpxq1VPExyhUAmvg2bHb4AbzYGrXtrdQ1ZiRgikA@mail.gmail.com>
Message-ID: <1387578471.3474.1.camel@fsol>


Antoine Pitrou added the comment:

> Maybe it's time to look into
> http://code.google.com/p/tulip/issues/detail?id=42 ? (It proposes to
> run gc.collect() occasionally when the loop is idle.)

Is it possible to break the cycle instead? Or is the graph of references
too complex for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:35:49 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 22:35:49 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387578949.04.0.939264084159.issue20032@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The only reasonable place to break the cycle seems to be the frame containing the set_exception() call -- but that could be app code.

Looking again at what the patch actually does I think it is too big a hammer anyway -- it would break debugging tools that preserve tracebacks and inspect the frames later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:37:14 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 22:37:14 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387579034.42.0.639565765322.issue20032@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"The cycle will be cleaned up (and the message printed) when the
garbage collector runs next."

Oh, ok. Using the following task, the object is correctly deleted.
---
@asyncio.coroutine
def idle():
    while 1:
        gc.collect()
        yield from asyncio.sleep(0.1)

asyncio.Task(idle())
---

"Maybe it's time to look into
http://code.google.com/p/tulip/issues/detail?id=42 ? (It proposes to
run gc.collect() occasionally when the loop is idle.)"

I don't like such task. The issue can be documented, maybe with an example of call calling gc.collect() regulary? Such background task should be implemented in the application to control when the garbage collector is called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:37:23 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 22:37:23 +0000
Subject: [issue20032] asyncio.Future.set_exception() creates a reference cycle
In-Reply-To: <1387533303.95.0.0629214738994.issue20032@psf.upfronthosting.co.za>
Message-ID: <1387579043.18.0.535720645883.issue20032@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20032>
_______________________________________

From report at bugs.python.org  Fri Dec 20 23:41:08 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 20 Dec 2013 22:41:08 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387579268.15.0.564831333124.issue19967@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Victor, can you commit the fix (with my suggested improvement)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:17:44 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2013 23:17:44 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387581464.43.0.10801666912.issue19995@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It seems to me that anything that is an 'integer' that can be turned into an int without loss of information (has .__index__) is logically a 'number' that can be turned into an int possibly with loss of information (has .__int__).  So perhaps one of the following should be true:

1. The doc for .__index__ specifies that def __index__ 'must' be followed by __int__ = __index__ to make a coherent class. (So Ethan's Grade as written above would not qualify.)

2. The type constructor does this for us by adding __int__ as an alias for __index__ when the latter is present.

3. Every core usage of __int__ looks for __index__ also. Int() does not do this now, but '%d' does, so int(Grade.F) fails but int('%d' % Grade.f) works.

The exact details would depend on whether we want to allow (or at least bless) classes with __int__ and __index__ returning different ints.

The docs for bin/oct/hex(x) are clear. "Convert an integer number to a binary/octal/hexadecimal string. The result is a valid Python expression. If x is not a Python int object, it has to define an __index__() method that returns an integer." This should not change.

If the domain of %x is going to be a subset of of the domain of %d, it seems to me that the exclusion should be of non-integers (such as floats) rather than of non-int integers. Given things as they are, I would simply expand the domain of %x, etc, to that of %d without bothering to go through a deprecation process.

----------
nosy: +terry.reedy
stage:  -> test needed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:20:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Dec 2013 23:20:41 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <3dmQtJ2dSfz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 06ed1691efdc by Victor Stinner in branch 'default':
Issue #19967: Defer the formating of the traceback in asyncio.Future destructor
http://hg.python.org/cpython/rev/06ed1691efdc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:21:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Dec 2013 23:21:32 +0000
Subject: [issue19967] asyncio: remove _TracebackLogger
In-Reply-To: <1386889369.33.0.285516490097.issue19967@psf.upfronthosting.co.za>
Message-ID: <1387581692.01.0.547556594931.issue19967@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19967>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:28:20 2013
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 20 Dec 2013 23:28:20 +0000
Subject: [issue1100942] Add datetime.time.strptime and datetime.date.strptime
Message-ID: <1387582099.96.0.468562291661.issue1100942@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

I'm attaching merged and fixed patch (issue1100942_full.patch). Though during testing I found one issue with the patch: during checking for time part in date class I'm using (in _datetimemodule.c->date_strptime) DATE_GET_HOUR etc, but when given time parts are 0's then the test fails. Should I leave the patch as is, because possibility for 0's is very low or should I check the format string for time parts existence? Any further advice is appreciated.

----------
Added file: http://bugs.python.org/file33240/issue1100942_full.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1100942>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:28:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2013 23:28:46 +0000
Subject: [issue19998] Python 2.7.6 fails to build _ctypes on GCC 2.x toolchain
In-Reply-To: <1387200881.03.0.963168965941.issue19998@psf.upfronthosting.co.za>
Message-ID: <1387582126.24.0.459323464065.issue19998@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe an upstream change will be automatically picked up by any subsequent CPython release without an explicit tracker patch.

----------
nosy: +terry.reedy
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19998>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:33:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2013 23:33:54 +0000
Subject: [issue20003] Language Ref "raise" doc misssing "from None"
In-Reply-To: <1387252072.89.0.572943909834.issue20003@psf.upfronthosting.co.za>
Message-ID: <1387582434.6.0.974703131482.issue20003@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Document 'from None' in raise statement doc.
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20003>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:39:23 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2013 23:39:23 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387582763.51.0.347791377438.issue20014@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Sat Dec 21 00:55:56 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Dec 2013 23:55:56 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za>
Message-ID: <1387583756.55.0.33175444829.issue20015@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Victor and Stefan are correct. 2.7 is a fixed version of Python. CPython 2.7.z, z >= 1, only gets bug (and build) fixes. A 'new 2.7 version' would be 2.8, which will not happen. The fact that you propose to change the unambiguous doc shows that this is an enhancement, not a bugfix. This change would have had to be done in 2.7.0.

----------
nosy: +terry.reedy
resolution:  -> invalid
stage: patch review -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Sat Dec 21 01:12:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Dec 2013 00:12:18 +0000
Subject: [issue20014] Makes array.array constructor accepts ascii-unicode
 typecode
In-Reply-To: <1387360195.98.0.786950742842.issue20014@psf.upfronthosting.co.za>
Message-ID: <1387584738.62.0.442990497213.issue20014@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This enhancement request would have been nice in 2.7.0 but it is too late for bugfix releases. Typecodes have always been shown as instances of str and still are. The doc no where suggests that unicode chars should work in 2.7 and it is not a bug that they do not.

----------
nosy: +terry.reedy
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20014>
_______________________________________

From report at bugs.python.org  Sat Dec 21 02:35:33 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 21 Dec 2013 01:35:33 +0000
Subject: [issue20038] Crash due to I/O in __del__
Message-ID: <1387589732.66.0.870061019982.issue20038@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I was writing a new Tulip example (a cache client and server, not yet public) and I noticed that when I interrupted the client with ^C I got a traceback (expected) followed by a segfault (unexpected).  This is on OSX 10.8 but I don't think it is platform dependent.

A little experiment showed that this only happened with Python 3.4 and only with the latest Tulip, where Future has a __del__ method.  

According to gdb, the segfault happens on the first line of PyModule_GetState(), because the argument 'm' is NULL.

Putting a NULL check in this function averts the segfault but give the following disturbing extra traceback:

--- Logging error ---
Traceback (most recent call last):
Exception ignored in: <bound method Task.__del__ of Task(<testing>)<exception=KeyboardInterrupt()>>
Traceback (most recent call last):
  File "/Users/guido/tulip/asyncio/futures.py", line 177, in __del__
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1278, in error
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1384, in _log
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1394, in handle
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 1456, in callHandlers
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 835, in handle
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 959, in emit
  File "/Users/guido/cpython/Lib/logging/__init__.py", line 888, in handleError
  File "/Users/guido/cpython/Lib/traceback.py", line 169, in print_exception
  File "/Users/guido/cpython/Lib/traceback.py", line 153, in _format_exception_iter
  File "/Users/guido/cpython/Lib/traceback.py", line 18, in _format_list_iter
  File "/Users/guido/cpython/Lib/traceback.py", line 65, in _extract_tb_or_stack_iter
  File "/Users/guido/cpython/Lib/linecache.py", line 15, in getline
  File "/Users/guido/cpython/Lib/linecache.py", line 41, in getlines
  File "/Users/guido/cpython/Lib/linecache.py", line 126, in updatecache
  File "/Users/guido/cpython/Lib/tokenize.py", line 431, in open
TypeError: bad argument type for built-in operation

This suggests the problem is triggered by some I/O due to the exception logging in the __del__ method.

The gdb traceback (too big to post here) tells me that this PyModule_GetState() call is in the IO_STATE macro in textiowrapper_init().  The whole thing seems to be in a GC run called from Py_Finalize().  Check out the attached @bt.txt.

Any ideas?  (The TypeError is simply what PyModule_GetState() returns for a non-module argument -- I made it take the same exit path for NULL.)

----------
files: @bt.txt
messages: 206721
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: Crash due to I/O in __del__
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file33241/@bt.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20038>
_______________________________________

From report at bugs.python.org  Sat Dec 21 08:30:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 07:30:06 +0000
Subject: [issue13566] Array objects pickled in 3.x with protocol <=2 are
 unpickled incorrectly in 2.x
In-Reply-To: <1323437104.23.0.789258355405.issue13566@psf.upfronthosting.co.za>
Message-ID: <1387611006.76.0.553632139619.issue13566@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13566>
_______________________________________

From report at bugs.python.org  Sat Dec 21 11:35:14 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Dec 2013 10:35:14 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
In-Reply-To: <1387583756.55.0.33175444829.issue20015@psf.upfronthosting.co.za>
Message-ID: <20131221103512.GA2071@sleipnir.bytereef.org>


Stefan Krah added the comment:

Well, generally I'd be against adding features, but this particular one
could be rationalized in the same way as PEP 414.  So I'm simply unsure
whether the feature should be added, but *if* it's added, it should
be backed by a pronouncement either from the RM or Guido.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Sat Dec 21 11:40:25 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Sat, 21 Dec 2013 10:40:25 +0000
Subject: [issue20039] Missing documentation for argparse.ArgumentTypeError
Message-ID: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>


New submission from Arnaut Billings:

There is no documentation for argparse.ArgumentTypeError:

http://docs.python.org/3/library/unittest.html

Though it does appear in an example and its usage is simple enough to decipher what it means, it would none the less look more professional if there was formal documentation for it. Not only on what it is, but when it should actually be used, etc...

----------
assignee: docs at python
components: Documentation
messages: 206723
nosy: arnaut-billings, docs at python
priority: normal
severity: normal
status: open
title: Missing documentation for argparse.ArgumentTypeError
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20039>
_______________________________________

From report at bugs.python.org  Sat Dec 21 12:04:52 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 11:04:52 +0000
Subject: [issue20038] Crash due to I/O in __del__
In-Reply-To: <1387589732.66.0.870061019982.issue20038@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZaQDUNwOnKfsK6oNizTRT-FYpXGqyfDH=5VBxBZkaoTw@mail.gmail.com>


STINNER Victor added the comment:

>
> This issue is a duplicate of issue #20037.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20038>
_______________________________________

From report at bugs.python.org  Sat Dec 21 12:07:55 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Dec 2013 11:07:55 +0000
Subject: [issue20015] Allow 1-character ASCII unicode where 1-character str is
 required
In-Reply-To: <1387382366.37.0.964927896158.issue20015@psf.upfronthosting.co.za>
Message-ID: <1387624075.02.0.926897995675.issue20015@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

PEP414 was about adding a feature to 3.3 well before the first alpha release. 

What Guido has recently said about 2.7 is that after 3 1/2 years we should concentrate on build issues such as came up with the new OSX and de-emphasize or even cease fixing bugs. He thinks that by now, people will have worked around the ones that matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20015>
_______________________________________

From report at bugs.python.org  Sat Dec 21 12:22:16 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Dec 2013 11:22:16 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387624936.12.0.7279923134.issue20037@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 12:57:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 11:57:55 +0000
Subject: [issue20038] Crash due to I/O in __del__
In-Reply-To: <1387589732.66.0.870061019982.issue20038@psf.upfronthosting.co.za>
Message-ID: <1387627075.87.0.152243203972.issue20038@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Calling traceback.format_exception() during Pyhon shutdown does crash Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20038>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:01:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 12:01:25 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387627285.8.0.967800000723.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, the current idiom for calling PyModule_GetState in extension modules isn't safe (because it assumes nothing ever errors out, which can be wrong in the shutdown phase).

----------
nosy: +gvanrossum, ncoghlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:04:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 12:04:45 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387627485.72.0.921829258906.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Speaking of which, Victor, your script works here:

$ ./python futcrash.py 
Future/Task exception was never retrieved:
Traceback (most recent call last):
  File "futcrash.py", line 4, in <module>
    raise ValueError()
ValueError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:05:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 12:05:25 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387627525.92.0.168873278873.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, that was before the latest changes. Scratch that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:13:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 12:13:33 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387628013.16.0.0595611724707.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

See issue18710 for an API proposal which may help in some cases.

Also, see https://mail.python.org/pipermail/python-dev/2013-August/127862.html for an involved discussion of issues with the current "module state" scheme.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 13:19:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 12:19:53 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387628393.03.0.667977483615.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note that the module state is only used when no explicit encoding is given to TextIOWrapper(), so the following patch fixes this particular issue:

$ hg di
diff --git a/Modules/_io/textio.c b/Modules/_io/textio.c
--- a/Modules/_io/textio.c
+++ b/Modules/_io/textio.c
@@ -852,7 +852,7 @@ textiowrapper_init(textio *self, PyObjec
     char *errors = NULL;
     char *newline = NULL;
     int line_buffering = 0, write_through = 0;
-    _PyIO_State *state = IO_STATE;
+    _PyIO_State *state = NULL;
 
     PyObject *res;
     int r;
@@ -891,6 +891,7 @@ textiowrapper_init(textio *self, PyObjec
     if (encoding == NULL) {
         /* Try os.device_encoding(fileno) */
         PyObject *fileno;
+        state = IO_STATE;
         fileno = _PyObject_CallMethodId(buffer, &PyId_fileno, NULL);
         /* Ignore only AttributeError and UnsupportedOperation */
         if (fileno == NULL) {


However, since doing I/O at shutdown is not a particularly uncommon operation, we should still fix the general case to at least raise a proper exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:19:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 13:19:13 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387631953.81.0.736866403128.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch with tests.

----------
keywords: +patch
stage:  -> patch review
type:  -> crash
Added file: http://bugs.python.org/file33242/iostate_shutdown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:51:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 13:51:01 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387633861.38.0.0798516718222.issue20037@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I think that #19421 was also a duplicate of this issue. Updated example from this issue: attached script crash_logging_exc_info.py.

Output:
---
$ ./python crash_logging_exc_info.py
Erreur de segmentation (core dumped)
---

Output with iostate_shutdown.patch applied:
---
$ ./python ~/crash_logging_exc_info.py 
CRITICAL:root:error
Traceback (most recent call last):
  File "/home/haypo/crash_logging_exc_info.py", line 7, in __del__
    raise ValueError()
ValueError
---

@Antoine: You should also add a test based on crash_logging_exc_info.py in test_logging, to test the whole feature (display a traceback during Python shutdown).

----------
Added file: http://bugs.python.org/file33243/crash_logging_exc_info.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:52:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 13:52:10 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387633930.54.0.685095491227.issue20037@psf.upfronthosting.co.za>


STINNER Victor added the comment:

iostate_shutdown.patch: "_PyIO_State *state = IO_STATE;" looks weird to me. The macro should be take parenthesis: "_PyIO_State *state = IO_STATE();". When I read IO_STATE, it looks like a global variable, whereas it does call a real function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 14:55:53 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 13:55:53 +0000
Subject: [issue20040] Tracing not disabled in generator when the system trace
 function returns None.
Message-ID: <1387634153.88.0.744375474198.issue20040@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The sys.settrace documentation states:
  The trace function is invoked (with event set to 'call') whenever a new local scope is entered;
  it should return a reference to a local trace function to be used that scope, or None if the scope shouldn?t be traced.

But when tracing a generator, 'line' events may be traced even though tracing has been disabled by
returning None at the 'call' event. Run the attached tracer.py with 0 as argument and see that
tracing does not stop as it should when count is 1:
$ python tracer.py 0
call gen with count 0
line
line
return
call gen with count 1
returning None: the scope shouldn?t be traced
line
return

However, when tracer.py is run with 1 as argument, tracing is (correctly) disabled when count is 1
and 2. This problem is closely related to issue 11992.
The dispatch_call() method of Bdb in the bdb module is broken when the frame is a generator and the
previous command is next, until or return (and when this problem is fixed).

----------
components: Interpreter Core
files: tracer.py
messages: 206734
nosy: xdegaye
priority: normal
severity: normal
status: open
title: Tracing not disabled in generator when the system trace function returns None.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33244/tracer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20040>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:00:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 14:00:36 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387634436.34.0.705455968348.issue19861@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:01:27 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 14:01:27 +0000
Subject: [issue20041] TypeError when f_trace is None and tracing.
Message-ID: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Section 3.2 of 'The Python Language Reference' states:
  f_trace, if not None, is a function called at the start of each source code line

Run the attached tracer.py and see that although f_trace is None in both cases when 'cmd' is either
'delete' or 'set', the second case raises a TypeError exception:
$ python tracer.py
f_trace: None
delete start
delete done
f_trace: None
set start
Traceback (most recent call last):
  File "tracer.py", line 19, in <module>
    foo('set')
  File "tracer.py", line 15, in foo
    print(cmd, 'done')
  File "tracer.py", line 15, in foo
    print(cmd, 'done')
TypeError: 'NoneType' object is not callable

Also, the frame.f_lineno may be wrong in a traceback when f_trace is set to None because
PyFrame_GetLineNumber() does not handle this case.

The attached patch fixes this issue.
The patch also fixes issue 11992 and issue 20040.
The patch also fixes the dispatch_call() method of Bdb in the bdb module when the frame is a
generator and the previous command is next, until or return.
The patch also provides a backward compatible solution to the performance enhancement described in
issue 16672.

----------
components: Interpreter Core
files: tracer.py
messages: 206735
nosy: xdegaye
priority: normal
severity: normal
status: open
title: TypeError when f_trace is None and tracing.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33245/tracer.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20041>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:01:44 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 14:01:44 +0000
Subject: [issue20041] TypeError when f_trace is None and tracing.
In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>
Message-ID: <1387634504.52.0.369731092466.issue20041@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file33246/f_trace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20041>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:05:20 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 14:05:20 +0000
Subject: [issue16672] improve tracing performances when f_trace is NULL
In-Reply-To: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za>
Message-ID: <1387634720.96.0.18213814603.issue16672@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

A patch proposed in issue 20041 provides a backward compatible solution to this performance enhancement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16672>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:05:30 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Dec 2013 14:05:30 +0000
Subject: [issue19463] assertGdbRepr depends on hash randomization / endianess
In-Reply-To: <1383245602.59.0.0634998131847.issue19463@psf.upfronthosting.co.za>
Message-ID: <1387634730.66.0.47128513808.issue19463@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Also on System Z:

http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1009/steps/test/logs/stdio

Setting priority to "normal", since it's the only test failing on
System Z and generally green buildbots are more useful.

----------
keywords: +buildbot
nosy: +dmalcolm, skrah
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19463>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:06:19 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 14:06:19 +0000
Subject: [issue20040] Tracing not disabled in generator when the system trace
 function returns None.
In-Reply-To: <1387634153.88.0.744375474198.issue20040@psf.upfronthosting.co.za>
Message-ID: <1387634779.69.0.369538040201.issue20040@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

A patch is proposed in issue 20041.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20040>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:07:05 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 Dec 2013 14:07:05 +0000
Subject: [issue11992] sys.settrace doesn't disable tracing if a local trace
 function returns None
In-Reply-To: <1304474333.76.0.969797512596.issue11992@psf.upfronthosting.co.za>
Message-ID: <1387634825.78.0.857884635647.issue11992@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

See also issue 20040.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11992>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:08:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:08:38 +0000
Subject: [issue19463] assertGdbRepr depends on hash randomization / endianess
In-Reply-To: <1383245602.59.0.0634998131847.issue19463@psf.upfronthosting.co.za>
Message-ID: <1387634918.73.0.654475938553.issue19463@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I didn't notice this issue. I created the duplicate #19753 and I did some changes to try to fix it.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19463>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:10:03 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 14:10:03 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
Message-ID: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>


New submission from Konstantin Zemlyak:

Running `py.exe ??????.py` in cmd window fails:

E:\>set PYLAUNCH_DEBUG=1

E:\>py ??????.py
launcher build: 32bit
launcher executable: Console
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
Using global configuration file 'C:\Windows\py.ini'
Called with command line: .pymaybe_handle_shebang: read 211 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 64bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files\Python27\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python32\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python33\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files (x86)\Python27\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python32\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python33\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
found configured value 'python3=3.2-32' in environment
search for Python version '3.2-32' found '"C:\Program Files (x86)\Python32\python.exe"'
run_child: about to run '"C:\Program Files (x86)\Python32\python.exe" .py'
C:\Program Files (x86)\Python32\python.exe: can't open file '.py': [Errno 2] No such file or directory
child process exit code: 2


Note "Called with command line: .py" in output shows that filename was mangled very early on. Invoking `??????.py` (which is associated with py.exe) directly works fine though.

The problem lies in Windows handling of command-line arguments and fix to this is simple but non-obvious. Patch attached.

----------
components: Unicode, Windows
files: pylauncher-fix-launcing-unicode-filenames.patch
keywords: patch
messages: 206741
nosy: ezio.melotti, haypo, zart
priority: normal
severity: normal
status: open
title: Python Launcher for Windows fails to invoke scripts with non-latin names
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file33247/pylauncher-fix-launcing-unicode-filenames.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:10:21 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:10:21 +0000
Subject: [issue19463] assertGdbRepr depends on hash randomization / endianess
In-Reply-To: <1383245602.59.0.0634998131847.issue19463@psf.upfronthosting.co.za>
Message-ID: <1387635021.5.0.264793223192.issue19463@psf.upfronthosting.co.za>


STINNER Victor added the comment:

When trying to workaround a bug in the implementation of the PEP 456 (which was not known as a bug at this time), I implemented something using subprocessing which may be reused on SystemZ (or maybe on all platforms):

changeset:   87290:11cb1c8faf11
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Wed Nov 20 12:27:48 2013 +0100
files:       Lib/test/test_gdb.py
description:
Issue #19183: Fix repr() tests of test_gdb, hash() is now platform dependent

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19463>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:13:37 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 14:13:37 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387635217.5.0.172185238447.issue20042@psf.upfronthosting.co.za>


Konstantin Zemlyak added the comment:

Sorry, fixed whitespaces in the patch.

----------
Added file: http://bugs.python.org/file33248/pylauncher-fix-launcing-unicode-filenames.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:14:03 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 14:14:03 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387635243.25.0.230617916823.issue20042@psf.upfronthosting.co.za>


Changes by Konstantin Zemlyak <zart at zartsoft.ru>:


Removed file: http://bugs.python.org/file33247/pylauncher-fix-launcing-unicode-filenames.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:19:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:19:50 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387635590.4.0.491137205113.issue20042@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like the wide character strings (wchar_t*) are misused. For example:

error(RC_NO_PYTHON, L"Requested Python version (%s) ...", &p[1]);
fwprintf(stdout, L"usage: %s ...\n\n", argv[0]);

The %s formatter is for byte string (char*), "%ls" should be used instead.

+	_setmode(_fileno(stdout), _O_WTEXT);

Extract of wprintf() documentation:

"The wprintf() and vwprintf() functions perform wide-character output to stdout.  stdout must not be byte oriented;  see  fwide(3)  for more information."

So _setmode() or fwide() should be used if I understood correctly. Or wprintf() should be replaced with printf() (still with "%ls" format)?

wprintf("%ls") replaces unencodable character string arguments by ? (U+003F), whereas printf("%ls") and wprintf("%s") truncates the output at the first undecodable/unencodable character:
http://unicodebook.readthedocs.org/en/latest/programming_languages.html#printf-functions-family

So wprintf() is probably better here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:20:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:20:22 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387635622.19.0.310313146131.issue20042@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +brian.curtin, loewis, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:21:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:21:22 +0000
Subject: [issue20040] Tracing not disabled in generator when the system trace
 function returns None.
In-Reply-To: <1387634153.88.0.744375474198.issue20040@psf.upfronthosting.co.za>
Message-ID: <1387635682.44.0.730580031043.issue20040@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20040>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:21:32 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:21:32 +0000
Subject: [issue20040] Tracing not disabled in generator when the system trace
 function returns None.
In-Reply-To: <1387634153.88.0.744375474198.issue20040@psf.upfronthosting.co.za>
Message-ID: <1387635692.51.0.923793240543.issue20040@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20040>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:22:53 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 14:22:53 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387635773.4.0.968162150132.issue20042@psf.upfronthosting.co.za>


Konstantin Zemlyak added the comment:

I don't care much about debug output though it probably should be fixed.

The point is that changing text mode of stdout has a weird side effect of fixing command-line arguments when invoking interactively from cmd.exe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:25:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:25:00 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387635900.1.0.783670963825.issue19861@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is a command to generate a list a list versionchanged, but I don't remember it.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:28:28 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:28:28 +0000
Subject: [issue19380] Optimize parsing of regular expressions
In-Reply-To: <1382645659.73.0.868235602026.issue19380@psf.upfronthosting.co.za>
Message-ID: <1387636108.39.0.281672156968.issue19380@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/issue19380>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:28:45 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 21 Dec 2013 14:28:45 +0000
Subject: [issue20043] test_multiprocessing_main_handling fails
 --without-threads
Message-ID: <1387636125.31.0.836708895935.issue20043@psf.upfronthosting.co.za>


New submission from Stefan Krah:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5874/steps/test/logs/stdio


test test_multiprocessing_main_handling crashed -- Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/importlib/__init__.py", line 129, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2172, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2155, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2144, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1209, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1133, in _exec
  File "<frozen importlib._bootstrap>", line 1436, in exec_module
  File "<frozen importlib._bootstrap>", line 321, in _call_with_frames_removed
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_multiprocessing_main_handling.py", line 19, in <module>
    import multiprocessing
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/multiprocessing/__init__.py", line 16, in <module>
    from . import context
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/multiprocessing/context.py", line 3, in <module>
    import threading
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/threading.py", line 4, in <module>
    import _thread
ImportError: No module named '_thread'

----------
components: 2to3 (2.x to 3.x conversion tool)
keywords: buildbot
messages: 206747
nosy: skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing_main_handling fails --without-threads
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20043>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:45:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:45:04 +0000
Subject: [issue14228] It is impossible to catch sigint on startup in python
 code
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387637104.61.0.19761487469.issue14228@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, but I don't understand this issue. Well, I understood the issue as "When I press CTRL+c to interrupt Python, Python does exit". What's wrong with that? Why do you send CTRL+c if you don't want Python to exit?

Using custom signal handler (SIG_IGN), it would be possible to ignore SIGINT during Python initialization. Using pthread_sigmask(), it is possible to defer the handling of the signal until user is able to setup its own custom signal handler (or just use try/except KeyboardInterrupt). But I don't like these options. I would like to be able to kill (stop) Python as early as possible with CTRL+c.

If you are only worried by the long traceback when importing the site module is interrupted, you can use -S. On UNIX, you can then use signal.pthread_sigmask() to defer the handling of SIGINT.

The whole issue remembers me the dummy question: "is the finally block executed even if I unplug the power cable?".

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926

This issue can be solved using python -S, calling signal.signal(SIGINT, signal.SIG_DFL) and then import the site module manually.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:52:35 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Dec 2013 14:52:35 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <3dmqYZ52gnz7LkH@mail.python.org>


Roundup Robot added the comment:

New changeset 9158f201f6d0 by Antoine Pitrou in branch 'default':
Issue #20037: Avoid crashes when doing text I/O late at interpreter shutdown.
http://hg.python.org/cpython/rev/9158f201f6d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:53:26 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 14:53:26 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387637606.92.0.084646703298.issue20037@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Applied Victor's comments and committed the fix.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:54:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 14:54:57 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387637697.88.0.684709213675.issue20037@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Applied Victor's comments

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 15:59:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 14:59:48 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387637988.0.0.740239626189.issue20042@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:20:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Dec 2013 15:20:16 +0000
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1349389263.57.0.925729224322.issue16136@psf.upfronthosting.co.za>
Message-ID: <3dmr9W2khmz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 568391b3eda9 by Christian Heimes in branch 'default':
Issue #16136: Remove VMS support and VMS-related code
http://hg.python.org/cpython/rev/568391b3eda9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16136>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:21:19 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Dec 2013 15:21:19 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1387639279.47.0.842475458349.issue19766@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Donald updated CPython to pip 1.5rc2, so test_venv is now passing without threading support:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5874/steps/test/logs/stdio

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:21:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Dec 2013 15:21:29 +0000
Subject: [issue19766] test_venv: test_with_pip() failed on "AMD64 Fedora
 without threads 3.x" buildbot: urllib3 dependency requires the
 threading module
In-Reply-To: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>
Message-ID: <1387639289.72.0.398872610477.issue19766@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19766>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:31:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Dec 2013 15:31:02 +0000
Subject: [issue19744] test_venv fails if SSL/TLS is not available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <1387639862.0.0.496212828709.issue19744@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

OK, since pip 1.5 will still have the SSL/TLS dependency, the approach I'll go with for 3.4 is to:

1. Have ensurepip refuse to bootstrap pip if the ssl module is not available (noting that we'll remove that restriction if pip 1.6 avoids the strict dependency)
2. Use import_fresh_module to check that behaviour
3. Ensure venv skips trying to bootstrap pip if the ssl module is not available (although the subprocess invocation in the venv tests could make that tricky to test when the ssl module actually *is* available)

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19744>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:31:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 21 Dec 2013 15:31:31 +0000
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1349389263.57.0.925729224322.issue16136@psf.upfronthosting.co.za>
Message-ID: <1387639891.42.0.281184789192.issue16136@psf.upfronthosting.co.za>


Christian Heimes added the comment:

All VMS code has been removed except for some code in Lib/platform.py.

MAL:
Do you want to keep the code in the platform module?

----------
assignee:  -> lemburg
nosy: +lemburg
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16136>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:31:46 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Dec 2013 15:31:46 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1387639906.81.0.450840337389.issue19734@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:33:16 2013
From: report at bugs.python.org (telmich)
Date: Sat, 21 Dec 2013 15:33:16 +0000
Subject: [issue14228] It is impossible to catch sigint on startup in python
 code
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387639996.49.0.795941503086.issue14228@psf.upfronthosting.co.za>


telmich added the comment:

Victor, the problem is *not* that python exits. This is fine and virtually every other unix program behaves like that.

The problem is that python throws an ugly-to-read and completly senseless backtrace to the novice (end!) user by default. Backtraces are great for debugging and should be treated as such, but not presented to an end user by default.

But I as a developer, who wants to prevent the user seeing a backtrace while she does the most normal thing, this places a huge burden on me and I need to use undocumented workarounds to try to prevent this - in the case of a try... except block around my whole program even without suceess.

The point is that no programming language should shout its internals to an end user and prevent the developer from cushion it easily.

Think about "ls -lR" that throws debugging symbols at you, because you interrupted it - you would not want to see them, nor what you be happy if you had to cushion and especially not if this was not documented and hard to do.

So in short my request is to make python more user friendly by cushion the unnecessary backtrace of a Ctrl-C printed out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:38:33 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Dec 2013 15:38:33 +0000
Subject: [issue20043] test_multiprocessing_main_handling fails
 --without-threads
In-Reply-To: <1387636125.31.0.836708895935.issue20043@psf.upfronthosting.co.za>
Message-ID: <1387640313.98.0.131639831611.issue20043@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is fixed by changeset http://hg.python.org/cpython/rev/239faf6b6e8d:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5875/steps/test/logs/stdio

----------
components: +Library (Lib), Tests -2to3 (2.x to 3.x conversion tool)
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20043>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:43:58 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 21 Dec 2013 15:43:58 +0000
Subject: [issue20043] test_multiprocessing_main_handling fails
 --without-threads
In-Reply-To: <1387636125.31.0.836708895935.issue20043@psf.upfronthosting.co.za>
Message-ID: <1387640638.22.0.292054985858.issue20043@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks! I wasn't aware of this issue.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20043>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:44:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Dec 2013 15:44:17 +0000
Subject: [issue14228] Don't display traceback when import site is interrupted
 by CTRL+c
In-Reply-To: <1331197536.95.0.87995012042.issue14228@psf.upfronthosting.co.za>
Message-ID: <1387640657.19.0.782009598804.issue14228@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"The problem is that python throws an ugly-to-read and completly senseless backtrace to the novice (end!) user by default."

Oh ok, I changed the title of the issue.

"Backtraces are great for debugging and should be treated as such, but not presented to an end user by default."

We may hide the traceback by default or even do not write anything by default, and write the traceback when -v option is used.

We may hide the traceback when -q is used.

----------
title: It is impossible to catch sigint on startup in python code -> Don't display traceback when import site is interrupted by CTRL+c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14228>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:46:44 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 15:46:44 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387640804.29.0.136680856885.issue20042@psf.upfronthosting.co.za>


Konstantin Zemlyak added the comment:

There is something weird with my proposed fix. Right after submitting a bug with patch I've updated pythons on my system - 2.7.5 to 2.7.6, 3.3.2 to 3.3.3, and installed 3.4.0b1 - both 32- and 64-bit. Then my fixed py.exe stopped working.

Then I've added _setmode for stdin/stdout/stderr and rebuilt both debug/release and x86/x64 versions:

E:\>set PYLAUNCH_DEBUG=1

E:\>e:\cpython\PCbuild\py.exe ??????.py
launcher build: 32bit
launcher executable: Console
launcher charset: Multi-byte
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
File 'e:\cpython\PCbuild\py.ini' non-existent
Called with command line: .py
maybe_handle_shebang: read 211 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 64bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files\Python27\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python32\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python33\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python34\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files (x86)\Python27\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python32\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python33\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python34\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
found configured value 'python3=3.3-32' in environment
search for Python version '3.3-32' found '"C:\Program Files (x86)\Python33\python.exe"'
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" .py'
C:\Program Files (x86)\Python33\python.exe: can't open file '.py': [Errno 2] No such file or directory
child process exit code: 2

E:\>e:\cpython\PCbuild\py_d.exe ??????.py
launcher build: 32bit
launcher executable: Console
launcher charset: Multi-byte
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
File 'e:\cpython\PCbuild\py.ini' non-existent
Called with command line: ??????.py
maybe_handle_shebang: read 211 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 64bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files\Python27\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python32\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python33\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python34\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files (x86)\Python27\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python32\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python33\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python34\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
found configured value 'python3=3.3-32' in environment
search for Python version '3.3-32' found '"C:\Program Files (x86)\Python33\python.exe"'
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" ??????.py'
??????
child process exit code: 0

E:\>e:\cpython\PCbuild\amd64\py.exe ??????.py
launcher build: 64bit
launcher executable: Console
launcher charset: Multi-byte
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
File 'e:\cpython\PCbuild\amd64\py.ini' non-existent
Called with command line: ??????.py
maybe_handle_shebang: read 211 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 32bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files (x86)\Python27\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python32\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python33\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python34\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files\Python27\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python32\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python33\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python34\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
found configured value 'python3=3.3-32' in environment
search for Python version '3.3-32' found '"C:\Program Files (x86)\Python33\python.exe"'
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" ??????.py'
??????
child process exit code: 0

E:\>e:\cpython\PCbuild\amd64\py_d.exe ??????.py
launcher build: 64bit
launcher executable: Console
launcher charset: Multi-byte
File 'C:\Users\Zart\AppData\Local\py.ini' non-existent
File 'e:\cpython\PCbuild\amd64\py.ini' non-existent
Called with command line: ?????.py
maybe_handle_shebang: read 211 bytes
maybe_handle_shebang: BOM not found, using UTF-8
parse_shebang: found command: python3
locating Pythons in 32bit registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files (x86)\Python27\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python32\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python33\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python34\python.exe" is a 32bit executable
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files (x86)\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locating Pythons in native registry
locate_pythons_for_key: unable to open PythonCore key in HKCU
locate_pythons_for_key: "C:\Program Files\Python27\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python2\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python32\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python33\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python34\python.exe" is a 64bit executable
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
locate_pythons_for_key: "C:\Program Files\Python3\PCBuild\amd64\python.exe: ?????????????? ?????? ? ????? ?????, ????? ????? ??? ????? ????.
found configured value 'python3=3.3-32' in environment
search for Python version '3.3-32' found '"C:\Program Files (x86)\Python33\python.exe"'
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" ?????.py'
C:\Program Files (x86)\Python33\python.exe: can't open file '<unprintable file name>': [Errno 2] No such file or directory
child process exit code: 2




Setting wide mode for stderr had fixed error messages in debug output. And looks like x64 debug build has off-by-one error and CRT behavior is wonky regarding command-line handling. So my patch doesn't really fix original problem yet exhibits some underlying crt bug.

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 16:56:59 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Dec 2013 15:56:59 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387641419.01.0.210076030134.issue19861@psf.upfronthosting.co.za>


R. David Murray added the comment:

The command is listed in 'make help'.

It was seeing this issue go by that reminded me that this job needed to be done, but it's a big one and will probably take me until the actual release to finish it, assuming I manage to finish.  (The 3.3 What's New was never finished, but I started contributing to that rather late in the game.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:15:20 2013
From: report at bugs.python.org (Francis Moreau)
Date: Sat, 21 Dec 2013 16:15:20 +0000
Subject: [issue20044] gettext.install() ignores previous call to
 locale.setlocale()
Message-ID: <1387642520.63.0.386289472626.issue20044@psf.upfronthosting.co.za>


New submission from Francis Moreau:

It seems that gettext.install() uses environment variables such as LANGUAGE, to find out which language it should use to find the translation file.

This means that any local settings done by setlocale() previoulsy are ignored.

I don't think it's the case with the C implementation.

----------
components: Library (Lib)
messages: 206762
nosy: fmoreau
priority: normal
severity: normal
status: open
title: gettext.install() ignores previous call to locale.setlocale()
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20044>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:28:27 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 21 Dec 2013 16:28:27 +0000
Subject: [issue18603] PyOS_mystricmp unused and no longer available
In-Reply-To: <1375228725.23.0.641374823001.issue18603@psf.upfronthosting.co.za>
Message-ID: <1387643307.74.0.868048119804.issue18603@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18603>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:35:23 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 21 Dec 2013 16:35:23 +0000
Subject: [issue20044] gettext.install() ignores previous call to
 locale.setlocale()
In-Reply-To: <1387642520.63.0.386289472626.issue20044@psf.upfronthosting.co.za>
Message-ID: <1387643723.86.0.839104868188.issue20044@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20044>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:38:32 2013
From: report at bugs.python.org (Konstantin Zemlyak)
Date: Sat, 21 Dec 2013 16:38:32 +0000
Subject: [issue20042] Python Launcher for Windows fails to invoke scripts with
 non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1387643912.46.0.440351313771.issue20042@psf.upfronthosting.co.za>


Konstantin Zemlyak added the comment:

Some more fun stuff with command-line (I'm cutting output to few essential lines for easier reading):


e:\cpython\PCbuild\py.exe ??????.py
...
Called with command line: .py
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" .py'
C:\Program Files (x86)\Python33\python.exe: can't open file '.py': [Errno 2] No such file or directory
child process exit code: 2

e:\cpython\PCbuild\py.exe e:\??????.py
...
Called with command line: e:\??????.py
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" e:\??????.py'
child process exit code: 0


E:\>e:\cpython\PCbuild\py.exe ????\unicode.py
...
Called with command line: ???\unicode.py
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" ???\unicode.py'
C:\Program Files (x86)\Python33\python.exe: can't open file '<unprintable file name>': [Errno 2] No such file or directory
child process exit code: 2

E:\>e:\cpython\PCbuild\py.exe e:\????\unicode.py
...
Called with command line: e:\????\unicode.py
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" e:\????\unicode.py'
child process exit code: 0


E:\>e:\cpython\PCbuild\py.exe "??????.py"
Called with command line: "??????.py"
run_child: about to run '"C:\Program Files (x86)\Python33\python.exe" "??????.py"'
child process exit code: 0




IOW, so long as command-line starts with ASCII character everything is fine. If not, then one or more characters gets mangled. Now I'm not sure whether it's a cmd.exe bug or C runtime one, and whether it's possible to workaround about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:42:30 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 21 Dec 2013 16:42:30 +0000
Subject: [issue20045] setup.py register --list-classifiers is broken
Message-ID: <1387644150.38.0.435206294981.issue20045@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

$ ./python -V
Python 3.4.0b1
$ ./python setup.py register --list-classifiers
running register
running check
Traceback (most recent call last):
  File "setup.py", line 2219, in <module>
    main()
  File "setup.py", line 2214, in main
    "Tools/scripts/2to3", "Tools/scripts/pyvenv"]
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/dist.py", line 974, in run_command
    cmd_obj.run()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/register.py", line 54, in run
    self.classifiers()
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/command/register.py", line 90, in classifiers
    log.info(response.read())
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/log.py", line 44, in info
    self._log(INFO, msg, args)
  File "/home/giampaolo/svn/python/3.4/Lib/distutils/log.py", line 33, in _log
    msg = msg.encode(encoding, "backslashreplace").decode(encoding)
AttributeError: 'bytes' object has no attribute 'encode'

----------
components: Distutils
messages: 206764
nosy: eric.araujo, giampaolo.rodola, tarek
priority: normal
severity: normal
status: open
title: setup.py register --list-classifiers is broken
versions: Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20045>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:57:04 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 21 Dec 2013 16:57:04 +0000
Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1387645024.95.0.893184236007.issue16074@psf.upfronthosting.co.za>


Jakub Wilk added the comment:

As far as rename() and link() are concerned, either of the arguments can cause an ENOENT error:

os.rename('/dev/foobar', '/dev/barfoo') # fails because /dev/foobar doesn't exist

os.rename('/dev/null', '/foo/bar/baz') # fails because /foo/bar doesn't exist

----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16074>
_______________________________________

From report at bugs.python.org  Sat Dec 21 17:57:29 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 21 Dec 2013 16:57:29 +0000
Subject: [issue20037] Calling traceback.format_exception() during Pyhon
 shutdown does crash Python
In-Reply-To: <1387577947.41.0.102377073108.issue20037@psf.upfronthosting.co.za>
Message-ID: <1387645049.41.0.273994881271.issue20037@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks for the quick fix guys! Sorry for the duplicate bug (probably a race condition :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20037>
_______________________________________

From report at bugs.python.org  Sat Dec 21 18:09:52 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 21 Dec 2013 17:09:52 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1387645792.44.0.503894247031.issue19846@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Sat Dec 21 18:10:09 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 21 Dec 2013 17:10:09 +0000
Subject: [issue15216] Support setting the encoding on a text stream after
 creation
In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za>
Message-ID: <1387645809.54.0.219355862238.issue15216@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15216>
_______________________________________

From report at bugs.python.org  Sat Dec 21 18:10:37 2013
From: report at bugs.python.org (Jakub Wilk)
Date: Sat, 21 Dec 2013 17:10:37 +0000
Subject: [issue19977] Use "surrogateescape" error handler for sys.stdin and
 sys.stdout on UNIX for the C locale
In-Reply-To: <1386952820.2.0.77364136667.issue19977@psf.upfronthosting.co.za>
Message-ID: <1387645837.74.0.0919456939807.issue19977@psf.upfronthosting.co.za>


Changes by Jakub Wilk <jwilk at jwilk.net>:


----------
nosy: +jwilk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19977>
_______________________________________

From report at bugs.python.org  Sat Dec 21 19:31:18 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 21 Dec 2013 18:31:18 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387650678.11.0.0949197406063.issue19927@psf.upfronthosting.co.za>


Larry Hastings added the comment:

That's not how this works, Eric.  I have to give you permission to add a new feature, which I remind you I have yet to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sat Dec 21 19:37:44 2013
From: report at bugs.python.org (paul j3)
Date: Sat, 21 Dec 2013 18:37:44 +0000
Subject: [issue20039] Missing documentation for argparse.ArgumentTypeError
In-Reply-To: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>
Message-ID: <1387651064.98.0.804345628122.issue20039@psf.upfronthosting.co.za>


paul j3 added the comment:

In argparse.py the status of ArgumentTypeError is ambiguous.

ArgumentError is listed as a public class, ArgumentTypeError is not.  It also says 'All other classes in this module are considered implementation details.'

ArgumentTypeError is a subclass of Exception (with no added functionality).

ArgumentTypeError is raised only once, in the FileType class (which is both a scripting convenience and example of a custom type).  As you note it is also used in the documentation example.  There is also one such example in test_argparse.py.

It is caught once, where it is converted into an ArgumentError.  It is handled much like a ValueError or TypeError - except that its message is passed through unchanged.  

In http://bugs.python.org/issue13824 I use it several times in the FileContext class for just this reason.  

In fact ArgumentTypeError could be documented as a footnote to the `type` block, saying to the effect: 'An ArgumentTypeError may be raised (instead of a ValueError or TypeError) to produce a custom error message.'

Normally an ArgumentTypeError is not passed back to the user code, consistent with the claim that it is not public.

--------------

Along the same line, should ArgumentError be documented better?  Currently it is just mentioned at the end, as a replacement for an optparse error class.

As best I can tell, the user code will only see an ArgumentError if the ArgumentParser.error method is customized.  Otherwise that error is caught and converted into a system exit.  Maybe the `error` paragraph in the documentation should get a sentence about ArgumentError.

In test_argparse.py, ArgumentError is used extensively (with a custom error method).

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20039>
_______________________________________

From report at bugs.python.org  Sat Dec 21 20:20:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 19:20:58 +0000
Subject: [issue20046] Optimize locale aliases table
Message-ID: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes over 400 entities from locale alias tables. They are redundant because they can be calculated on fly.

Also it enables utf8 aliases. Now this adds not hundreds of redundant aliases, but only 8 new locales:

+    'be_bg.utf8':                           'bg_BG.UTF-8',
+    'c.utf8':                               'en_US.UTF-8',
+    'en_dl.utf8':                           'en_DL.UTF-8',
+    'en_zw.utf8':                           'en_ZS.UTF-8',
+    'pa_pk.utf8':                           'pa_PK.UTF-8',
+    'sr_yu.utf8':                           'sr_RS.UTF-8',
+    'te_in.utf8':                           'te_IN.UTF-8',
+    'zh_sg.utf8':                           'zh_SG.UTF-8',

----------
components: Library (Lib)
files: locale_optimize_aliases.patch
keywords: patch
messages: 206769
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Optimize locale aliases table
type: enhancement
Added file: http://bugs.python.org/file33249/locale_optimize_aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Sat Dec 21 20:22:08 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 19:22:08 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>
Message-ID: <1387653728.88.0.600675756703.issue20046@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Fix makelocalealias.py for Python 3, Fixed support for Indian locales

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Sat Dec 21 20:33:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 19:33:26 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>
Message-ID: <1387654406.9.0.104686216013.issue20046@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Example.

     'br_fr':                                'br_FR.ISO8859-1',
-    'br_fr.iso88591':                       'br_FR.ISO8859-1',
-    'br_fr.iso885914':                      'br_FR.ISO8859-14',
-    'br_fr.iso885915':                      'br_FR.ISO8859-15',
-    'br_fr.iso885915 at euro':                 'br_FR.ISO8859-15',
-    'br_fr.utf8 at euro':                      'br_FR.UTF-8',
-    'br_fr at euro':                           'br_FR.ISO8859-15',

Only one of 7 br_fr entities are left. For br_fr.iso88591, br_fr.iso885914 and br_fr.iso885915 just replaced encoding of base br_fr locale. For br_fr.iso885915 at euro and br_fr.utf8 at euro the @euro modifier is dropped because ISO8859-15 and UTF-8 already contains the euro character. For br_fr at euro default ISO8859-1 encoding replaced to ISO8859-15 and the @euro modifier is dropped.

So now the table contains only base entities which map lang_country to lang_country.encoding and special cases for deprecated and obscure aliases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Sat Dec 21 20:41:46 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 21 Dec 2013 19:41:46 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387654906.94.0.28810383699.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

My bad, Larry.  I guess I was reading between the lines too much. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sat Dec 21 20:41:47 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 19:41:47 +0000
Subject: [issue19463] assertGdbRepr depends on hash randomization / endianess
In-Reply-To: <1383245602.59.0.0634998131847.issue19463@psf.upfronthosting.co.za>
Message-ID: <1387654907.15.0.0767440048482.issue19463@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/1009/steps/test/logs/stdio

This is a different issue than the one reported here.

I'm not seeing any recent failures on "PPC64 PowerLinux 3.x". Christian, can we close?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19463>
_______________________________________

From report at bugs.python.org  Sat Dec 21 20:52:41 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Dec 2013 19:52:41 +0000
Subject: [issue20047] bytearray partition bug
Message-ID: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

If partition is called with a single byte it works correctly but if called with the equivalent integer it returns the same bytearray with two empty arrays as follows.

py> ba = bytearray(range(8))
py> ba
bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07')
py> 3 in ba
True
py> ba.find(3) == ba.index(3) == ba.find(b'\x03')
True
py> ba.partition(b'\x03')
(bytearray(b'\x00\x01\x02'), bytearray(b'\x03'), bytearray(b'\x04\x05\x06
\x07'))
py> ba.partition(3)
(bytearray(b'\x00\x01\x02\x03\x04\x05\x06\x07'), bytearray(b''), bytearray
(b''))

More background on the thread starting here https://mail.python.org/pipermail/python-list/2013-December/663111.html which refers to Issue 12170.

----------
components: Interpreter Core
messages: 206773
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: bytearray partition bug
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:00:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 20:00:49 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1387656049.0.0.00289554318649.issue20047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Similar bug was in 3.2:

>>> ba = bytearray(range(8))
>>> ba[2:6]
bytearray(b'\x02\x03\x04\x05')
>>> ba[2:6] = 2
>>> ba
bytearray(b'\x00\x01\x00\x00\x06\x07')

Now it is fixed.

----------
nosy: +serhiy.storchaka
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:12:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 20:12:07 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1387656727.87.0.372632757214.issue20047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Bytearray slice assignment bug was fixed in issue8401.

----------
nosy: +ezio.melotti, georg.brandl, loewis, mark.dickinson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:33:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 20:33:59 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387658039.41.0.550692268368.issue18879@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a proper patch (for 3.3). Untested under Windows, but should work.

----------
nosy: +pitrou
Added file: http://bugs.python.org/file33250/tempfile_lifetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:38:05 2013
From: report at bugs.python.org (Elias Zamaria)
Date: Sat, 21 Dec 2013 20:38:05 +0000
Subject: [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1387658285.6.0.917376695995.issue19980@psf.upfronthosting.co.za>


Elias Zamaria added the comment:

I have created a patch that fixes this issue that terry.reedy described. It does not fix the problem described BreamoreBoy involving the empty string.

Please note that this is my first patch for Python so let me know if I am missing something or if I can do anything else to help.

----------
keywords: +patch
nosy: +mikez302
Added file: http://bugs.python.org/file33251/help-response.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19980>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:41:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 20:41:32 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387658492.15.0.919609891037.issue18879@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file33252/tempfile_lifetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:41:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 20:41:38 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387658498.16.0.763037668827.issue18879@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file33250/tempfile_lifetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:42:01 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 20:42:01 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387658521.94.0.458564836173.issue18879@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Oops, removed two debug lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 21:58:59 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 20:58:59 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
Message-ID: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

This problem happens when I unpack a file from a 200+ MB zip archive as follows:

with zipfile.ZipFile(archive) as z:
    data = b''
    with z.open(filename, 'rU') as f:
        for line in f:
      	    data += line


I cannot reduce it to a test case suitable for posting here, but the culprit is the following code in zipfile.py:

    def peek(self, n=1):
        """Returns buffered bytes without advancing the position."""
        if n > len(self._readbuffer) - self._offset:
            chunk = self.read(n)
            self._offset -= len(chunk)

See http://hg.python.org/cpython/file/81f8375e60ce/Lib/zipfile.py#l605

The problem occurs when peek() is called on the boundary of the uncompress buffer and read() goes through more than one readbuffer.  The result is that self._offset is smaller than len(chunk) leading to a non-sensical negative self._offset upon return from peek().

This problem does not seem to appear in 3.x since 028e8e0b03e8.

----------
messages: 206779
nosy: belopolsky
priority: normal
severity: normal
status: open
title: zipfile's readline() drops data in universal newline mode
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:00:23 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 21:00:23 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387659623.03.0.1191608525.issue20048@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +Add support for bzip2 compression to the zipfile module
keywords: +gsoc
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:04:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 21:04:12 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387659852.05.0.0797742236505.issue18879@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thank you Antoine.

----------
assignee: serhiy.storchaka -> pitrou
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:17:24 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 21:17:24 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387660644.23.0.471110409215.issue20048@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
keywords: +3.2regression -gsoc
nosy: +alanmcintyre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:19:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Dec 2013 21:19:20 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <3dn07q4g78z7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset f3b7a76fb778 by Antoine Pitrou in branch '3.3':
Issue #18879: When a method is looked up on a temporary file, avoid closing the file before the method is possibly called.
http://hg.python.org/cpython/rev/f3b7a76fb778

New changeset d68ab2eb7a77 by Antoine Pitrou in branch 'default':
Issue #18879: When a method is looked up on a temporary file, avoid closing the file before the method is possibly called.
http://hg.python.org/cpython/rev/d68ab2eb7a77

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:20:32 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 21:20:32 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387660832.1.0.0713297000215.issue20048@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
keywords:  -3.2regression

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:21:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 21:21:12 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387660872.78.0.0389261716778.issue18879@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed in 3.3 and 3.4. I think 2.7 is irrelevant at this point.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:21:15 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 21:21:15 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387660875.27.0.910523662273.issue20048@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
components: +Library (Lib)
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:21:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 21:21:19 +0000
Subject: [issue18879] tempfile.NamedTemporaryFile can close the file too early, 
 if not assigning to a variable
In-Reply-To: <1377807943.36.0.898364678904.issue18879@psf.upfronthosting.co.za>
Message-ID: <1387660879.41.0.0221802285407.issue18879@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: commit review -> committed/rejected
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18879>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:22:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 21:22:25 +0000
Subject: [issue20045] setup.py register --list-classifiers is broken
In-Reply-To: <1387644150.38.0.435206294981.issue20045@psf.upfronthosting.co.za>
Message-ID: <1387660945.38.0.00283815904798.issue20045@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
priority: normal -> high
stage:  -> needs patch
type:  -> behavior
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20045>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:23:43 2013
From: report at bugs.python.org (Arnaut Billings)
Date: Sat, 21 Dec 2013 21:23:43 +0000
Subject: [issue20039] Missing documentation for argparse.ArgumentTypeError
In-Reply-To: <1387622425.21.0.562750433804.issue20039@psf.upfronthosting.co.za>
Message-ID: <1387661023.33.0.575321887187.issue20039@psf.upfronthosting.co.za>


Arnaut Billings added the comment:

It seems what you're saying is that the ArgumentTypeError class should not be public, but being able to raise is should be public. If that's the case, I think it would be more clear to have an argparse.raiseArgumentTypeError method and document when it should be used.

If such classes are meant to be private, why not prepend their names with an underscore and remove them from the __all__ list? (I thought a leading underscore meant that a module level variable was private to that module.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20039>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:24:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 21:24:48 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387661088.47.0.284590796045.issue20048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does this patch fix a bug?

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file33253/zipfile_peek.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:29:03 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 21 Dec 2013 21:29:03 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387661343.47.0.465692649573.issue20048@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

It does!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:29:54 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 21:29:54 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1387661394.02.0.185852133242.issue7464@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:30:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 21:30:00 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1387661400.12.0.249231280145.issue19524@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:30:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 21:30:04 +0000
Subject: [issue18144] FD leak in urllib2
In-Reply-To: <1370459423.62.0.313188871142.issue18144@psf.upfronthosting.co.za>
Message-ID: <1387661404.28.0.458132025254.issue18144@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18144>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:38:37 2013
From: report at bugs.python.org (Alexander Pyhalov)
Date: Sat, 21 Dec 2013 21:38:37 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
Message-ID: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>


New submission from Alexander Pyhalov:

When Python 2.6 (or 2.7) compiled with _XOPEN_SOURCE=600 on illumos  string.lowercase and string.uppercase contain garbage when UTF-8 locale is used. 
(OpenIndiana bug report - https://www.illumos.org/issues/4411 ).
The reason is that with UTF-8 locale islower()/isupper() and similar functions are not expected to work with non-ascii symbols. 
So, code like 

    n = 0;
    for (c = 0; c < 256; c++) {
        if (islower(c))
            buf[n++] = c;
    }

is expected to fail, because it calls islower on illegal UTF-8 symbols (with codes 128-255). It should be converted to something like

    n = 0;
    for (c = 0; c < 256; c++) {
        if (isascii(c) && islower(c))
            buf[n++] = c;
    }

or to 

    n = 0;
    for (c = 0; c < 128; c++) {
        if (islower(c))
            buf[n++] = c;
    }

Before doing this you should check if locale is UTF-8. However, almost all non-C locales on illumos are UTF-8. 


Example of incorrect behavior: 

Python 2.6.9 (unknown, Nov 12 2013, 13:54:48) 
[GCC 4.7.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import string
>>> string.lowercase
'abcdefghijklmnopqrstuvwxyz\\xaa\\xb5\\xba\\xdf\\xe0\\xe1\\xe2\\xe3\\xe4\\xe5\\xe6\\xe7\\xe8\\xe9\\xea\\xeb\\xec\\xed\\xee\\xef\\xf0\\xf1\\xf2\\xf3\\xf4\\xf5\\xf6\\xf8\\xf9\\xfa\\xfb\\xfc\\xfd\\xfe\\xff'
>>> string.uppercase
'ABCDEFGHIJKLMNOPQRSTUVWXYZ\\xc0\\xc1\\xc2\\xc3\\xc4\\xc5\\xc6\\xc7\\xc8\\xc9\\xca\\xcb\\xcc\\xcd\\xce\\xcf\\xd0\\xd1\\xd2\\xd3\\xd4\\xd5\\xd6\\xd8\\xd9\\xda\\xdb\\xdc\\xdd\\xde'
>>>

----------
components: Unicode
messages: 206786
nosy: Alexander.Pyhalov, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: string.lowercase and string.uppercase can contain garbage
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:38:44 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 21 Dec 2013 21:38:44 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1387654406.9.0.104686216013.issue20046@psf.upfronthosting.co.za>
Message-ID: <52B60A58.8070106@egenix.com>


Marc-Andre Lemburg added the comment:

On 21.12.2013 20:33, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Example.
> 
>      'br_fr':                                'br_FR.ISO8859-1',
> -    'br_fr.iso88591':                       'br_FR.ISO8859-1',
> -    'br_fr.iso885914':                      'br_FR.ISO8859-14',
> -    'br_fr.iso885915':                      'br_FR.ISO8859-15',
> -    'br_fr.iso885915 at euro':                 'br_FR.ISO8859-15',
> -    'br_fr.utf8 at euro':                      'br_FR.UTF-8',
> -    'br_fr at euro':                           'br_FR.ISO8859-15',
> 
> Only one of 7 br_fr entities are left. For br_fr.iso88591, br_fr.iso885914 and br_fr.iso885915 just replaced encoding of base br_fr locale. For br_fr.iso885915 at euro and br_fr.utf8 at euro the @euro modifier is dropped because ISO8859-15 and UTF-8 already contains the euro character. For br_fr at euro default ISO8859-1 encoding replaced to ISO8859-15 and the @euro modifier is dropped.
> 
> So now the table contains only base entities which map lang_country to lang_country.encoding and special cases for deprecated and obscure aliases.

Looks like an interesting approach, but I'd like to think about it
a day or two.

Some notes:
* the patch seems to include some unrelated changes, e.g. the
  devanagari fixes and a few new mappings
* the optimize step is called twice for some reason - is this
  intended ? if yes, please add a comment why this is done
* the patch would need some tests to make sure that the removed
  aliases indeed still map to the correct C locale strings

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:52:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Dec 2013 21:52:31 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <3dn0t64Mkvz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 8b097d07488d by Serhiy Storchaka in branch '2.7':
Issue #20048: Fixed ZipExtFile.peek() when it is called on the boundary of
http://hg.python.org/cpython/rev/8b097d07488d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:55:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 21:55:42 +0000
Subject: [issue20048] zipfile's readline() drops data in universal newline mode
In-Reply-To: <1387659539.36.0.629484655922.issue20048@psf.upfronthosting.co.za>
Message-ID: <1387662942.16.0.0979105665527.issue20048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Than you for your report and irrefragable analysis.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20048>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:59:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Dec 2013 21:59:14 +0000
Subject: [issue20045] setup.py register --list-classifiers is broken
In-Reply-To: <1387644150.38.0.435206294981.issue20045@psf.upfronthosting.co.za>
Message-ID: <3dn11s2nWnz7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset cffed58b1bbd by Antoine Pitrou in branch '3.3':
Issue #20045: Fix "setup.py register --list-classifiers".
http://hg.python.org/cpython/rev/cffed58b1bbd

New changeset 597b69d3a74f by Antoine Pitrou in branch 'default':
Issue #20045: Fix "setup.py register --list-classifiers".
http://hg.python.org/cpython/rev/597b69d3a74f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20045>
_______________________________________

From report at bugs.python.org  Sat Dec 21 22:59:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 21:59:51 +0000
Subject: [issue20045] setup.py register --list-classifiers is broken
In-Reply-To: <1387644150.38.0.435206294981.issue20045@psf.upfronthosting.co.za>
Message-ID: <1387663191.71.0.331285585539.issue20045@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Fixed, thanks for reporting.

----------
nosy: +pitrou
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20045>
_______________________________________

From report at bugs.python.org  Sat Dec 21 23:22:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Dec 2013 22:22:26 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1387664546.38.0.377639064194.issue20047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Whatever the change, bytes and bytearray should act the same.

>>> b = bytes(range(8))
>>> b
b'\x00\x01\x02\x03\x04\x05\x06\x07'
>>> b.partition(3)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    b.partition(3)
TypeError: expected bytes, bytearray or buffer compatible object

As noted in the thread, ba.partition(a) apparently is executed as ba.partition(bytearray(a)) if a is not a bytearray (or maybe not a buffer object). bytearray(3) == bytearray((0,0,0)) and the latter is not in ba and hence the output given is 'correct'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sat Dec 21 23:38:39 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Dec 2013 22:38:39 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1387665519.28.0.280511084174.issue20047@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I believe that all methods should act the same, but they don't as a result of the work done in issue12170.  E.g. find will accept integer input but split will not.  Given this comment at the top of test_bytes.py "XXX This is a mess.  Common tests should be moved to buffer_tests.py, which itself ought to be unified with string_tests.py (and the latter should be modernized).", it looks like a thorough review of the code and tests is in order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20047>
_______________________________________

From report at bugs.python.org  Sun Dec 22 00:21:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Dec 2013 23:21:36 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387668096.55.0.208069490398.issue20049@psf.upfronthosting.co.za>


R. David Murray added the comment:

In python2, string.lowercase and string.uppercase are locale dependent.  This isn't really all that useful in practice, which is why it was dropped in Python3.  The proposed fix might be correct, *if* utf-8 is checked for (see, eg, Issue 6525), but...do you have any idea why this is a problem on illumos with _XOPEN_SOURCE=600 but not on any other platform (as far as we know)?  It seems like it would be a bug in the platform's islower and isupper functions, which are supposed to operate on integers that fit in an unsigned char, and be locale aware, according to the standards.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 00:25:13 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Dec 2013 23:25:13 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387668313.32.0.760297848097.issue20049@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> The reason is that with UTF-8 locale islower()/isupper() and similar
> functions are not expected to work with non-ascii symbols. 

Can you explain why?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 00:38:34 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Dec 2013 23:38:34 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <52B60A58.8070106@egenix.com>
Message-ID: <13879211.rAT1KLZY4E@raxxla>


Serhiy Storchaka added the comment:

> * the patch seems to include some unrelated changes, e.g. the
>   devanagari fixes and a few new mappings

May be. In any case I have added issue20027 as dependency. New mappings were 
added when enable UTF-8 locales in makelocalealias.py (I can split this in 
separate issue).

> * the optimize step is called twice for some reason - is this
>   intended ? if yes, please add a comment why this is done

Actually we should call it in a loop while the size of the table is decreased.

> * the patch would need some tests to make sure that the removed
>   aliases indeed still map to the correct C locale strings

Currently the makelocalealias.py is such manual test. test_locale contains 
multiple tests for different locales. I'll add several new cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:29:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:29:31 +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: <1387672171.96.0.353184527757.issue12226@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: eric.araujo -> 
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:36:00 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Dec 2013 00:36:00 +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: <3dn4Vl3DVDz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 32a39ec6bd75 by Antoine Pitrou in branch '2.7':
Issue #12226: HTTPS is now used by default when connecting to PyPI.
http://hg.python.org/cpython/rev/32a39ec6bd75

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:48:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Dec 2013 00:48:17 +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: <3dn4mw4VLlz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 2b5cd6d4d149 by Antoine Pitrou in branch '3.2':
Issue #12226: HTTPS is now used by default when connecting to PyPI.
http://hg.python.org/cpython/rev/2b5cd6d4d149

New changeset e5a9755c967c by Antoine Pitrou in branch '3.3':
Issue #12226: HTTPS is now used by default when connecting to PyPI.
http://hg.python.org/cpython/rev/e5a9755c967c

New changeset 9839aa0e5b28 by Antoine Pitrou in branch 'default':
Null merge (#12226 already fixed on default)
http://hg.python.org/cpython/rev/9839aa0e5b28

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:50:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:50:04 +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: <1387673404.49.0.145208400386.issue12226@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Closing as fixed, and opening a new issue for cert checking.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12226>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:52:05 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:52:05 +0000
Subject: [issue20050] distutils should check PyPI certs when connecting to it
Message-ID: <1387673525.81.0.630232623355.issue20050@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Spun off from #12226: distutils now uses HTTPS by default to connect PyPI, but certs aren't checked at all.

----------
components: Library (Lib)
messages: 206800
nosy: Giovanni.Bajo, alexis, benjamin.peterson, christian.heimes, dstufft, eric.araujo, georg.brandl, pitrou
priority: high
severity: normal
status: open
title: distutils should check PyPI certs when connecting to it
type: security
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20050>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:57:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Dec 2013 00:57:59 +0000
Subject: [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <3dn5054JTpz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 39ea24aaf0e7 by Antoine Pitrou in branch '2.7':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/39ea24aaf0e7

New changeset b63258b6eb4d by Antoine Pitrou in branch '3.3':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/b63258b6eb4d

New changeset d659e7761d59 by Antoine Pitrou in branch 'default':
s/lightweight/minimal/, as per issue #11379.
http://hg.python.org/cpython/rev/d659e7761d59

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11379>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:58:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:58:10 +0000
Subject: [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1387673890.75.0.535430364968.issue17538@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17538>
_______________________________________

From report at bugs.python.org  Sun Dec 22 01:59:30 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 00:59:30 +0000
Subject: [issue17123] Add OCSP support to ssl module
In-Reply-To: <1359994472.8.0.804183286731.issue17123@psf.upfronthosting.co.za>
Message-ID: <1387673970.39.0.793343002339.issue17123@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type: security -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17123>
_______________________________________

From report at bugs.python.org  Sun Dec 22 02:10:50 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 01:10:50 +0000
Subject: [issue20041] TypeError when f_trace is None and tracing.
In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>
Message-ID: <1387674650.93.0.151611023112.issue20041@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky, georg.brandl, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20041>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:03:53 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Dec 2013 03:03:53 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1387654906.94.0.28810383699.issue19927@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cysJS0ymp6mUCwvKUR7FYuoTdd7awvM-=+=BisuJ=JpQ@mail.gmail.com>


Nick Coghlan added the comment:

That reminds me: I ended up working around this in the runpy tests by only
checking the loader type was correct in the module specs. With an improved
definition of equality for loaders, the runpy tests could be both
simplified *and* made more rigorous at the same time (by simply comparing
specs for equality, the same as the other module level attributes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:10:39 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 22 Dec 2013 03:10:39 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387681839.81.0.267624709323.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

Yeah, it was while writing tests that I ran into this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:17:23 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 22 Dec 2013 03:17:23 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387682243.34.0.741113537327.issue19927@psf.upfronthosting.co.za>


Larry Hastings added the comment:

So can you tell me how this will make users' lives easier?  I don't really understand the issues involved.  But the only concrete thing I've seen mentioned is making testing easier, and that's not worth breaking feature freeze over.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:34:07 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Dec 2013 03:34:07 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387683247.49.0.84960054955.issue19927@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yeah, I think we can safely leave this to 3.5.

----------
priority: high -> normal
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:34:26 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 22 Dec 2013 03:34:26 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387683266.54.0.727877152528.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

Right now say you have 2 module specs that are the same.  The only difference is that the 2 loaders are not the same instance (they were created separately with the same arguments, ergo equal).  The two specs will not compare as equal even though they are equal.

I expect users will find it surprising if they compare module.__spec__ to another spec that is basically the same (as described above) and it resolve to not equal.  I can see this as particularly vexing for importer writers that are switching over to the new spec-based APIs.

In my mind, the benefit of removing that unexpected (and aggravating) behavior outweighs the risk that someone is depending on identity-only comparision for the two loader types that are impacted by this change (which were both just added in 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 04:36:19 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Dec 2013 03:36:19 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387683379.14.0.34416057993.issue19927@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Importer writers are already used to __loader__ being annoying, and comparting specs for equality is unlikely to be a common thing (and easily worked around by comparing spec.origin instead)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 08:00:53 2013
From: report at bugs.python.org (Alexander Pyhalov)
Date: Sun, 22 Dec 2013 07:00:53 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387668313.32.0.760297848097.issue20049@psf.upfronthosting.co.za>
Message-ID: <CALOYryEbGkYdbHY1w5RG-sh9j=yOVMwd7d9EEXjBMPNmBRa4Dg@mail.gmail.com>


Alexander Pyhalov added the comment:

Honestly, I don't understand locale-related things good enough. But I
received this explanation when discussed similar issue in illumos
developers mailing list.
http://comments.gmane.org/gmane.os.illumos.devel/14193

2013/12/22 Antoine Pitrou <report at bugs.python.org>

>
> Antoine Pitrou added the comment:
>
> > The reason is that with UTF-8 locale islower()/isupper() and similar
> > functions are not expected to work with non-ascii symbols.
>
> Can you explain why?
>
> ----------
> nosy: +pitrou
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue20049>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 08:31:05 2013
From: report at bugs.python.org (Alexander Pyhalov)
Date: Sun, 22 Dec 2013 07:31:05 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387697465.43.0.214349351055.issue20049@psf.upfronthosting.co.za>


Alexander Pyhalov added the comment:

I've discussed this once more. 

>From islower man page:

RETURN VALUES
     If the argument to any of the character handling  macros  is
     not  in the domain of the function, the result is undefined.

And (char)128-255 are not legal UTF-8 (at least what I see from wikipedia: http://en.wikipedia.org/wiki/UTF-8 ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 08:31:39 2013
From: report at bugs.python.org (gudge)
Date: Sun, 22 Dec 2013 07:31:39 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387697499.95.0.343908675675.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Akira, I will fix it. I will put in the patch in the same bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Sun Dec 22 09:35:42 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Dec 2013 08:35:42 +0000
Subject: [issue20009] Property should expose wrapped function.
In-Reply-To: <1387316995.02.0.931185950843.issue20009@psf.upfronthosting.co.za>
Message-ID: <1387701342.41.0.387404075318.issue20009@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> When using the @property decorator the wrapped functions 
> are not exposed for source introspection. 
> (At least I can't see how they are.)

The underlying functions are already exposed as the "fget", "fset", and "fdel" attributes of property objects.

Here is an example of how to access the source:

class Dog:
    @property
    def age(self):
        return 42

if __name__ == '__main__':
    import inspect
    age_property = Dog.__dict__['age']
    lines, size = inspect.getsourcelines(age_property.fget)
    print(''.join(lines))

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20009>
_______________________________________

From report at bugs.python.org  Sun Dec 22 11:20:16 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Dec 2013 10:20:16 +0000
Subject: [issue19363] Python 2.7's future_builtins.map is not compatible with
 Python 3's map
In-Reply-To: <1382534189.14.0.63787411181.issue19363@psf.upfronthosting.co.za>
Message-ID: <1387707616.76.0.677805507587.issue19363@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I agree with you in principle, but it is far too late in 2.7's development to take away a capability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19363>
_______________________________________

From report at bugs.python.org  Sun Dec 22 11:44:59 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 22 Dec 2013 10:44:59 +0000
Subject: [issue20045] setup.py register --list-classifiers is broken
In-Reply-To: <1387644150.38.0.435206294981.issue20045@psf.upfronthosting.co.za>
Message-ID: <1387709099.76.0.158915135945.issue20045@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Thanks for fixing. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20045>
_______________________________________

From report at bugs.python.org  Sun Dec 22 15:37:02 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 14:37:02 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387697465.43.0.214349351055.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387723018.2302.5.camel@fsol>


Antoine Pitrou added the comment:

> I've discussed this once more. 
> 
> >From islower man page:
> 
> RETURN VALUES
>      If the argument to any of the character handling  macros  is
>      not  in the domain of the function, the result is undefined.

This is not the wording of the POSIX spec:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/islower.html

"""The c argument is an int, the value of which the application shall
ensure is a character representable as an unsigned char or equal to the
value of the macro EOF."""

This means that any value between 0 and 255 ("representable as an
unsigned char") is a valid input for islower().

This would mean IllumOS deviates from the POSIX spec here. I would
suggest either fixing your libc's ctype.h implementation, and/or
patching your version of Python to workaround this issue.

Note the ISO C99 standard has the same wording as POSIX:

"""The header <ctype.h> declares several functions useful for
classifying and mapping characters. In all cases the argument is an int,
the value of which shall be representable as an unsigned char or shall
equal the value of the macro EOF."""

(Note also that under Linux and most likely other Unices,
string.lowercase and string.uppercase work fine under a UTF-8 locale)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 15:38:29 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 14:38:29 +0000
Subject: [issue20045] setup.py register --list-classifiers is broken
In-Reply-To: <1387709099.76.0.158915135945.issue20045@psf.upfronthosting.co.za>
Message-ID: <1387723107.2302.6.camel@fsol>


Antoine Pitrou added the comment:

> Thanks for fixing. =)

You're welcome. Unfixed distutils regressions are painful...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20045>
_______________________________________

From report at bugs.python.org  Sun Dec 22 15:48:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 14:48:53 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387723733.59.0.499395564952.issue20049@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

To elaborate yet a bit, I agree with the following statement in the aforementioned [illumos-devel] discussion thread:

"""In further explanation, the isalpha() and friends *should* probably return false for the value 196, or any other byte with high order bit set, in UTF-8 locales."""
http://thread.gmane.org/gmane.os.illumos.devel/14193/focus=14206

I'll also point out that the code examples in the POSIX spec use islower() exactly like Python does (on arbitrary integers) between 0 and 255:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/islower.html

    c = (unsigned char) (rand() % 256);
...
    if (islower(c))
        keystr[len++] = c;
    }
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 16:03:51 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 15:03:51 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387724631.79.0.117145851741.issue20049@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

As to whether we will add a workaround for this in Python:

- Python follows POSIX correctly here, and no issue was reported in mainstream OSes such as Linux, OS X or the *BSDs

- this only exists in 2.7, which is in extended maintenance mode (it's the last of the 2.x series, and will probably stopped being maintained in a few years); Python 3.x doesn't have this issue

- IllumOS is a rather niche OS that none of us is using, so adding a system-specific workaround doesn't sound very compelling

Thanks for reporting, though. It's good to be reminded that locales and ctype.h are a rather lousy design :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 16:34:02 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 Dec 2013 15:34:02 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387726442.31.0.10061723136.issue20049@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Alexander, the "domain fo the function" probably refers to
the range [-1, 256].

C99:
====

The header <ctype.h> declares several functions useful for classifying and mapping
characters.166) In all cases the argument is an int, the value of which shall be
representable as an unsigned char or shall equal the value of the macro EOF. If the
argument has any other value, the behavior is undefined.
2 The behavior of these functions is affected by the current locale. Those functions that
 have locale-specific aspects only when not in the "C" locale are noted below.
3 The term printing character refers to a member of a locale-specific set of characters, each
 of which occupies one printing position on a display device; the term control character
refers to a member of a locale-specific set of characters that are not printing
characters.167) All letters and digits are printing characters.
Forward references: EOF (7.19.1), localization (7.11).
7.4.1 Character classification functions
1
The functions in this subclause return nonzero (true) if and only if the value of the
argument c conforms to that in the description of the function.


I think this agrees with what Antoine has said.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 16:35:17 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 Dec 2013 15:35:17 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387726517.95.0.956647964866.issue20049@psf.upfronthosting.co.za>


Stefan Krah added the comment:

IOW, I also support closing this issue. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 17:03:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Dec 2013 16:03:05 +0000
Subject: [issue20049] string.lowercase and string.uppercase can contain garbage
In-Reply-To: <1387661917.11.0.929433274966.issue20049@psf.upfronthosting.co.za>
Message-ID: <1387728185.59.0.80182267748.issue20049@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I definitely think this falls into the category of platform bugs, and we only maintain workarounds for those for "mainstream" OSes.  Others need to maintain their own local patches, just as for any other changes that are required to get Python working on those platforms.  (A platform's status can change over time, of course, but this is the category illumos currently falls into.)

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20049>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:18:09 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:18:09 +0000
Subject: [issue19610] TypeError in distutils.command.upload
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1387732689.33.0.531402598093.issue19610@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't think accepting a tuple for classifiers is a bugfix. Furthermore, the latest patch is much too intrusive and may break legitimate uses.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:23:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:23:46 +0000
Subject: [issue17325] improve organization of the PyPI distutils docs
In-Reply-To: <1362131491.68.0.398716399036.issue17325@psf.upfronthosting.co.za>
Message-ID: <1387733026.17.0.870238675526.issue17325@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This looks good to me. It may also be worth changing example URLs to use "https" instead of "http", and mentioning the test PyPI server in the pypirc section: https://wiki.python.org/moin/TestPyPI

Chris, please proceed.

----------
assignee: eric.araujo -> chris.jerdonek
nosy: +pitrou
stage: patch review -> commit review
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17325>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:45:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:45:33 +0000
Subject: [issue9303] Migrate sqlite3 module to _v2 API to enhance performance
In-Reply-To: <1279541286.68.0.824716490463.issue9303@psf.upfronthosting.co.za>
Message-ID: <1387734333.37.0.0920764051082.issue9303@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9303>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:46:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:46:58 +0000
Subject: [issue19216] stat cache for import bootstrap
In-Reply-To: <1381404050.43.0.806301244574.issue19216@psf.upfronthosting.co.za>
Message-ID: <1387734418.48.0.156865610244.issue19216@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19216>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:48:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:48:32 +0000
Subject: [issue15216] Support setting the encoding on a text stream after
 creation
In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za>
Message-ID: <1387734512.78.0.79611578068.issue15216@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15216>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:48:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:48:59 +0000
Subject: [issue19508] Add warning that Python doesn't verify SSL certs by
 default
In-Reply-To: <1383691927.99.0.022250098505.issue19508@psf.upfronthosting.co.za>
Message-ID: <1387734539.64.0.870616713364.issue19508@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/issue19508>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:50:18 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:50:18 +0000
Subject: [issue15340] OSError with "import random" when /dev/urandom doesn't
 exist (regression from 2.6)
In-Reply-To: <1342132229.15.0.69254682318.issue15340@psf.upfronthosting.co.za>
Message-ID: <1387734618.95.0.408639304401.issue15340@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

2.6 and 3.1 don't receive bug fixes anymore, closing.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15340>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:51:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:51:08 +0000
Subject: [issue19610] setup.py should allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1387734668.11.0.352906321108.issue19610@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: patch review -> needs patch
title: TypeError in distutils.command.upload -> setup.py should allow a tuple for classifiers
type: behavior -> enhancement
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Sun Dec 22 18:51:57 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 17:51:57 +0000
Subject: [issue20033] Fix makelocalealias.py for Python 3
In-Reply-To: <1387537501.53.0.333984460427.issue20033@psf.upfronthosting.co.za>
Message-ID: <1387734717.65.0.0407973480302.issue20033@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sounds ok to me.

----------
assignee:  -> serhiy.storchaka
nosy: +pitrou
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20033>
_______________________________________

From report at bugs.python.org  Sun Dec 22 19:05:11 2013
From: report at bugs.python.org (gudge)
Date: Sun, 22 Dec 2013 18:05:11 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1387735511.54.0.40374298601.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

1) I understand I can run a whole test suite as
./python -m test -v test_abc
as mentioned in
http://docs.python.org/devguide/runtests.html

How do I run a particluar test case, like the test I added
test_cert_time_to_seconds

2) I have a added a test case test_cert_time_to_seconds to test_ssl.py. 
3) ./python -m test -v test_ssl
   is all PASS.

4) I will start my work on http://bugs.python.org/issue19940#msg205860.

5) The patch is attached.

----------
Added file: http://bugs.python.org/file33254/patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Sun Dec 22 19:33:19 2013
From: report at bugs.python.org (John Malmberg)
Date: Sun, 22 Dec 2013 18:33:19 +0000
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1349389263.57.0.925729224322.issue16136@psf.upfronthosting.co.za>
Message-ID: <1387737199.87.0.372519260673.issue16136@psf.upfronthosting.co.za>


John Malmberg added the comment:

Access to VMS licenses and media:

1. Hobby - non-commercial applications - Free with 1 year time-bombed license keys with free media download.  A self-service mostly web based system.

http://www.openvms.org/pages.php?page=Hobbyist

Easiest way to get a membership ID is to join Encompasserve.org which is free.

Unfortunately right now, HP is in their holiday shutdown and Encompasserve.org is being relocated from Wisconsin to Massachusetts.

Both should be back available sometime in the beginning of January 2014.

2. Commercial - Company Alliance One Membership.  It is my understanding that upon acceptance to the program, 1 year time-bombed license keys are available with free.  Search for "Alliance One" on the HP site.

This has been the case for well over 10 years, so VMS programmers for open source projects should normally have no problem getting current media or license keys.

There are several free Alpha emulators now available for download.  These are less functional versions of the commercial versions of the emulator.

While there are also commercial VAX emulators that may be available, SimH VAX is free and open source.

Resources: comp.os.vms newsgroup, www.openvmshobbyist.com, sourceforge GNV and vms-ports projects, encompasserve.org, and www.openvms.org


GNV:

GNV as packaged by HP has multiple problems.  To use it at a minimum you need to install the newer Bash and Coreutils kits from the GNV sourceforge project.  Read http://sourceforge.net/p/gnv/wiki/InstallingGNVPackages/ before installing the updates.

Running configure scripts on GNV typically requires some hacks because most configure scripts test with out the header files, and on VMS, the header files are needed to get ANSI/ISO or X/Open behavior or bug-fixes.  Otherwise the tests fail.

Instructions: http://sourceforge.net/p/vms-ports/wiki/GeneratingConfigh/


As far as removing the VMS specific code, it is very likely that much of the VMS specific code is not needed for the current 8.3/8.4 versions of VMS, so it is probably better for a someone porting Python 3.x to VMS to start with clean code.

If a VMS library routine is missing or does not behave properly, it is better handled with a replacement routine than by putting #ifdef in the code.

----------
nosy: +John.Malmberg
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16136>
_______________________________________

From report at bugs.python.org  Sun Dec 22 19:45:03 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 22 Dec 2013 18:45:03 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387737903.73.0.797522660355.issue19927@psf.upfronthosting.co.za>


Larry Hastings added the comment:

1. Is this patch going to change best practice for working with ModuleSpec?

2. If we delayed it to 3.5, will users have to ignore it to work around the deficiencies of the ModuleSpec implementation in 3.4?

I'm guessing the answer to both of these is "well, no, not really" simply because comparing ModuleSpec objects is not expected to be a regular operation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Sun Dec 22 20:57:38 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 Dec 2013 19:57:38 +0000
Subject: [issue19610] setup.py should allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1387742258.93.0.829448551354.issue19610@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Classifiers have always been documented as a list; I don?t think a tuple makes more sense here (even if it does no harm), but more importantly I think it?s a bad idea to have a setup.py that would work in 3.5 and not in 3.2-3.4.  I suggest rejecting this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Sun Dec 22 20:58:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 19:58:28 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <1387742308.07.0.211404674552.issue19648@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The patch looks fine to me. Gennadiy, could you go and sign a contributor's agreement? http://www.python.org/psf/contrib/
Thanks very much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Sun Dec 22 20:58:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 19:58:39 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <1387742319.61.0.912749958404.issue19648@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Sun Dec 22 21:47:36 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 20:47:36 +0000
Subject: [issue18379] SSLSocket.getpeercert(): OCSP and CRL DP URIs
In-Reply-To: <1373113820.69.0.993582296308.issue18379@psf.upfronthosting.co.za>
Message-ID: <1387745256.88.0.0536992275544.issue18379@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/issue18379>
_______________________________________

From report at bugs.python.org  Sun Dec 22 21:49:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 20:49:19 +0000
Subject: [issue19563] Changing barry's email  to barry@python.org
In-Reply-To: <1384283767.67.0.793092256619.issue19563@psf.upfronthosting.co.za>
Message-ID: <1387745359.11.0.522101430131.issue19563@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19563>
_______________________________________

From report at bugs.python.org  Sun Dec 22 21:50:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 20:50:58 +0000
Subject: [issue7171] Add inet_ntop and inet_pton support for Windows
In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za>
Message-ID: <1387745458.56.0.593189769494.issue7171@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7171>
_______________________________________

From report at bugs.python.org  Sun Dec 22 21:53:33 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 20:53:33 +0000
Subject: [issue19501] Buildbot testing of 3.2 broken
In-Reply-To: <1383625464.91.0.832501203458.issue19501@psf.upfronthosting.co.za>
Message-ID: <1387745613.15.0.911674061848.issue19501@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Antoine, can you fix this on the buildmaster or need I apply the patch in the 3.2 branch?

I'd rather you apply the patch in the 3.2 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19501>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:00:32 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 21:00:32 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1387746032.32.0.897545824211.issue16500@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:04:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 21:04:07 +0000
Subject: [issue11471] If without else generates redundant jump
In-Reply-To: <1299880156.4.0.0999870554397.issue11471@psf.upfronthosting.co.za>
Message-ID: <1387746247.92.0.651783386295.issue11471@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.4 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11471>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:06:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 22 Dec 2013 21:06:19 +0000
Subject: [issue15826] Increased test coverage of test_glob.py
In-Reply-To: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za>
Message-ID: <1387746379.02.0.172940793608.issue15826@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15826>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:16:32 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 Dec 2013 21:16:32 +0000
Subject: [issue20051] PA-RISC buildbot: compiler cannot create executables
Message-ID: <1387746992.49.0.56287185551.issue20051@psf.upfronthosting.co.za>


New submission from Stefan Krah:

I think the demo mode for aCC has expired on h2 | HP-UX 11iv2 | PA-RISC:
  

bash-4.0$ cc +DD32 -o xxx xxx.c 
Error: Demo mode has expired.
Contact your Hewlett-Packard sales office to order HP C Compiler

----------
keywords: buildbot
messages: 206831
nosy: skrah, trent
priority: normal
severity: normal
status: open
title: PA-RISC buildbot: compiler cannot create executables
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20051>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:42:38 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 Dec 2013 21:42:38 +0000
Subject: [issue19563] Changing barry's email  to barry@python.org
In-Reply-To: <1384283767.67.0.793092256619.issue19563@psf.upfronthosting.co.za>
Message-ID: <1387748558.03.0.0775425982553.issue19563@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Thanks for the patch!  I don't care if the old email address is retained in the test data (maybe it's even a good thing those point to nonexistent addresses :).  Definitely change the one in pygettext.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19563>
_______________________________________

From report at bugs.python.org  Sun Dec 22 22:55:19 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 22 Dec 2013 21:55:19 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387749319.12.0.0987048122106.issue19999@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I think the minimum bound for dt could stand to be relaxed very slightly, here's some results from my 64-bit Win7 box running 32-bit Python:

3.4.0b1 (default:eae6966d9734+, Dec 21 2013, 15:47:14) [MSC v.1600 32 bit (Intel)]
sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1')
Running:
import time
import sys
print(sys.version)
print(sys.getwindowsversion())

with open(__file__) as file:
    print('Running:')
    print(file.read())

for i in range(10):
    # copied from test_monotonic, with regular assert and added prints
    t1 = time.monotonic()
    time.sleep(0.5)
    t2 = time.monotonic()
    dt = t2 - t1
    assert t2 > t1
    print(i, t1, t2, dt, sep='\t')
    print('  assertion', 'passed' if 0.5 <= dt <= 1.0 else 'failed')

0	243323.54200000002	243324.041	0.4989999999816064
  assertion failed
1	243324.041	243324.54	0.4990000000107102
  assertion failed
2	243324.54	243325.03900000002	0.4990000000107102
  assertion failed
3	243325.03900000002	243325.53900000002	0.5
  assertion passed
4	243325.53900000002	243326.038	0.4989999999816064
  assertion failed
5	243326.038	243326.537	0.4990000000107102
  assertion failed
6	243326.537	243327.036	0.4989999999816064
  assertion failed
7	243327.036	243327.535	0.4990000000107102
  assertion failed
8	243327.535	243328.035	0.5
  assertion passed
9	243328.035	243328.534	0.4990000000107102
  assertion failed


I suspect there's some rounding going on somewhere, making dt usually about 0.499, not 0.5.  Relaxing the condition to '0.498 < dt < 1.0' should be adequate, since I don't think a thousandth of a second only part of the time is enough to say there's a behavior issue.

I haven't seen this fail on any buildbots, but I suspect most of them are just loaded a bit heavier than my laptop is when I see this.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Sun Dec 22 23:26:14 2013
From: report at bugs.python.org (Julian Gindi)
Date: Sun, 22 Dec 2013 22:26:14 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1387751174.5.0.403839020032.issue18983@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Just wanted to check in and see if the documentation change I made is sufficient. I tried to copy the other entries for the command line arguments. Let me know if I can improve it in any way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec 23 00:29:59 2013
From: report at bugs.python.org (VeloxAmbitum)
Date: Sun, 22 Dec 2013 23:29:59 +0000
Subject: [issue20052] input() crashes in 2.7.6
Message-ID: <1387754999.65.0.50719623287.issue20052@psf.upfronthosting.co.za>


New submission from VeloxAmbitum:

Using input(string) to read a number crashes whenever the number is "0*8*" or "0*9*" where * can be any number (i.e., "09", "08", and "0102393" all cause the code to crash).

Crash occurs on Windows 7 x64 running 32 bit Python version 2.7.6 as a Syntax Error:

----------------------------------------------------
Enter a number
>01239123
Traceback (most recent call last):
  File "python2.7.6 bug", line 6, in <module>
    bug()
  File "python2.7.6 bug", line 2, in bug
    number = input("Enter a number\n>");
  File "<string>", line 1
    01239123
           ^
SyntaxError: invalid token

----------------------------------------------------

Can be reproduced from:


def bug():
	number = input("Enter a number\n>");

while True:
	print("0*8* or 0*9* causes bug to appear (* is wildcard):\n");
	bug()

----------
components: Windows
files: python2.7.6 bug.py
messages: 206835
nosy: VeloxAmbitum
priority: normal
severity: normal
status: open
title: input() crashes in 2.7.6
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file33255/python2.7.6 bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20052>
_______________________________________

From report at bugs.python.org  Mon Dec 23 00:35:19 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 22 Dec 2013 23:35:19 +0000
Subject: [issue20052] input() crashes in 2.7.6
In-Reply-To: <1387754999.65.0.50719623287.issue20052@psf.upfronthosting.co.za>
Message-ID: <1387755319.35.0.0285815752011.issue20052@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It's nota bug, it's a feature. Python 2.x interprets numers with a 0 prefix as octal numbers. '8' and '9' are no valid tokens in octal notation.

>>> 010
8
>>> 10
10


http://docs.python.org/2.7/reference/lexical_analysis.html#numeric-literals

----------
nosy: +christian.heimes
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20052>
_______________________________________

From report at bugs.python.org  Mon Dec 23 01:28:00 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 00:28:00 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1387737903.73.0.797522660355.issue19927@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fji4zxBPB2SkVn9cXAjGMReGL3ZZyg8dtwgcafdjxe7Q@mail.gmail.com>


Nick Coghlan added the comment:

Yes, I think it will just make the third party idiom for testing that the
right module was imported to be to check spec.origin rather than comparing
specs directly. It's a nice-to-have, rather than something essential that
justifies breaking feature freeze.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Mon Dec 23 01:29:37 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 00:29:37 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <CADiSq7fji4zxBPB2SkVn9cXAjGMReGL3ZZyg8dtwgcafdjxe7Q@mail.gmail.com>
Message-ID: <CADiSq7fsKtodMvN1Na7Tkb+g-8Y6+BirfiprLScadxzjxziEPA@mail.gmail.com>


Nick Coghlan added the comment:

That is, I think the answer to both your questions is actually "Yes, but it
doesn't really matter due to the obscurity of the use case".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Mon Dec 23 02:46:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Dec 2013 01:46:08 +0000
Subject: [issue19563] Changing barry's email  to barry@python.org
In-Reply-To: <1384283767.67.0.793092256619.issue19563@psf.upfronthosting.co.za>
Message-ID: <3dnk1C0fYPzQvN@mail.python.org>


Roundup Robot added the comment:

New changeset f07689845f55 by Benjamin Peterson in branch '2.7':
update Barry's email (closes #19563)
http://hg.python.org/cpython/rev/f07689845f55

New changeset 9529c6c993fe by Benjamin Peterson in branch '3.3':
update Barry's email (#19563)
http://hg.python.org/cpython/rev/9529c6c993fe

New changeset a3b61c770b40 by Benjamin Peterson in branch 'default':
merge 3.3 (#19563)
http://hg.python.org/cpython/rev/a3b61c770b40

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19563>
_______________________________________

From report at bugs.python.org  Mon Dec 23 03:31:31 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 23 Dec 2013 02:31:31 +0000
Subject: [issue19422] Neither DTLS nor error for SSLSocket.sendto() of UDP
 socket
In-Reply-To: <1382965011.03.0.394041339056.issue19422@psf.upfronthosting.co.za>
Message-ID: <1387765891.92.0.483964963625.issue19422@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Thanks, Antoine, for the review! Attached the patch to address Antoine's concern.

----------
Added file: http://bugs.python.org/file33256/raises_error_on_wrap_socket_with_sock_dgram_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19422>
_______________________________________

From report at bugs.python.org  Mon Dec 23 06:33:49 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 23 Dec 2013 05:33:49 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387776829.03.0.763705023449.issue19999@psf.upfronthosting.co.za>


Tim Peters added the comment:

@Zach, "it would be nice" to know more about this.  I tried your little program on a desktop box, 32-bit Windows Vista, Python 3.3.2, but I boosted the loop count to 10,000.  So it ran well over an hour, with a wide variety of other loads (from 0 to 4 (of 4) cores busy).  `dt` was never less than 0.5.  It was exactly 0.5 9,997(!) times, and a little larger than 0.5 the remaining 3 times.  Yes, I was surprised too ;-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:16:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Dec 2013 06:16:26 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <3dnr160bwFz7Ljh@mail.python.org>


Roundup Robot added the comment:

New changeset 7a5a4d7c564d by Nick Coghlan in branch 'default':
Close #19734: ignore pip env vars in ensurepip
http://hg.python.org/cpython/rev/7a5a4d7c564d

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:41:08 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 06:41:08 +0000
Subject: [issue20053] venv and ensurepip are affected by default pip config
 file
Message-ID: <1387780868.34.0.410698465934.issue20053@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In resolving issue 19734, I realised venv and ensurepip are actually in a similar situation with respect to the default pip configuration file as they were with respect to environment variables: those settings are unlikely to be appropriate for ensurepip, but pip will still pay attention to them during the bootstrapping process.

However, it's a bit trickier to test, since PIP_CONFIG_FILE will be ignored (due to the resolution of issue 19734).

The approach I will run with (if nobody has any better suggestions):

- create a temporary directory
- set os.environ["HOME"] to point to that directory
- create a platform appropriate file (pip\pip.ini on Windows, .pip/pip.conf elsewhere) containing the settings:

    [global]
    no-install=1

That should cause the test_venv tests to fail, just as setting PIP_NO_INSTALL in the environment caused them to fail as a test for the issue 19734 resolution.

In terms of forcing pip to *ignore* the global config file, the best option I have found is setting PIP_CONFIG_FILE=/dev/null (I believe the Windows equivalent would be PIP_CONFIG_FILE=NUL). The fact the file exists means pip uses it without falling back to the default file location, while the fact it is always read as empty means it has no effect on pip's operation.

I'm open to better suggestions on how to do that, but it seems like the best available option without an "isolated mode" equivalent in pip.

----------
assignee: ncoghlan
messages: 206843
nosy: dstufft, ncoghlan, pmoore
priority: normal
severity: normal
status: open
title: venv and ensurepip are affected by default pip config file
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20053>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:42:04 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 06:42:04 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1387780924.83.0.613426558846.issue19734@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 20053 covers a related issue with ensurepip and venv being affected by the user's default pip config file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:43:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 06:43:11 +0000
Subject: [issue19347] PEP 453 implementation tracking issue
In-Reply-To: <1382442514.8.0.354499850572.issue19347@psf.upfronthosting.co.za>
Message-ID: <1387780991.5.0.753403126038.issue19347@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue 20053 covers the fact that the default pip config file affects ensurepip and venv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19347>
_______________________________________

From report at bugs.python.org  Mon Dec 23 07:49:49 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 06:49:49 +0000
Subject: [issue20053] venv and ensurepip are affected by default pip config
 file
In-Reply-To: <1387780868.34.0.410698465934.issue20053@psf.upfronthosting.co.za>
Message-ID: <1387781389.11.0.122482342536.issue20053@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

pip side counterpart, suggesting an explicit "isolated mode" option: https://github.com/pypa/pip/issues/1397

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20053>
_______________________________________

From report at bugs.python.org  Mon Dec 23 08:04:34 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 07:04:34 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1387782274.02.0.165563564458.issue19734@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The PIP_REQUIRES_VIRTUALENV buildbot still failed:

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3495/steps/test/logs/stdio

This suggests both that the setting didn't get cleared as expected *and* that pip 1.5rc2 still failed to detect the pyvenv created virtual environment.

----------
resolution: fixed -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Mon Dec 23 08:40:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Dec 2013 07:40:16 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <3dnssq5P2Qz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 98d8bf13a32c by Nick Coghlan in branch 'default':
Issue #19734: ignore pip env vars in ensurepip._uninstall
http://hg.python.org/cpython/rev/98d8bf13a32c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Mon Dec 23 08:42:13 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Dec 2013 07:42:13 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <3dnsw50hXHz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 3b3d1c312042 by Nick Coghlan in branch 'default':
Issue #19734: add missing NEWS entry
http://hg.python.org/cpython/rev/3b3d1c312042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:10:08 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 08:10:08 +0000
Subject: [issue19734] venv and ensurepip are affected by pip environment
 variable settings
In-Reply-To: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>
Message-ID: <1387786208.4.0.559628011385.issue19734@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Buildbot is happy with that version:
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3496/steps/test/logs/stdio

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19734>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:22:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Dec 2013 08:22:12 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <3dntpC56fFz7Lld@mail.python.org>


Roundup Robot added the comment:

New changeset cd62fc2488cf by Nick Coghlan in branch 'default':
Issue #19728: fix ensurepip name clash with submodule
http://hg.python.org/cpython/rev/cd62fc2488cf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19728>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:23:24 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 08:23:24 +0000
Subject: [issue19728] PEP 453: enable pip by default in the Windows binary
 installers
In-Reply-To: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>
Message-ID: <1387787004.72.0.915824963949.issue19728@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I noticed that actually importing ensurepip._uninstall would clobber the helper function, so I renamed it and added some new tests to check the basics of the command line functionality from the main ensurepip tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19728>
_______________________________________

From report at bugs.python.org  Mon Dec 23 09:55:54 2013
From: report at bugs.python.org (yegle)
Date: Mon, 23 Dec 2013 08:55:54 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387788954.67.0.278482817924.issue19861@psf.upfronthosting.co.za>


yegle added the comment:

Hi all,

It's my first time commenting on this issue tracker so bear with me if this looks naive.

For the `plistlib` package, from Apple's own manual[1], there's actually a third JSON format.

It'll be good to indicate that `plistlib` doesn't support JSON format in the what's new page and corresponding document page.

It takes me sometime before I realize `plistlib` in Python 3.3 doesn't support the so called binary property list format. So if the JSON format won't be supported in this Python version, it'll save someone's time by just reading the manual.

[1]: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/plutil.1.html

----------
nosy: +yegle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:19:39 2013
From: report at bugs.python.org (Ralf Gommers)
Date: Mon, 23 Dec 2013 09:19:39 +0000
Subject: [issue4709] Mingw-w64 and python on windows x64
In-Reply-To: <1229849614.64.0.683517411932.issue4709@psf.upfronthosting.co.za>
Message-ID: <1387790379.16.0.0343354877191.issue4709@psf.upfronthosting.co.za>


Changes by Ralf Gommers <ralf.gommers at gmail.com>:


----------
nosy: +ralf.gommers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4709>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:41:56 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 Dec 2013 09:41:56 +0000
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1387639891.42.0.281184789192.issue16136@psf.upfronthosting.co.za>
Message-ID: <52B80563.3030308@egenix.com>


Marc-Andre Lemburg added the comment:

On 21.12.2013 16:31, Christian Heimes wrote:
> 
> All VMS code has been removed except for some code in Lib/platform.py.
> 
> MAL:
> Do you want to keep the code in the platform module?

The platform.py module is intended to be usable by several Python versions,
so I think it's better to keep the code around for a little longer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16136>
_______________________________________

From mal at egenix.com  Mon Dec 23 10:41:55 2013
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 23 Dec 2013 10:41:55 +0100
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1387639891.42.0.281184789192.issue16136@psf.upfronthosting.co.za>
References: <1387639891.42.0.281184789192.issue16136@psf.upfronthosting.co.za>
Message-ID: <52B80563.3030308@egenix.com>

On 21.12.2013 16:31, Christian Heimes wrote:
> 
> All VMS code has been removed except for some code in Lib/platform.py.
> 
> MAL:
> Do you want to keep the code in the platform module?

The platform.py module is intended to be usable by several Python versions,
so I think it's better to keep the code around for a little longer.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Mon Dec 23 10:42:31 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 Dec 2013 09:42:31 +0000
Subject: [issue16136] Removal of VMS support
In-Reply-To: <1349389263.57.0.925729224322.issue16136@psf.upfronthosting.co.za>
Message-ID: <1387791751.12.0.0765463887511.issue16136@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee: lemburg -> christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16136>
_______________________________________

From report at bugs.python.org  Mon Dec 23 10:53:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2013 09:53:20 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1387788954.67.0.278482817924.issue19861@psf.upfronthosting.co.za>
Message-ID: <3857539.FP5nrOTbfM@raxxla>


Serhiy Storchaka added the comment:

> For the `plistlib` package, from Apple's own 
manual[1], there's actually a
> third JSON format.

See *issue14455.*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Mon Dec 23 14:07:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Dec 2013 13:07:20 +0000
Subject: [issue19744] test_venv fails if SSL/TLS is not available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <3dp17C2lpbz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset f670d8db8ef3 by Nick Coghlan in branch 'default':
Issue #19744: improve ensurepip error when ssl is missing
http://hg.python.org/cpython/rev/f670d8db8ef3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19744>
_______________________________________

From report at bugs.python.org  Mon Dec 23 14:14:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 13:14:02 +0000
Subject: [issue19744] test_venv fails if SSL/TLS is not available
In-Reply-To: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>
Message-ID: <1387804442.7.0.327824766454.issue19744@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I ended up not implementing step 3 - if you don't have SSL/TLS built, and you pass with_pip to the venv module API, or use the default settings for pyvenv, you *will* get an error from ensurepip.

Instead, I just kept the test skip in test_venv. ensurepip and test_ensurepip have been updated to provide a better traceback when SSL/TLS support is missing, though.

Tim, could you poke around at the latest version in your local build and see if the new checks are triggering? (I've assumed the ssl module can't be imported if the necessary underlying bits aren't built)

----------
assignee: ncoghlan -> tim.peters
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19744>
_______________________________________

From report at bugs.python.org  Mon Dec 23 14:29:09 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 Dec 2013 13:29:09 +0000
Subject: [issue19995] hex() and %x, oct() and %o do not behave the same
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1387805349.86.0.52335575435.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thank you everyone for increasing my understanding.  :)

Terry J Reedy wrote:
--------------------
> [snip everything I now agree with, which is most of Terry's comment]

> 3. Every core usage of __int__ looks for __index__ also. Int() does not
> do this now, but '%d' does [...]
> 
> The exact details would depend on whether we want to allow (or at least
> bless) classes with __int__ and __index__ returning different ints.

I think we should state that __int__ and __index__ are expected to return the same value (if both are defined) otherwise one is on one's own (otherwise known as: if it breaks, you own all the pieces ;) .

> Given things as they are, I would simply expand the domain of %x, etc,
> to that of %d without bothering to go through a deprecation process.

This is not correct.  `hex(3.14)` raises a TypeError, and so should `'%x' % 3.14`

While Terry's option 2 would have to wait for 3.5, is there any reason why fixing the %-formating characters to use __index__ instead of __int__ can't go into 3.4?  That portion seems to be clearly a bug and not an enhancement (the enhancement portions of this ticket can be separated out into another issue).

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:23:54 2013
From: report at bugs.python.org (Sophie Chancheong)
Date: Mon, 23 Dec 2013 14:23:54 +0000
Subject: [issue20054] IDLE won't work (Mac)
Message-ID: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>


New submission from Sophie Chancheong:

I'm having trouble with running Idle on my macbook pro os x 10.9.1 . two days ago it was running with absolutely no problem and now it won't start up. I've tried uninstalling and reinstalling, and I have updated the Tkinter and Tcl/Tk etc. It appears in the dock for a second then disappears. Any help would be appreciated.

Thanks,
Sophie

----------
components: IDLE
messages: 206859
nosy: Sophie.Chancheong
priority: normal
severity: normal
status: open
title: IDLE won't work (Mac)
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:48:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 23 Dec 2013 14:48:44 +0000
Subject: [issue20055] On Windows NT 6 with administrator account,
 there are two failing tests on test_shutil.py
Message-ID: <1387810124.3.0.485695266122.issue20055@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Use administrator account and run Lib\test\test_shutil.py! You will get two failing tests.

======================================================================
FAIL: test_move_dangling_symlink (__main__.TestMove)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_shutil.py", line 60, in wrap
    return func(*args, **kwargs)
  File "Lib\test\test_shutil.py", line 1557, in test_move_dangling_symlink
    self.assertEqual(os.path.realpath(src), os.path.realpath(dst_link))
AssertionError: 'C:\\Users\\compaq\\AppData\\Local\\Temp\\tmp9kkaex06\\baz' != '
C:\\Users\\compaq\\AppData\\Local\\Temp\\tmpuuretujv\\quux'
- C:\Users\compaq\AppData\Local\Temp\tmp9kkaex06\baz
?                                       ^^^^  ------
+ C:\Users\compaq\AppData\Local\Temp\tmpuuretujv\quux
?                                       ^^^ ++++++++


======================================================================
FAIL: test_copymode_follow_symlinks (__main__.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib\test\test_shutil.py", line 298, in test_copymode_follow_symlinks
    self.assertEqual(os.stat(src).st_mode, os.stat(dst).st_mode)
AssertionError: 33206 != 33060

----------------------------------------------------------------------
Ran 85 tests in 0.872s

FAILED (failures=2, skipped=12)

Attached the patch which contains the explanation as well to fix the tests.

----------
components: Library (Lib)
files: fix_test_shutil_with_admin_on_windows.patch
keywords: patch
messages: 206860
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: On Windows NT 6 with administrator account, there are two failing tests on test_shutil.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33257/fix_test_shutil_with_admin_on_windows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20055>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:52:44 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 23 Dec 2013 14:52:44 +0000
Subject: [issue20056] Got deprecation warning when running test_shutil.py on
 Windows NT 6
Message-ID: <1387810364.09.0.723584968408.issue20056@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

You don't have to be an administrator get this deprecation warning. I am not sure whether showing the deprecation warning is intended behaviour or not.

C:\Users\vajrasky\Code\cpython>PCbuild\python.exe Lib\test\test_shutil.py
..s..........s..s....ss...s..ss.ss..ssssssss....s.ss.ss..........ss.C:\Users\vaj
rasky\Code\cpython\lib\ntpath.py:309: DeprecationWarning: The Windows bytes API
has been deprecated, use Unicode filenames instead
  st = os.lstat(path)
C:\Users\vajrasky\Code\cpython\lib\shutil.py:357: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  names = os.listdir(path)
C:\Users\vajrasky\Code\cpython\lib\shutil.py:363: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  mode = os.lstat(fullname).st_mode
C:\Users\vajrasky\Code\cpython\lib\shutil.py:370: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  os.unlink(fullname)
C:\Users\vajrasky\Code\cpython\lib\shutil.py:374: DeprecationWarning: The Window
s bytes API has been deprecated, use Unicode filenames instead
  os.rmdir(path)
.sss.............
----------------------------------------------------------------------
Ran 85 tests in 0.741s

OK (skipped=28)

----------
components: Tests
messages: 206861
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got deprecation warning when running test_shutil.py on Windows NT 6
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20056>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:53:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Dec 2013 14:53:03 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387810383.7.0.409603439821.issue19861@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unless I missed something, the changes to plistlib didn't make the Beta cutoff for 3.4, so there's nothing to be done for whatsnew with regard to it.  If the current documentation needs clarification, please open a new issue for that topic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:53:06 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Dec 2013 14:53:06 +0000
Subject: [issue20055] On Windows NT 6 with administrator account,
 there are two failing tests on test_shutil.py
In-Reply-To: <1387810124.3.0.485695266122.issue20055@psf.upfronthosting.co.za>
Message-ID: <1387810386.31.0.837525788941.issue20055@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +hynek, tarek
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20055>
_______________________________________

From report at bugs.python.org  Mon Dec 23 15:57:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Dec 2013 14:57:27 +0000
Subject: [issue19861] Update What's New for Python 3.4
In-Reply-To: <1385986982.03.0.371652275474.issue19861@psf.upfronthosting.co.za>
Message-ID: <1387810647.73.0.769182590037.issue19861@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, looks like I did miss something.  I'll have to sort out what actually changed, since issue 14455 is still open.  I'll have to think about whether or not it is appropriate to discuss something that *hasn't* been added yet in whatsnew...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19861>
_______________________________________

From report at bugs.python.org  Mon Dec 23 16:02:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Dec 2013 15:02:34 +0000
Subject: [issue20053] venv and ensurepip are affected by default pip config
 file
In-Reply-To: <1387780868.34.0.410698465934.issue20053@psf.upfronthosting.co.za>
Message-ID: <1387810954.93.0.119881236834.issue20053@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't know anything about pip configuration or the tests, but perhaps you want to use something like: 

'PIP_CONFIG_FILE={}'.format(os.devnull)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20053>
_______________________________________

From report at bugs.python.org  Mon Dec 23 16:51:06 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 23 Dec 2013 15:51:06 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387813866.74.0.607496988007.issue19999@psf.upfronthosting.co.za>


Zachary Ware added the comment:

That's weird.  I ran the same test on the same computer with an installed 64-bit 3.3.2, and got the same results (70+% failure).  I just ran the same test on a different computer (32-bit Windows 7), and also got the same results with both 3.4.0b1+ and 3.3.2 (installed).

FTR:
>>> time.get_clock_info('monotonic')
namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015600099999999999)

I believe it's the same for all four Pythons tested.

Shall I open a new issue for this, or is it related enough to stay here? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 23 16:57:00 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 23 Dec 2013 15:57:00 +0000
Subject: [issue20055] On Windows NT 6 with administrator account,
 there are two failing tests on test_shutil.py
In-Reply-To: <1387810124.3.0.485695266122.issue20055@psf.upfronthosting.co.za>
Message-ID: <1387814220.72.0.867543367986.issue20055@psf.upfronthosting.co.za>


Zachary Ware added the comment:

See also issues #9949 and #15411.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20055>
_______________________________________

From report at bugs.python.org  Mon Dec 23 17:35:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Dec 2013 16:35:01 +0000
Subject: [issue20053] venv and ensurepip are affected by default pip config
 file
In-Reply-To: <1387780868.34.0.410698465934.issue20053@psf.upfronthosting.co.za>
Message-ID: <1387816501.44.0.913774877049.issue20053@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Oh, I forgot about os.devnull.

ensurepip.bootstrap mutates the environment of the current process (hence the recommendation to use the CLI instead), so yes, doing "os.environ['PIP_CONFIG_FILE'] = os.devnull" before importing pip should do the trick.

And then generate a "no-install=true" config with HOME in test_venv to make sure it is properly ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20053>
_______________________________________

From report at bugs.python.org  Mon Dec 23 17:57:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2013 16:57:26 +0000
Subject: [issue20033] Fix makelocalealias.py for Python 3
In-Reply-To: <1387537501.53.0.333984460427.issue20033@psf.upfronthosting.co.za>
Message-ID: <1387817846.44.0.813553215811.issue20033@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/issue20033>
_______________________________________

From report at bugs.python.org  Mon Dec 23 17:59:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2013 16:59:06 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1387817946.84.0.0342794383898.issue19020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If there are no objections I'll commit these patches tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Mon Dec 23 18:04:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Dec 2013 17:04:49 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1387818289.41.0.981736312224.issue18983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Mon Dec 23 19:17:48 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 23 Dec 2013 18:17:48 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387822668.29.0.83777920319.issue19999@psf.upfronthosting.co.za>


Tim Peters added the comment:

Hmm.  One obvious difference on my box:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32
>>> time.get_clock_info('monotonic')
namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015625)

So the "resolution" here is exactly 1/64.  If that's truly the resolution, then all the results I'll see are exactly representable as Python floats.

The "resolution" you see (0.015600099999999999) looks bizarre.  Not because of the trailing nines, but because 0.0156001 doesn't appear to have any natural hardware or software meaning in decimal or binary.

That said, I see we get the resolution from GetSystemTimeAdjustment.  I don't understand the Windows time functions, but also don't see anything in the MSDN docs to suggest that the results from GetSystemTimeAdjustment "should have" anything to do with the resolution of GetTickCount64.  But maybe they do - LOL ;-)

One other point:  we have lots of code of the form:

        info->resolution = timeIncrement * 1e-7;

That is, we multiply some integer type by a double _negative_ power of 10.  All such code is needlessly inaccurate:  no negative power of 10 is exactly representable as a double, so we suffer a rounding error in representing 1e-7, and then another rounding error from the multiplication.  It's trivial to reduce the grand total to one rounding error instead, by rewriting as:

        info->resolution = timeIncrement / 1e7;

But these rounding errors are too tiny to account for the difference between, e.g., 0.4990000000107102 and 0.5.

I don't conclude that we don't know what we're doing, but I bet we don't really understand what Windows is doing ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 23 22:05:19 2013
From: report at bugs.python.org (Brett Tiplitz)
Date: Mon, 23 Dec 2013 21:05:19 +0000
Subject: [issue20057] wrong behavior with fork and mmap
Message-ID: <1387832719.01.0.39752700346.issue20057@psf.upfronthosting.co.za>


New submission from Brett Tiplitz:

When running the example mmap library (with a slight modification, plus I did not handle all the changes for the 3.3 string handling as the example posted does not work with 3.x) 

When looking at the subprocess, the spawned process will have all the mmap'd file descriptors open.  The spawned process has the responsibility of closing any FD's that are in use.  However, since the shared memory segment get's closed and the program has no knowledge of private FD's, the mmap's private FD becomes a leak in the FD table.  It seems python should set the close-on-exec attribute on the dup'd FD that it maintains.  Examples of fixing this issue are found on http://stackoverflow.com/questions/1643304/how-to-set-close-on-exec-by-default
import mmap,os

# write a simple example file
with open("hello.txt", "wb") as f:
    f.write(bytes("Hello Python!\n", 'UTF-8'))

with open("hello.txt", "r+b") as f:
    # memory-map the file, size 0 means whole file
    os.system("/bin/ls -l /proc/"+str(os.getpid())+"/fd")

    mm = mmap.mmap(f.fileno(), 0)
    os.system("/bin/ls -l /proc/"+str(os.getpid())+"/fd")
    os.system("/bin/ls -l /proc/self/fd")

    # read content via standard file methods
    t1 = mm.readline() # used to print out
  # prints "Hello Python!"
    # read content via slice notation
    t2=mm[:5]
#    print mm[:5]  # prints "Hello"
    # update content using slice notation;
    # note that new content must have same size
    mm[6:] = bytes(" world!\n", 'UTF-8')
    # ... and read again using standard file methods
    mm.seek(0)
    t3=mm.readline()
 #   print mm.readline()  # prints "Hello  world!"
    # close the map
    mm.close()
~

----------
components: Library (Lib)
messages: 206871
nosy: btiplitz
priority: normal
severity: normal
status: open
title: wrong behavior with fork and mmap
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20057>
_______________________________________

From report at bugs.python.org  Mon Dec 23 22:13:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Dec 2013 21:13:23 +0000
Subject: [issue20057] wrong behavior with fork and mmap
In-Reply-To: <1387832719.01.0.39752700346.issue20057@psf.upfronthosting.co.za>
Message-ID: <1387833203.92.0.6615386329.issue20057@psf.upfronthosting.co.za>


R. David Murray added the comment:

It seems very likely that this is addressed by PEP 446.  Since that is not a behavior change that can be backported, I think this issue should probably be closed as out of date.

----------
nosy: +haypo, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20057>
_______________________________________

From report at bugs.python.org  Mon Dec 23 22:28:18 2013
From: report at bugs.python.org (Julian Gindi)
Date: Mon, 23 Dec 2013 21:28:18 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1387834098.91.0.800048270663.issue19683@psf.upfronthosting.co.za>


Julian Gindi added the comment:

So, it seems that there are many seemingly redundant tests and many tests whose intentions are unclear. I think this might be better suited for someone who has more experience with the xml minidom module. I have uploaded the work I have done but it is not complete.

----------
Added file: http://bugs.python.org/file33258/issue19683.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Mon Dec 23 22:32:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Dec 2013 21:32:43 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387822668.29.0.83777920319.issue19999@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbv68rjV1t_XM-DZ+zSoccN+sVxsP3PytyiHRgQXezuNQ@mail.gmail.com>


STINNER Victor added the comment:

For more info on time, you can refer to the PEP 418.

I may be interesting to add "sleep" to time.get_clock_info(). time.sleep()
uses WaitForSingleObject() on windows. It may use internally a different
clock with a different resolution than time.monoyonic (GetTickCount). The
PEP says "WaitForSingleObject(): use the same timer than GetTickCount()
with the same precision."

I don't think that it's very useful to investigate the rounding issue on
Windows. The resolution of Windows clocks is very coarse (15 ms, 10^-2)
compared to Unix clocks (usually a few nanoseconds, 10^-9)... I changed
recently the unit test to check if a sleep of 0.5 seconds gives a time
delta of at least 0.5 seconds. The minimum delta can be set to 0.45 sec
with a comment refering to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Mon Dec 23 22:34:39 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 23 Dec 2013 21:34:39 +0000
Subject: [issue19979] Missing nested scope vars in class scope (bis)
In-Reply-To: <1386970277.4.0.799872209267.issue19979@psf.upfronthosting.co.za>
Message-ID: <1387834479.2.0.238432963056.issue19979@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As near as I can tell, "class A: n = n" currently works the same at module and nested scope, the latter with or without nonlocal n.

>>> class A: n=n
[...]
NameError: name 'n' is not defined

>>> def f():
	class A: n=n
	
>>> f()
[...]
NameError: name 'n' is not defined

>>> def f(n):
	class A: n=n
	
>>> f(2)
[...]
NameError: name 'n' is not defined

Repeat after 'n=1' at module scope and the NameErrors disappear. It appears that you are asking that the class statement be made to act differently when nested instead of the same. This would break code that depends on the current behavior. This would need discussion on python-ideas and pydev lists.

----------
nosy: +terry.reedy
stage:  -> test needed
type:  -> enhancement
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19979>
_______________________________________

From report at bugs.python.org  Mon Dec 23 22:37:33 2013
From: report at bugs.python.org (Brett Tiplitz)
Date: Mon, 23 Dec 2013 21:37:33 +0000
Subject: [issue20057] wrong behavior with fork and mmap
In-Reply-To: <1387832719.01.0.39752700346.issue20057@psf.upfronthosting.co.za>
Message-ID: <1387834653.91.0.826582135999.issue20057@psf.upfronthosting.co.za>


Brett Tiplitz added the comment:

Changing the code to 
    subprocess.call(["/bin/ls", "-l", "/proc/self/fd"])
and running this on Python 3.3 does show this as being resolved by the broader fix implemented in PEP 446.  It does seem bad that the os.system call remains in place with bad behavior as I know it's widely used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20057>
_______________________________________

From report at bugs.python.org  Mon Dec 23 23:04:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Dec 2013 22:04:15 +0000
Subject: [issue20057] wrong behavior with fork and mmap
In-Reply-To: <1387833203.92.0.6615386329.issue20057@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbKLtUZoTa9PGwPavy3sKbk4y8SKF-W6NHE=5DEc_+biQ@mail.gmail.com>


STINNER Victor added the comment:

This issue is not specific to mmap. Many other functions and libraries may
use private inheritable file descriptors. Python 3.4 does not fix the issue
for third party libraries.

os.system() must be avoided, use subprocess.call() instead. It avoids an
useless shell process and closes all fds by default.

Is it a documentation issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20057>
_______________________________________

From report at bugs.python.org  Mon Dec 23 23:10:48 2013
From: report at bugs.python.org (Brett Tiplitz)
Date: Mon, 23 Dec 2013 22:10:48 +0000
Subject: [issue20057] wrong behavior with fork and mmap
In-Reply-To: <1387832719.01.0.39752700346.issue20057@psf.upfronthosting.co.za>
Message-ID: <1387836648.36.0.452832200707.issue20057@psf.upfronthosting.co.za>


Brett Tiplitz added the comment:

Man page currently says as follows: (this does not says it's deprecated or that files have to be closed on exec)...  So I'd think some more comments would help. And as mentioned, which a user can close his own fd's, the mmap call creates a special problem since the user can't work around the issue cleanly though fixed in the subprocess calls.


s.system(command)

    Execute the command (a string) in a subshell. This is implemented by calling the Standard C function system(), and has the same limitations. Changes to sys.stdin, etc. are not reflected in the environment of the executed command.

    On Unix, the return value is the exit status of the process encoded in the format specified for wait(). Note that POSIX does not specify the meaning of the return value of the C system() function, so the return value of the Python function is system-dependent.

    On Windows, the return value is that returned by the system shell after running command, given by the Windows environment variable COMSPEC: on command.com systems (Windows 95, 98 and ME) this is always 0; on cmd.exe systems (Windows NT, 2000 and XP) this is the exit status of the command run; on systems using a non-native shell, consult your shell documentation.

    The subprocess module provides more powerful facilities for spawning new processes and retrieving their results; using that module is preferable to using this function. See the Replacing Older Functions with the subprocess Module section in the subprocess documentation for some helpful recipes.

    Availability: Unix, Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20057>
_______________________________________

From report at bugs.python.org  Mon Dec 23 23:28:33 2013
From: report at bugs.python.org (Steven Barker)
Date: Mon, 23 Dec 2013 22:28:33 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
Message-ID: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>


New submission from Steven Barker:

Pasting multiple lines of input and then pressing Enter when IDLE is waiting to read a single line (such as when input() or sys.stdin.readline() have been called) will result is a multi-line string being given as the input, rather than a single line.

This may be most easily understood by looking at an example. Run this code in IDLE (either by typing it in the shell, or from a file with F5):

    s = "X"
    while s:
        s = input()
        print(repr(s))

First, try typing in several lines. Each will be printed separately, with no newlines inside the strings (since input() strips a trailing newline).

    foo
    'foo'
    bar
    'bar'
    baz
    'baz'

Next, copy several lines of text from somewhere. It doesn't matter what the lines' contents are. Here I grabbed a list of Python version numbers, as I was on the download page after grabbing 3.4.0b1 for testing this bug:

    3.1.5
    3.0.1
    2.7.6
    2.6.9
    2.5.6
    2.4.6
    2.3.7
    2.2.3 <all the preceding lines were pasted in one go, followed by enter pressed here>
    '3.1.5\n3.0.1\n2.7.6\n2.6.9\n2.5.6\n2.4.6\n2.3.7\n2.2.3'

This behavior is different than what the Python interpreter does in a regular console shell. When running in cmd.exe on Windows, Python treats a multi-line paste just like typed input:

    3.1.5
    '3.1.5'
    3.0.1
    '3.0.1'
    2.7.6
    '2.7.6'
    2.6.9
    '2.6.9'
    2.5.6
    '2.5.6'
    2.4.6
    '2.4.6'
    2.3.7
    '2.3.7'
    2.2.3 <enter typed here>
    '2.2.3'

I expect the same behavior will be common in other kinds of terminals on other platforms.

This issue makes testing certain kinds of programs very frustrating. If your program needs to read certain text from STDIN, and you want to paste that text in quickly, you need to update your code with special logic just for use in IDLE's console. As an example of the kind of pain you may experience, try copying and pasting a block of text with a blank line into the input loop above. On a regular console session it will exit the loop after the blank line. In IDLE, it will keep running.

I've traced the source of this issue through IDLE's sys.stdin file object and an RPC call, and found it probably is located in the idlelib.PyShell.PyShell.readline method (or the surrounding code). This grabs a string from the Text object in the shell window and returns it to the Python code running in the subprocess.

Probably it should have some extra steps added to check if it got multiple lines. If so, it should split the string on newlines and return just one line of text for each readline call. I'm not sure exactly what should be done with the rest of the lines, but perhaps they could be queued up (or somehow "put back" by moving the markers in the Text object) so later lines would be grabbed by later input requests.

Or alternatively, maybe the event where the multi-line paste arrives should be handled differently, as several single-line input events, rather than a single multiple-line one.

----------
components: IDLE
messages: 206879
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: IDLE's shell returns a multiple-line string to input() or readline() when multiple lines of text are pasted by the user
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20058>
_______________________________________

From report at bugs.python.org  Mon Dec 23 23:50:40 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 23 Dec 2013 22:50:40 +0000
Subject: [issue20054] IDLE won't work (Mac)
In-Reply-To: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>
Message-ID: <1387839040.67.0.24393217311.issue20054@psf.upfronthosting.co.za>


Ned Deily added the comment:

What happens if you try to start IDLE from a terminal session by typing:

/usr/local/bin/idle3.3

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Tue Dec 24 00:51:50 2013
From: report at bugs.python.org (Chad Birch)
Date: Mon, 23 Dec 2013 23:51:50 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
Message-ID: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>


New submission from Chad Birch:

I'm not sure if this is something that needs adjustment, but it seems somewhat inconsistent to me.

After using urlparse() on various urls with invalid port values, trying to access .port on the result will raise a ValueError. This case includes urls such as:

"http://www.example.com:asdf"

"http://www.example.com:1.5"

"http://www.example.com:"

However, as of May 24 2012 (http://hg.python.org/cpython/diff/d769e64aed79/Lib/urllib/parse.py), if the invalid port value is an integer, accessing .port will result in None. So this includes urls such as:

"http://www.example.com:66000"

"http://www.example.com:-1"

Should these two cases be made consistent, so that either .port is always None or always results in a ValueError if the port section of the url is invalid? I'd be happy to write a patch for it if it's wanted, but I thought I'd check first (and see which of the two options would be correct, if so).

----------
components: Library (Lib)
messages: 206881
nosy: chad.birch
priority: normal
severity: normal
status: open
title: Inconsistent urlparse/urllib.parse handling of invalid port values?
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20059>
_______________________________________

From report at bugs.python.org  Tue Dec 24 01:08:05 2013
From: report at bugs.python.org (Sophie Chancheong)
Date: Tue, 24 Dec 2013 00:08:05 +0000
Subject: [issue20054] IDLE won't work (Mac)
In-Reply-To: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>
Message-ID: <1387843685.39.0.358056479745.issue20054@psf.upfronthosting.co.za>


Sophie Chancheong added the comment:

when i try to start it from terminal i get:

sophiesmac:~ Sophie$ /usr/local/bin/idle3.3
Traceback (most recent call last):
  File "/usr/local/bin/idle3.3", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/idlelib/PyShell.py", line 1572, in main
    shell.interp.runcommand(''.join(("print('", tkversionwarning, "')")))
AttributeError: 'NoneType' object has no attribute 'interp'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Tue Dec 24 02:37:22 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 24 Dec 2013 01:37:22 +0000
Subject: [issue19927] Path-based loaders lack a meaningful __eq__()
 implementation.
In-Reply-To: <1386479617.91.0.98675544786.issue19927@psf.upfronthosting.co.za>
Message-ID: <1387849042.54.0.0642535914394.issue19927@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm fine with this.  Thanks, Larry, for your attentiveness and diligence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19927>
_______________________________________

From report at bugs.python.org  Tue Dec 24 03:44:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 02:44:06 +0000
Subject: [issue11797] 2to3 does not correct "reload"
In-Reply-To: <1302191844.85.0.922084217825.issue11797@psf.upfronthosting.co.za>
Message-ID: <1387853046.6.0.515794878669.issue11797@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since this patch was applied, imp.reload has been deprecated in favor of importlib.reload.  I don't know how we handle differences between python3 versions...is there anything that should be done here, or do we just use imp.reload even though it is deprecated in 3.4?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11797>
_______________________________________

From report at bugs.python.org  Tue Dec 24 04:10:07 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 24 Dec 2013 03:10:07 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387854607.47.0.107652282528.issue19999@psf.upfronthosting.co.za>


Tim Peters added the comment:

@haypo, I've read the PEP and it has great ideas.  What I'm wondering is whether they've been implemented "correctly" in the relevant cases on Windows here.  That Zach see a resolution of 0.0156001 on Windows isn't plausibly a question of rounding errors:  that value appears to be insane.  Yes, it's vaguely close to the 0.015625 I see, but the value I see _is_ sane (being exactly 1/64) - but 0.0156001 isn't close enough to 0.015625 for "rounding errors" to be at all a plausible explanation for why it's so strange.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Tue Dec 24 04:26:39 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 24 Dec 2013 03:26:39 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387855599.09.0.277801271444.issue19999@psf.upfronthosting.co.za>


Tim Peters added the comment:

FYI, this person seems to have made a career ;-) of making sense of the Windows time functions:

http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly

and their site:

http://www.windowstimestamp.com/description

Bottom line is that it's messy as everything else on Windows :-(  They claim, among other things:

- "GetSystemTimeAdjustment is not the function to look at."

- The undocumented NtQueryTimerResolution() is the function to look at.

- "Time Adjustment: 0.0156001 clearly identifies windows VISTA or higher with HPET and/or constant/invariant TSC on your system."

Screw it - I'm gonna go shovel more snow ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Tue Dec 24 07:26:50 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Dec 2013 06:26:50 +0000
Subject: [issue20054] IDLE won't work (Mac)
In-Reply-To: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>
Message-ID: <1387866410.3.0.548156033726.issue20054@psf.upfronthosting.co.za>


Ned Deily added the comment:

This problem was reported and fixed in Issue18270 which will be in the next set of Python maintenance releases.  As explained there, what is causing this is that the Python 3.3 tkinter you are using is trying to use the known buggy system Tk 8.5 shipped with OS X.  If you are using a python.org 3.3, you can avoid the problem by installing a more up-to-date version of Tcl/Tk 8.5, such as the current ActiveTcl 8.5.15.0.  See http://www.python.org/download/mac/tcltk/

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> IDLE on OS X fails with Attribute Error if no initial shell and Tk out-of-date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Tue Dec 24 08:03:18 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Dec 2013 07:03:18 +0000
Subject: [issue20033] Fix makelocalealias.py for Python 3
In-Reply-To: <1387537501.53.0.333984460427.issue20033@psf.upfronthosting.co.za>
Message-ID: <3dpT0h6tD8z7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 22c59ddba494 by Serhiy Storchaka in branch '3.3':
Issue #20033: makelocalealias.py now works with non-ASCII locales and produces
http://hg.python.org/cpython/rev/22c59ddba494

New changeset 1287c570176b by Serhiy Storchaka in branch 'default':
Issue #20033: makelocalealias.py now works with non-ASCII locales and produces
http://hg.python.org/cpython/rev/1287c570176b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20033>
_______________________________________

From report at bugs.python.org  Tue Dec 24 08:05:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Dec 2013 07:05:06 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
In-Reply-To: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>
Message-ID: <1387868706.11.0.389720987362.issue20058@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +kbk, roger.serwy, serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20058>
_______________________________________

From report at bugs.python.org  Tue Dec 24 08:43:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Dec 2013 07:43:50 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
In-Reply-To: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>
Message-ID: <1387871030.95.0.50929058283.issue20058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is simple patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file33259/idle_readline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20058>
_______________________________________

From report at bugs.python.org  Tue Dec 24 15:08:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Dec 2013 14:08:08 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387894088.65.0.812655895608.issue19999@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> but 0.0156001 isn't close enough to 0.015625 for "rounding errors" to be at all a plausible explanation for why it's so strange.

0.0156001 is close to 0.0156, and this number cannot be representated exactly in binary:

>>> (0.0156).hex()
'0x1.ff2e48e8a71dep-7'

C code used by Python:

GetSystemTimeAdjustment(&timeAdjustment, &timeIncrement,
                        &isTimeAdjustmentDisabled);
info->resolution = timeIncrement * 1e-7;

(And yes, 0.0156001 is surprising, I also expected 1/64, 0.015625)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Tue Dec 24 15:18:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Dec 2013 14:18:26 +0000
Subject: [issue19999] test_monotonic fails on x86 OpenIndiana
In-Reply-To: <1387219618.02.0.0675755074748.issue19999@psf.upfronthosting.co.za>
Message-ID: <1387894706.31.0.787771083233.issue19999@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> "GetSystemTimeAdjustment is not the function to look at."

This sentence comes from http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly which describes the wall clock (GetSystemTimeAsFileTime), not the monotonic clock (GetTickCount[64]).

GetTickCount[64] resolution cannot be better than 1 ms because its C structure has a resolution of 1 ms...

But I don't know any other *monotonic* clock with a better resolution.

Python 3.3 provides time.perf_counter(): "clock with the highest available resolution to measure a short duration". I added this function because of Windows, to give access to QueryPerformanceCounter().

@Tim: This issue is closed. If you believe that Python time functions are buggy on windows, which is quite possible, please open a *new* issue. (This issue was specific to OpenIndiana buildbot which looks to be ill.)

The C function pygettimeofday() which is used by time.time() and time.get_clock_info() uses GetSystemTimeAsFileTime() and GetSystemTimeAdjustment(). According to the article, there is a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19999>
_______________________________________

From report at bugs.python.org  Tue Dec 24 15:29:12 2013
From: report at bugs.python.org (Mitchell Model)
Date: Tue, 24 Dec 2013 14:29:12 +0000
Subject: [issue20060] float() and int() TypeError messages differ
Message-ID: <1387895352.05.0.912673240315.issue20060@psf.upfronthosting.co.za>


New submission from Mitchell Model:

[Sorry if ctypes is wrong component -- don't know which to use.]
Given an invalid type, int()'s TypeError message includes the name of the invalid type, but float()'s doesn't. (Nor does complex()'s.) All three should give analogous error messages. int()'s version, with the name of the offending type, seems better.

----------
components: ctypes
messages: 206892
nosy: MLModel
priority: normal
severity: normal
status: open
title: float() and int() TypeError messages differ
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20060>
_______________________________________

From report at bugs.python.org  Tue Dec 24 15:46:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 14:46:57 +0000
Subject: [issue20060] float() and int() TypeError messages differ
In-Reply-To: <1387895352.05.0.912673240315.issue20060@psf.upfronthosting.co.za>
Message-ID: <1387896417.7.0.487622586675.issue20060@psf.upfronthosting.co.za>


R. David Murray added the comment:

Could you provide examples?  I'm not seeing the problem myself.

Unless you really do mean this to apply to the ctypes python module, which I don't know much about.  It sounds like you are talking about the built in types though.

----------
components: +Interpreter Core -ctypes
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20060>
_______________________________________

From report at bugs.python.org  Tue Dec 24 15:57:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 14:57:18 +0000
Subject: [issue20060] float() and int() TypeError messages differ
In-Reply-To: <1387895352.05.0.912673240315.issue20060@psf.upfronthosting.co.za>
Message-ID: <1387897038.54.0.28382706982.issue20060@psf.upfronthosting.co.za>


R. David Murray added the comment:

I take it back.  This is a duplicate of issue 17080 and has already been fixed in 3.4, which is why I didn't see the problem (I was testing in my development sandbox).

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> A better error message for float()
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20060>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:09:20 2013
From: report at bugs.python.org (Chiel ten Brinke)
Date: Tue, 24 Dec 2013 15:09:20 +0000
Subject: [issue20061] pdb through separate terminal not working properly
Message-ID: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>


New submission from Chiel ten Brinke:

There are several reasons why one would need to debug in a terminal window other than the debuggee terminal window, for instance when we have a curses application.
The pdb doesn't support a tty command like gdb, which would allow this.
Instead, it is possible to manually create a Pdb object with the stdin/stdout set to the terminal you want to use (e.g. /dev/pts/6). However, this is quite cumbersome, as command history, autocompletion etc don't work this way. Also, it seems that post mortem debugging cannot easily be done this way, like when running `python3.3 -m pdb myscript.py`. 

There should be an easy way to debug properly through a second terminal window.

----------
messages: 206895
nosy: Chiel92
priority: normal
severity: normal
status: open
title: pdb through separate terminal not working properly
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:15:16 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Dec 2013 15:15:16 +0000
Subject: [issue20041] TypeError when f_trace is None and tracing.
In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>
Message-ID: <1387898116.13.0.167173157687.issue20041@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Adding the corresponding tests.

----------
components: +2to3 (2.x to 3.x conversion tool) -Interpreter Core
Added file: http://bugs.python.org/file33260/tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20041>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:18:24 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Dec 2013 15:18:24 +0000
Subject: [issue20041] TypeError when f_trace is None and tracing.
In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>
Message-ID: <1387898304.45.0.354891100629.issue20041@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
components: +Interpreter Core -2to3 (2.x to 3.x conversion tool)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20041>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:23:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 15:23:36 +0000
Subject: [issue20062] Add section on vim to devguide
Message-ID: <1387898616.8.0.449305088689.issue20062@psf.upfronthosting.co.za>


New submission from R. David Murray:

This is a followup to issue 9893.  There should be a section on vim in the devguide just like there is currently a section on emacs.

----------
components: Devguide
messages: 206897
nosy: ezio.melotti, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Add section on vim to devguide
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20062>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:26:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 15:26:06 +0000
Subject: [issue20062] Add section on vim to devguide
In-Reply-To: <1387898616.8.0.449305088689.issue20062@psf.upfronthosting.co.za>
Message-ID: <1387898766.3.0.32297422308.issue20062@psf.upfronthosting.co.za>


R. David Murray added the comment:

The Misc/TextMate directory was also removed.  I wonder if what we really want is an 'editor support' chapter that lists best practice for any editor any committers use (and are willing to write the section for).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20062>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:33:15 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 24 Dec 2013 15:33:15 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
Message-ID: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>


New submission from Madison May:

Note item 6 of http://docs.python.org/2.7/library/stdtypes.html#mutable-sequence-types is a bit misleading.  

It states: "The pop() method is only supported by the list and array types. The optional argument i defaults to -1, so that by default the last item is removed and returned."  

However, pop() is also a method of sets, which are neither lists or arrays.

----------
assignee: docs at python
components: Documentation
messages: 206899
nosy: docs at python, madison.may
priority: normal
severity: normal
status: open
title: Docs imply that set does not support .pop() method
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Tue Dec 24 16:55:49 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 15:55:49 +0000
Subject: [issue20061] pdb through separate terminal not working properly
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1387900549.78.0.557364228178.issue20061@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds like a good idea to me, but it would be a new feature, not a bug fix.

----------
components: +Library (Lib)
nosy: +r.david.murray
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:12:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 16:12:04 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387901524.7.0.944735935518.issue20063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, set supporting it is irrelevant to that section, which is about mutable sequence types.  However, bytearray also supports pop, so I think perhaps that sentence should just be deleted.  The whole footnote is gone in the Python3. docs.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:18:43 2013
From: report at bugs.python.org (Madison May)
Date: Tue, 24 Dec 2013 16:18:43 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387901923.3.0.579391964762.issue20063@psf.upfronthosting.co.za>


Madison May added the comment:

+1 for simply deleting that bit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:21:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 16:21:04 +0000
Subject: [issue20061] pdb through separate terminal not working properly
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1387902064.49.0.819061298627.issue20061@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify: remote debugging is not a new feature, but enabling command history &c should probably be considered a new feature, and making the interface for doing all this more convenient (which would be cool) certainly would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:22:18 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 16:22:18 +0000
Subject: [issue20061] make pdb through separate terminal more convenient
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1387902138.53.0.144012229466.issue20061@psf.upfronthosting.co.za>


R. David Murray added the comment:

Changing title to reflect the fact that it is an enhancement.

----------
title: pdb through separate terminal not working properly -> make pdb through separate terminal more convenient

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:46:10 2013
From: report at bugs.python.org (Chiel ten Brinke)
Date: Tue, 24 Dec 2013 16:46:10 +0000
Subject: [issue20061] make pdb through separate terminal more convenient
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1387903570.15.0.152421908082.issue20061@psf.upfronthosting.co.za>


Chiel ten Brinke added the comment:

I called it a bug, because command history etc. works when debugging in a single terminal. It only fails when debugging remotely/in a separate terminal. But if this is not due to a improper implementation, it should indeed be an enhancement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:53:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 16:53:17 +0000
Subject: [issue20061] make pdb through separate terminal more convenient
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1387903997.3.0.702569527062.issue20061@psf.upfronthosting.co.za>


R. David Murray added the comment:

Command line history (if I understand correctly) depends on the input/output being stdin/stdout, which isn't the case when doing remote debugging using the current implementation of remote debugging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 17:54:36 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 16:54:36 +0000
Subject: [issue20061] make pdb through separate terminal more convenient
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1387904076.74.0.660840555502.issue20061@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I mean stdin/stdout of the controlling terminal of the process.  Of course, I could be completely confused :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20061>
_______________________________________

From report at bugs.python.org  Tue Dec 24 18:37:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Dec 2013 17:37:50 +0000
Subject: [issue18529] Use long dash
In-Reply-To: <1374499433.16.0.583158051605.issue18529@psf.upfronthosting.co.za>
Message-ID: <3dpl4t1LNlz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 01d2c25a6804 by R David Murray in branch 'default':
Use endash in PEP callouts.
http://hg.python.org/cpython/rev/01d2c25a6804

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18529>
_______________________________________

From report at bugs.python.org  Tue Dec 24 19:59:04 2013
From: report at bugs.python.org (Sophie Chancheong)
Date: Tue, 24 Dec 2013 18:59:04 +0000
Subject: [issue20054] IDLE won't work (Mac)
In-Reply-To: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>
Message-ID: <1387911544.95.0.765316420914.issue20054@psf.upfronthosting.co.za>


Sophie Chancheong added the comment:

i have downloaded and installed activeTcl 8.5.15.0 and that's still what it says. do you mean a new version of python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Tue Dec 24 20:39:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 19:39:20 +0000
Subject: [issue20064] PyObject_Malloc is not documented
Message-ID: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>


New submission from R. David Murray:

At least, a doc ref to :c:func:`PyObject_Malloc` does not turn into a link, and I can't find anything in the docs that it looks like it should link to.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 206910
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: PyObject_Malloc is not documented
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Tue Dec 24 20:41:01 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Tue, 24 Dec 2013 19:41:01 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <1387914061.21.0.266508082135.issue19648@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Antoine, sure! I have just signed it. Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Tue Dec 24 20:45:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Dec 2013 19:45:59 +0000
Subject: [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1387914359.4.0.360858060138.issue18688@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18688>
_______________________________________

From report at bugs.python.org  Tue Dec 24 22:14:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Dec 2013 21:14:08 +0000
Subject: [issue16832] Expose cache validity checking support in ABCMeta
In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za>
Message-ID: <3dpqtS2KYkz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset a9f73b44ea0e by R David Murray in branch 'default':
#16832: s/integer/object/ in docs/docstring, and add whatsnew entry.
http://hg.python.org/cpython/rev/a9f73b44ea0e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16832>
_______________________________________

From report at bugs.python.org  Tue Dec 24 22:15:47 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Dec 2013 21:15:47 +0000
Subject: [issue16832] Expose cache validity checking support in ABCMeta
In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za>
Message-ID: <1387919747.1.0.956532632629.issue16832@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't see that there's anything other than the doc change that needs done here, so I'm closing this.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16832>
_______________________________________

From report at bugs.python.org  Wed Dec 25 02:12:16 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 25 Dec 2013 01:12:16 +0000
Subject: [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1387933936.3.0.361574436842.issue20064@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Hi, 

I created the patch, please kindly review it, all comments are welcomed.

Thank you!

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33261/20064.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20064>
_______________________________________

From report at bugs.python.org  Wed Dec 25 02:41:41 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 25 Dec 2013 01:41:41 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387935701.21.0.307988561595.issue20063@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Here's the patch

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33262/20063.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Wed Dec 25 03:48:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Dec 2013 02:48:00 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387939680.18.0.297864461077.issue20063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, but the proposal for 2.7 is to just delete the sentence about list/array, not the whole footnote.  Unless someone can think of a mutable list type in 2.7 that does not support pop...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Wed Dec 25 04:26:56 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 25 Dec 2013 03:26:56 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1387942016.02.0.999823664119.issue20063@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Got it. Looks like I was confused by absence of this footnote in Python 3 documentation) Here's updated patch.

----------
Added file: http://bugs.python.org/file33263/20063.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Wed Dec 25 08:26:16 2013
From: report at bugs.python.org (Ned Deily)
Date: Wed, 25 Dec 2013 07:26:16 +0000
Subject: [issue20054] IDLE won't work (Mac)
In-Reply-To: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>
Message-ID: <1387956376.72.0.972593960426.issue20054@psf.upfronthosting.co.za>


Ned Deily added the comment:

I was assuming you were using a Python 3.3 from a binary installer downloaded from python.org.  Those Pythons are built to dynamically link with a compatible Tcl and Tk 8.5 frameworks in /Library/Frameworks, such as the ActiveTcl 8.5 ones, and fall back to the Apple-supplied version in /System/Library/Frameworks.  If you are using a Python 3.3 from another source or built yourself from source, it may not behave that way.

If you are using the current Python.org 3.3.3 64-bit/32-bit installer, the signature should be:

$ /usr/local/bin/python3.3 -c "import sys; print(sys.version)"
3.3.3 (v3.3.3:c3896275c0f6, Nov 16 2013, 23:39:35)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
$ /usr/local/bin/python3.3 -c "import _tkinter;print(_tkinter.__file__)"
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_tkinter.so
$ otool -L $(/usr/local/bin/python3.3 -c "import _tkinter;print(_tkinter.__file__)")
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/lib-dynload/_tkinter.so:
	/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.15)
	/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.15)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Wed Dec 25 09:46:36 2013
From: report at bugs.python.org (Igor Franchuk)
Date: Wed, 25 Dec 2013 08:46:36 +0000
Subject: [issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error:
 'CAN_RAW' undeclared (first use in this function)
Message-ID: <1387961196.27.0.560814998744.issue20065@psf.upfronthosting.co.za>


New submission from Igor Franchuk:

Missing CAN_RAW check in Python 3.3.3

Python 3.3.3 assumes that if AF_CAN is defined then CAN_RAW is defined as well.

It won't assemble with old kernels. 

Either an additional check for CAN_RAW should be applied in the configuration script or Python 3.3.3 dependence on the newest kernels should be made mandatory
(configure check). It could be back to normal if a CAN_RAW check is applied and the problematic part of code is excluded. 

Python 3.3.3 can work with sockets without full CAN support but it won't.

Environment:

System uname: Linux-2.6.33-gentoo-i686-Intel-R-_Pentium-R-_D_CPU_3.00GHz-with-gentoo-1.12.1
Timestamp of tree: Sun, 22 Dec 2013 09:30:01 +0000
ld GNU ld (GNU Binutils) 2.21
app-shells/bash:          4.2_p37
dev-lang/python:          2.4.3-r1::<unknown repository>, 2.6.8, 2.7.3-r3, 3.1.1-r1, 3.2.3-r2
dev-util/pkgconfig:       0.27.1
sys-apps/baselayout:      1.12.1::<unknown repository>
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.13::<unknown repository>, 2.69
sys-devel/automake:       1.4_p6::<unknown repository>, 1.5::<unknown repository>, 1.6.3::<unknown repository>, 1.7.9-r1::<unknown repository>, 1.8.5-r3::<unknown repository>, 1.9.6-r2::<unknown repository>, 1.10::<unknown repository>, 1.11.1, 1.13.1
sys-devel/binutils:       2.21
sys-devel/gcc:            4.1.1::<unknown repository>, 4.2.4-r1, 4.4.2
sys-devel/gcc-config:     1.4.1
sys-devel/libtool:        1.5.23b::<unknown repository>, 2.4-r1
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 2.6.21::<unknown repository> (virtual/os-headers)
sys-libs/glibc:           2.10.1-r1
Repositories: gentoo
ACCEPT_KEYWORDS="x86"
ACCEPT_LICENSE="* - at EULA"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /var/bind"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=pentium4 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -march=i686 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -march=i686 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="acl alsa arts avi berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups cxx dbus dlloader dri dvd dvdr eds emboss encode esd fam fortran gdbm gif gnutls gpm gstreamer gtk hal iconv isdnlog jpeg kde ldap libg++ mad mikmod modules mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdflib perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl svg symlink tcpd truetype truetype-fonts type1-fonts udev unicode vorbis win32codecs x86 xml xorg xv zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

----------
components: Build
files: build.log
messages: 206919
nosy: lanthruster
priority: normal
severity: normal
status: open
title: Python-3.3.3/Modules/socketmodule.c:1660:14: error: 'CAN_RAW' undeclared (first use in this function)
versions: Python 3.3
Added file: http://bugs.python.org/file33264/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20065>
_______________________________________

From report at bugs.python.org  Wed Dec 25 12:41:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 11:41:06 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
In-Reply-To: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>
Message-ID: <1387971666.8.0.12202666578.issue20058@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/issue20058>
_______________________________________

From report at bugs.python.org  Wed Dec 25 13:25:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Dec 2013 12:25:33 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
In-Reply-To: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>
Message-ID: <3dqD645mzhz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 526dcd51e425 by Serhiy Storchaka in branch '2.7':
Issue #20058: sys.stdin.readline() in IDLE now always returns only one line.
http://hg.python.org/cpython/rev/526dcd51e425

New changeset 8f75d8ddc95b by Serhiy Storchaka in branch '3.3':
Issue #20058: sys.stdin.readline() in IDLE now always returns only one line.
http://hg.python.org/cpython/rev/8f75d8ddc95b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20058>
_______________________________________

From report at bugs.python.org  Wed Dec 25 13:27:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Dec 2013 12:27:22 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
In-Reply-To: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>
Message-ID: <3dqD8B0YYzz7Ljn@mail.python.org>


Roundup Robot added the comment:

New changeset 2a4c083f8f6b by Serhiy Storchaka in branch 'default':
Issue #20058: sys.stdin.readline() in IDLE now always returns only one line.
http://hg.python.org/cpython/rev/2a4c083f8f6b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20058>
_______________________________________

From report at bugs.python.org  Wed Dec 25 13:28:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 12:28:23 +0000
Subject: [issue20058] IDLE's shell returns a multiple-line string to input()
 or readline() when multiple lines of text are pasted by the user
In-Reply-To: <1387837713.58.0.522558553698.issue20058@psf.upfronthosting.co.za>
Message-ID: <1387974503.29.0.41352935509.issue20058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed. Thank you Steven for your report.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20058>
_______________________________________

From report at bugs.python.org  Wed Dec 25 14:33:19 2013
From: report at bugs.python.org (Wolf Ihlenfeldt)
Date: Wed, 25 Dec 2013 13:33:19 +0000
Subject: [issue20066] PyStructSequence_NewType() not setting proper heap
 allocation flag?
Message-ID: <1387978399.6.0.58819819413.issue20066@psf.upfronthosting.co.za>


New submission from Wolf Ihlenfeldt:

If I am not mistaken, I think that PyStructSequence_NewType() should set the Py_TPFLAGS_HEAPTYPE flag in tp->flags (which it currently does not). The original version initially works fine, but ultimately crashes at exit time in finalization with

Fatal Python error: type_traverse() called for non-heap type 'E_FILE'

#0  0x00007ffff12913d5 in raise () from /lib64/libc.so.6
#1  0x00007ffff1292858 in abort () from /lib64/libc.so.6
#2  0x00007ffff2360484 in Py_FatalError (msg=<optimized out>) at Python/pythonrun.c:2364
#3  0x00007ffff22e5354 in type_traverse (type=0x10b47a0, visit=0x7ffff2374350 <visit_decref>, arg=0x0)
    at Objects/typeobject.c:2892
#4  0x00007ffff2374bd1 in subtract_refs (containers=0x7ffff26466c0) at Modules/gcmodule.c:386
#5  collect (n_uncollectable=<synthetic pointer>, n_collected=<synthetic pointer>, generation=2)
    at Modules/gcmodule.c:891
#6  collect_with_callback (generation=2) at Modules/gcmodule.c:1048
#7  0x00007ffff2375436 in PyGC_Collect () at Modules/gcmodule.c:1476
#8  0x00007ffff235f698 in Py_Finalize () at Python/pythonrun.c:521
#9  0x00007ffff6e70b70 in CSpythonFinalize () at nmds_python.c:44652
#10 0x0000000000407399 in main ()

Setting the flag manually after creation lets the problem disappear.

----------
messages: 206923
nosy: Wolf.Ihlenfeldt
priority: normal
severity: normal
status: open
title: PyStructSequence_NewType() not setting proper heap allocation flag?
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20066>
_______________________________________

From report at bugs.python.org  Wed Dec 25 15:43:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Dec 2013 14:43:23 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <3dqH963S2Zz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset ff70c298dd60 by Serhiy Storchaka in branch '2.7':
Issue #19020: Tkinter now uses splitlist() instead of split() in configure
http://hg.python.org/cpython/rev/ff70c298dd60

New changeset a8f5f8c44dc8 by Serhiy Storchaka in branch '3.3':
Issue #19020: Tkinter now uses splitlist() instead of split() in configure
http://hg.python.org/cpython/rev/a8f5f8c44dc8

New changeset c6ba24ffa4ba by Serhiy Storchaka in branch 'default':
Issue #19020: Tkinter now uses splitlist() instead of split() in configure
http://hg.python.org/cpython/rev/c6ba24ffa4ba

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Wed Dec 25 15:59:37 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 14:59:37 +0000
Subject: [issue19020] Regression: Windows-tkinter-idle, unicode,
 and 0xxx filename
In-Reply-To: <1379196682.03.0.147663616291.issue19020@psf.upfronthosting.co.za>
Message-ID: <1387983577.26.0.266318963201.issue19020@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> commit review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19020>
_______________________________________

From report at bugs.python.org  Wed Dec 25 16:31:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Dec 2013 15:31:07 +0000
Subject: [issue19320] Tkinter tests ran with wantobjects is false
In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za>
Message-ID: <3dqJDB42Rtz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 6fe3e855a276 by Serhiy Storchaka in branch '2.7':
Issue #19320: test_tcl no longer fails when wantobjects is false.
http://hg.python.org/cpython/rev/6fe3e855a276

New changeset 6781a03d90c1 by Serhiy Storchaka in branch '3.3':
Issue #19320: test_tcl no longer fails when wantobjects is false.
http://hg.python.org/cpython/rev/6781a03d90c1

New changeset 78fa6dc5cc21 by Serhiy Storchaka in branch 'default':
Issue #19320: test_tcl no longer fails when wantobjects is false.
http://hg.python.org/cpython/rev/78fa6dc5cc21

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19320>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:16:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 16:16:22 +0000
Subject: [issue20067] Tkinter variables no works with wantobject is false
Message-ID: <1387988182.68.0.509066568991.issue20067@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tkinter variables test fails when wantobjects is false:

======================================================================
ERROR: test_default (__main__.TestVariable)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 29, in test_default
    self.assertEqual("", v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 239, in get
    return self._tk.globalgetvar(self._name)
_tkinter.TclError: can't read "PY_VAR0": no such variable

======================================================================
ERROR: test_default (__main__.TestStringVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 79, in test_default
    self.assertEqual("", v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 291, in get
    value = self._tk.globalgetvar(self._name)
_tkinter.TclError: can't read "PY_VAR2": no such variable

======================================================================
ERROR: test_default (__main__.TestIntVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 92, in test_default
    self.assertEqual(0, v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 313, in get
    return getint(self._tk.globalgetvar(self._name))
_tkinter.TclError: can't read "PY_VAR3": no such variable

======================================================================
ERROR: test_default (__main__.TestDoubleVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 114, in test_default
    self.assertEqual(0.0, v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 332, in get
    return getdouble(self._tk.globalgetvar(self._name))
_tkinter.TclError: can't read "PY_VAR4": no such variable

======================================================================
ERROR: test_default (__main__.TestBooleanVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 352, in get
    return self._tk.getboolean(self._tk.globalgetvar(self._name))
_tkinter.TclError: can't read "PY_VAR5": no such variable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 141, in test_default
    self.assertEqual(False, v.get())
  File "/home/serhiy/py/cpython/Lib/tkinter/__init__.py", line 354, in get
    raise ValueError("invalid literal for getboolean()")
ValueError: invalid literal for getboolean()

======================================================================
FAIL: test___del__ (__main__.TestVariable)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 38, in test___del__
    self.assertFalse(self.root.call("info", "exists", "varname"))
AssertionError: '0' is not false

======================================================================
FAIL: test_dont_unset_not_existing (__main__.TestVariable)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/tkinter/test/test_tkinter/test_variables.py", line 45, in test_dont_unset_not_existing
    self.assertFalse(self.root.call("info", "exists", "varname"))
AssertionError: '0' is not false

----------------------------------------------------------------------

Here is a patch which fixes tkinter and tests.

----------
assignee: serhiy.storchaka
components: Tkinter
files: tkinter_variables_wantobjects.patch
keywords: patch
messages: 206926
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Tkinter variables no works with wantobject is false
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33265/tkinter_variables_wantobjects.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20067>
_______________________________________

From report at bugs.python.org  Wed Dec 25 17:18:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 16:18:22 +0000
Subject: [issue19320] Tkinter tests ran with wantobjects is false
In-Reply-To: <1382302056.06.0.500513298536.issue19320@psf.upfronthosting.co.za>
Message-ID: <1387988302.04.0.185014612615.issue19320@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't know why wantobjects is false on some buildbots, but at least now they should be green.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19320>
_______________________________________

From report at bugs.python.org  Wed Dec 25 20:40:11 2013
From: report at bugs.python.org (Igor Franchuk)
Date: Wed, 25 Dec 2013 19:40:11 +0000
Subject: [issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error:
 'CAN_RAW' undeclared (first use in this function)
In-Reply-To: <1387961196.27.0.560814998744.issue20065@psf.upfronthosting.co.za>
Message-ID: <1388000411.49.0.401695456428.issue20065@psf.upfronthosting.co.za>


Changes by Igor Franchuk <lanthruster at gmail.com>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20065>
_______________________________________

From report at bugs.python.org  Wed Dec 25 21:38:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Dec 2013 20:38:06 +0000
Subject: [issue19761] test_tk fails on OS X with multiple test case failures
 with both Tk 8.5 and 8.4
In-Reply-To: <1385337935.63.0.262182292505.issue19761@psf.upfronthosting.co.za>
Message-ID: <1388003886.91.0.522520495325.issue19761@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/issue19761>
_______________________________________

From report at bugs.python.org  Wed Dec 25 21:45:05 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 25 Dec 2013 20:45:05 +0000
Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown()
 don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388004305.57.0.105695168087.issue18566@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Looks like this issue has been resolved. Can we close it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18566>
_______________________________________

From report at bugs.python.org  Wed Dec 25 22:16:38 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 Dec 2013 21:16:38 +0000
Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown()
 don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388006198.82.0.142638290119.issue18566@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Resolved in what way? The doc seems unchanged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18566>
_______________________________________

From report at bugs.python.org  Wed Dec 25 22:23:52 2013
From: report at bugs.python.org (Julian Gindi)
Date: Wed, 25 Dec 2013 21:23:52 +0000
Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown()
 don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388006632.32.0.795800474465.issue18566@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Sorry. I meant, merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18566>
_______________________________________

From report at bugs.python.org  Wed Dec 25 22:39:42 2013
From: report at bugs.python.org (py.user)
Date: Wed, 25 Dec 2013 21:39:42 +0000
Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown()
 don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388007582.67.0.384215173191.issue18566@psf.upfronthosting.co.za>


py.user added the comment:

I have built 3.4.0a4 and run - same thing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18566>
_______________________________________

From report at bugs.python.org  Thu Dec 26 01:36:03 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Dec 2013 00:36:03 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <13879211.rAT1KLZY4E@raxxla>
Message-ID: <52BB79ED.4060402@egenix.com>


Marc-Andre Lemburg added the comment:

I thought some more about this approach. I'm +1 on it. The locale
lookup is not time critical, so the table optimization makes sense.
Nice idea, Serhiy !

On 22.12.2013 00:38, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> * the patch seems to include some unrelated changes, e.g. the
>>   devanagari fixes and a few new mappings
> 
> May be. In any case I have added issue20027 as dependency. New mappings were 
> added when enable UTF-8 locales in makelocalealias.py (I can split this in 
> separate issue).

I think it's better to apply the patches separately, if that's
possible.

>> * the optimize step is called twice for some reason - is this
>>   intended ? if yes, please add a comment why this is done
> 
> Actually we should call it in a loop while the size of the table is decreased.

Ok, that makes sense. Still, please add a comment on why this is necessary.

>> * the patch would need some tests to make sure that the removed
>>   aliases indeed still map to the correct C locale strings
> 
> Currently the makelocalealias.py is such manual test. test_locale contains 
> multiple tests for different locales. I'll add several new cases.

Great.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Thu Dec 26 04:27:15 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 03:27:15 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <3dqc6V3tV1z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 3598805d7636 by R David Murray in branch '2.7':
#20063: Remove inaccurate/confusing statement about support of 'pop' method.
http://hg.python.org/cpython/rev/3598805d7636

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Thu Dec 26 04:27:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Dec 2013 03:27:57 +0000
Subject: [issue20063] Docs imply that set does not support .pop() method
In-Reply-To: <1387899195.0.0.384928731655.issue20063@psf.upfronthosting.co.za>
Message-ID: <1388028477.35.0.514348897474.issue20063@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Gennandiy.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20063>
_______________________________________

From report at bugs.python.org  Thu Dec 26 07:42:47 2013
From: report at bugs.python.org (Julian Gindi)
Date: Thu, 26 Dec 2013 06:42:47 +0000
Subject: [issue20068] collections.Counter documentation leaves out interesting
 usecase
Message-ID: <1388040167.94.0.902280065341.issue20068@psf.upfronthosting.co.za>


New submission from Julian Gindi:

I think the documentation for collections.Counter can be updated slightly to include an example showing the initialization of a counter object from a list. For example, it explains how to manually iterate through a list and increment the values...

for word in ['red', 'blue', 'red', 'green', 'blue', 'blue']:
...     cnt[word] += 1

I think it is more useful and powerful to do something like this:

cnt = Counter(['red', 'blue', 'red', 'green', 'blue', 'blue'])

where the result would be:

Counter({'blue': 3, 'red': 2, 'green': 1})

Just a thought. I'm curious to see what other people think.

----------
assignee: docs at python
components: Documentation
messages: 206935
nosy: Julian.Gindi, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: collections.Counter documentation leaves out interesting usecase
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/issue20068>
_______________________________________

From report at bugs.python.org  Thu Dec 26 11:00:27 2013
From: report at bugs.python.org (xupeng)
Date: Thu, 26 Dec 2013 10:00:27 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1388052027.24.0.399437096482.issue16500@psf.upfronthosting.co.za>


Changes by xupeng <xupeng at xupeng.me>:


----------
nosy: +xupeng

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Thu Dec 26 11:28:23 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 26 Dec 2013 10:28:23 +0000
Subject: [issue20069] Add unit test for os.chown
Message-ID: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is no tests for os.chown except for the invalid input.

Attached the patch to add tests for os.chown. This test has not exercised the keyword `dir_fd` and `follow_symlinks` because `follow_symlinks` (I think) is kinda broken on Windows and I prefer to add unit test for `dir_fd` keyword in different ticket.

----------
components: Tests
files: add_unit_test_os_chown.patch
keywords: patch
messages: 206936
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Add unit test for os.chown
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33266/add_unit_test_os_chown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20069>
_______________________________________

From report at bugs.python.org  Thu Dec 26 11:28:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 26 Dec 2013 10:28:52 +0000
Subject: [issue20069] Add unit test for os.chown
In-Reply-To: <1388053703.09.0.645818054692.issue20069@psf.upfronthosting.co.za>
Message-ID: <1388053732.19.0.787995958864.issue20069@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Here is the patch for Python 2.7.

----------
Added file: http://bugs.python.org/file33267/add_unit_test_os_chown_python27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20069>
_______________________________________

From report at bugs.python.org  Thu Dec 26 15:23:23 2013
From: report at bugs.python.org (Alexandr Zarubkin)
Date: Thu, 26 Dec 2013 14:23:23 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1388067803.23.0.267961588614.issue9291@psf.upfronthosting.co.za>


Alexandr Zarubkin added the comment:

An alternative solution, which worked for me, is:
add file named sitecustomize.py in Lib\site-packages folder.

The contents of the file:
import sys
sys.setdefaultencoding("cp1251")

The default encoding should be determined for every localized Windows version.
Also, when creating virtual environments, the same file should be placed in site-packages folder of virtual environment being created prior to installing setuptools in it.

----------
nosy: +me21
Added file: http://bugs.python.org/file33268/sitecustomize.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:03:04 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Dec 2013 15:03:04 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1388070184.58.0.399000858692.issue19683@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Some refactoring of the tests is certainly acceptable.  If there are some tests that can be merged together, it is fine to do so; also for removing ones that don't make any sense (it's not like they've ever tested anything anyway :)).  We don't have anyone listed as an expert on xml.dom.minidom (or the xml package as a whole), so we kind of have to just muddle along on our own with this.  Any tests you come up with to fill the empty ones will be better than no tests at all.  If someone with more experience with minidom comes along later and improves your tests, that will be great; but considering how long there have been this many empty tests in the file, I don't think that's terribly likely.

In fact, having looked at the test module in a bit more detail, it's in pretty sore need of an overall modernization.  The 'confirm' method is just a thin wrapper around assertTrue with an extremely unhelpful default message, and is used almost exclusively for all tests in the file.  So currently if anything breaks the tests will say "this failed, but I won't tell you why.  Good luck figuring it out!"  'confirm' should be removed, and all of the huge conditions passed into it throughout the file should be converted into individual assert*() calls.  It also looks like we could make use of setUp/tearDown to eliminate a lot of repetition (such as creating a base Document and subsequently removing it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:21:05 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Dec 2013 15:21:05 +0000
Subject: [issue19938] Re-enable test_bug_1333982 on 3.x
In-Reply-To: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>
Message-ID: <1388071265.62.0.905135822606.issue19938@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a much better patch to 3.4.

----------
Added file: http://bugs.python.org/file33269/test_dis_1333982-3.4.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19938>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:29:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 15:29:12 +0000
Subject: [issue19938] Re-enable test_bug_1333982 on 3.x
In-Reply-To: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>
Message-ID: <1388071752.64.0.112878072067.issue19938@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> zach.ware
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19938>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:32:01 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 26 Dec 2013 15:32:01 +0000
Subject: [issue20070] test_urllib2net is run even when the network resource is
 disabled
Message-ID: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>


New submission from Matthias Klose:

test_urllib2net is run even when the network resource is disabled, unlike test_urllibnet:

run_tests.py -j 1 -w -uall,-network,-urlfetch
...
[349/380/6] test_urllib2net
Resource 'http://www.python.org/' is not available
Resource 'http://www.example.com' is not available
Resource 'http://bitly.com/urllibredirecttest' is not available
Resource 'http://www.imdb.com' is not available
Resource 'http://docs.python.org/2/glossary.html#glossary' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'ftp://ftp.mirror.nl/pub/gnu/' is not available
Resource 'http://www.python.org' is not available
Resource 'http://www.python.org' is not available
Resource 'http://www.python.org' is not available
Resource 'http://www.python.org' is not available
[350/380/6] test_urllib_response
[351/380/6] test_urllibnet
test_urllibnet skipped -- Use of the 'network' resource not enabled
[352/380/6] test_urlparse
...

----------
components: Tests
messages: 206942
nosy: doko
priority: normal
severity: normal
status: open
title: test_urllib2net is run even when the network resource is disabled
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20070>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:32:34 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 26 Dec 2013 15:32:34 +0000
Subject: [issue20070] test_urllib2net is run even when the network resource is
 disabled
In-Reply-To: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>
Message-ID: <1388071954.47.0.956067228887.issue20070@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20070>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:55:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 15:55:42 +0000
Subject: [issue19938] Re-enable test_bug_1333982 on 3.x
In-Reply-To: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>
Message-ID: <3dqwk5462Gz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset e04fc45b7555 by Zachary Ware in branch '3.3':
Issue #19938: Re-enabled test_bug_1333982 in test_dis, which had been
http://hg.python.org/cpython/rev/e04fc45b7555

New changeset 285313c95e37 by Zachary Ware in branch 'default':
Issue #19938: Re-enabled test_bug_1333982 in test_dis, which had been
http://hg.python.org/cpython/rev/285313c95e37

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19938>
_______________________________________

From report at bugs.python.org  Thu Dec 26 16:57:11 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Dec 2013 15:57:11 +0000
Subject: [issue19938] Re-enable test_bug_1333982 on 3.x
In-Reply-To: <1386630396.24.0.124840868686.issue19938@psf.upfronthosting.co.za>
Message-ID: <1388073431.25.0.00202233485428.issue19938@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Committed; thanks for the review, Serhiy!  I made similar changes to the 3.3 patch before committing.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19938>
_______________________________________

From report at bugs.python.org  Thu Dec 26 17:06:25 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 26 Dec 2013 16:06:25 +0000
Subject: [issue20070] test_urllib2net is run even when the network resource is
 disabled
In-Reply-To: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>
Message-ID: <1388073985.49.0.235998763985.issue20070@psf.upfronthosting.co.za>


Matthias Klose added the comment:

this fixes it for me:

--- a/Lib/test/test_urllib2net.py	Wed Dec 25 17:36:20 2013 +0200
+++ b/Lib/test/test_urllib2net.py	Thu Dec 26 17:05:47 2013 +0100
@@ -14,6 +14,8 @@
 except ImportError:
     ssl = None
 
+support.requires("network")
+
 TIMEOUT = 60  # seconds
 
 
@@ -339,5 +341,4 @@
 
 
 if __name__ == "__main__":
-    support.requires("network")
     unittest.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20070>
_______________________________________

From report at bugs.python.org  Thu Dec 26 17:17:43 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Dec 2013 16:17:43 +0000
Subject: [issue20070] test_urllib2net is run even when the network resource is
 disabled
In-Reply-To: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>
Message-ID: <1388074663.29.0.771222184566.issue20070@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20070>
_______________________________________

From report at bugs.python.org  Thu Dec 26 17:37:32 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 16:37:32 +0000
Subject: [issue20070] test_urllib2net is run even when the network resource is
 disabled
In-Reply-To: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>
Message-ID: <3dqxfM6x9Nz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset e00bfb70a0c0 by doko in branch 'default':
- Issue #20070: Don't run test_urllib2net when network resources are not
http://hg.python.org/cpython/rev/e00bfb70a0c0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20070>
_______________________________________

From report at bugs.python.org  Thu Dec 26 18:25:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Dec 2013 17:25:26 +0000
Subject: [issue20071] What should happen if someone runs ./python -m ensurepip
 in the build environment?
Message-ID: <1388078726.11.0.20000173411.issue20071@psf.upfronthosting.co.za>


New submission from R. David Murray:

Someone on IRC reported doing this, and it (logically enough) gave a permission error trying to install into /opt.  That may be exactly what it should do...but if he'd done it as root, presumably it would have tried to install PIP without python having been installed first, which might be wrong.

(Donald says it would indeed install it, creating the directories as needed.)

----------
messages: 206948
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: What should happen if someone runs ./python -m ensurepip in the build environment?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20071>
_______________________________________

From report at bugs.python.org  Thu Dec 26 18:59:49 2013
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 26 Dec 2013 17:59:49 +0000
Subject: [issue20070] test_urllib2net is run even when the network resource is
 disabled
In-Reply-To: <1388071921.38.0.169844845527.issue20070@psf.upfronthosting.co.za>
Message-ID: <1388080789.91.0.331866717093.issue20070@psf.upfronthosting.co.za>


Matthias Klose added the comment:

fixed

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20070>
_______________________________________

From report at bugs.python.org  Thu Dec 26 19:09:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 18:09:01 +0000
Subject: [issue20067] Tkinter variables no works with wantobject is false
In-Reply-To: <1387988182.68.0.509066568991.issue20067@psf.upfronthosting.co.za>
Message-ID: <3dqzgw47xhz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset b13c15a9ae54 by Serhiy Storchaka in branch '2.7':
Issue #20067: Tkinter variables now work when wantobjects is false.
http://hg.python.org/cpython/rev/b13c15a9ae54

New changeset fbc1a39b68e4 by Serhiy Storchaka in branch '3.3':
Issue #20067: Tkinter variables now work when wantobjects is false.
http://hg.python.org/cpython/rev/fbc1a39b68e4

New changeset 99df5128d978 by Serhiy Storchaka in branch 'default':
Issue #20067: Tkinter variables now work when wantobjects is false.
http://hg.python.org/cpython/rev/99df5128d978

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20067>
_______________________________________

From report at bugs.python.org  Thu Dec 26 19:11:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 18:11:05 +0000
Subject: [issue20067] Tkinter variables no works with wantobject is false
In-Reply-To: <1387988182.68.0.509066568991.issue20067@psf.upfronthosting.co.za>
Message-ID: <1388081465.76.0.238350608574.issue20067@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/issue20067>
_______________________________________

From report at bugs.python.org  Thu Dec 26 19:20:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 18:20:06 +0000
Subject: [issue20072] Ttk tests fail when wantobjects is false
Message-ID: <1388082006.36.0.0879597768975.issue20072@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Ttk tests fail when wantobjects is false. See attached log file.

----------
assignee: serhiy.storchaka
components: Tkinter
files: test_ttk_guionly.log
messages: 206951
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Ttk tests fail when wantobjects is false
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33270/test_ttk_guionly.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20072>
_______________________________________

From report at bugs.python.org  Thu Dec 26 19:38:55 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 18:38:55 +0000
Subject: [issue20072] Ttk tests fail when wantobjects is false
In-Reply-To: <1388082006.36.0.0879597768975.issue20072@psf.upfronthosting.co.za>
Message-ID: <1388083135.55.0.909240759199.issue20072@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes tkinter so that it now works when wantobjects is false (at least functions and methods return more sensible results) and fixes ttk tests so they conform to current behavior. If wantobjects is true, the behavior should not be changed.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file33271/test_ttk_wantobjects.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20072>
_______________________________________

From report at bugs.python.org  Thu Dec 26 19:59:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 18:59:29 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1388084369.02.0.72883831386.issue20027@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please make a decision about last patch, Marc-Andre?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 26 20:16:21 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Dec 2013 19:16:21 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1388084369.02.0.72883831386.issue20027@psf.upfronthosting.co.za>
Message-ID: <52BC807F.7010407@egenix.com>


Marc-Andre Lemburg added the comment:

On 26.12.2013 19:59, Serhiy Storchaka wrote:
> 
> Could you please make a decision about last patch, Marc-Andre?

Looks good. Thanks, Serhiy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 26 20:22:16 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 19:22:16 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <3dr1JS0K7fz7Ljn@mail.python.org>


Roundup Robot added the comment:

New changeset aad582f717da by Serhiy Storchaka in branch '2.7':
Issue #20027: Fixed locale aliases for devanagari locales.
http://hg.python.org/cpython/rev/aad582f717da

New changeset 7615c009e925 by Serhiy Storchaka in branch '3.3':
Issue #20027: Fixed locale aliases for devanagari locales.
http://hg.python.org/cpython/rev/7615c009e925

New changeset fff3f28733b4 by Serhiy Storchaka in branch 'default':
Issue #20027: Fixed locale aliases for devanagari locales.
http://hg.python.org/cpython/rev/fff3f28733b4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 26 20:24:04 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 19:24:04 +0000
Subject: [issue20027] Fixed support for Indian locales
In-Reply-To: <1387482128.81.0.923367011564.issue20027@psf.upfronthosting.co.za>
Message-ID: <1388085844.31.0.861199962848.issue20027@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/issue20027>
_______________________________________

From report at bugs.python.org  Thu Dec 26 20:34:59 2013
From: report at bugs.python.org (Benjamin Eggerstedt)
Date: Thu, 26 Dec 2013 19:34:59 +0000
Subject: [issue20073] IDLE crashes on Unicode characters
Message-ID: <1388086497.78.0.557218598478.issue20073@psf.upfronthosting.co.za>


New submission from Benjamin Eggerstedt:

Hi,

On Mac OS the following crash happens in IDLE if you have fat fingers and hit some unexpected keys ...

e.g. 
? (Alt + u)

In case that the online tool somehow changes the characters, here is some hopefully safe way to deliver the details ...

Benny$ python
Python 2.7.6 (v2.7.6:3a1db0d2747e, Nov 10 2013, 00:42:54) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = "?"
>>> a
'\xc2\xa8'

I believe this is related to ...
http://bugs.python.org/issue13153
http://bugs.python.org/issue10973

Crash information:
Process:         Python [14161]
Path:            /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.7.6 (2.7.6)
Code Type:       X86 (Native)
Parent Process:  launchd [261]
Responsible:     Python [14161]
User ID:         501

Date/Time:       2013-12-26 19:59:35.756 +0100
OS Version:      Mac OS X 10.9.1 (13B42)
Report Version:  11
Anonymous UUID:  38E44FC5-9CFA-A636-C42D-307294DC13E7

Sleep/Wake UUID: A5C29C67-2DA5-4435-BC79-B6208FF60B16

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'

Application Specific Backtrace 1:
0   CoreFoundation                      0x9846d6b1 __raiseError + 193
1   libobjc.A.dylib                     0x9bceb091 objc_exception_throw + 162
2   CoreFoundation                      0x9846d5cb +[NSException raise:format:] + 139
3   CoreFoundation                      0x9833faed -[__NSCFString characterAtIndex:] + 109
4   Tk                                  0x020baac7 TkpInitKeymapInfo + 722
5   Tk                                  0x020b670f TkpRedirectKeyEvent + 1232
6   Tk                                  0x020c0efe Tk_MacOSXSetupTkNotifier + 954
7   Tcl                                 0x006f240e Tcl_DoOneEvent + 308
8   _tkinter.so                         0x002d4322 Tkapp_MainLoop + 450
9   Python                              0x000c4230 PyEval_EvalFrameEx + 25344
10  Python                              0x000c6a2c PyEval_EvalCodeEx + 2012
11  Python                              0x000c4825 PyEval_EvalFrameEx + 26869
12  Python                              0x000c554c PyEval_EvalFrameEx + 30236
13  Python                              0x000c6a2c PyEval_EvalCodeEx + 2012
14  Python                              0x000c6b77 PyEval_EvalCode + 87
15  Python                              0x000eaf5c PyRun_FileExFlags + 172
16  Python                              0x000eb284 PyRun_SimpleFileExFlags + 532
17  Python                              0x00103412 Py_Main + 3410
18  Python                              0x00001f65 start + 53
19  ???                                 0x00000002 0x0 + 2

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x9846e007 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 7
1   com.apple.CoreFoundation      	0x9846d9b0 __raiseError + 960
2   libobjc.A.dylib               	0x9bceb091 objc_exception_throw + 162
3   com.apple.CoreFoundation      	0x9846d5cb +[NSException raise:format:] + 139
4   com.apple.CoreFoundation      	0x9833faed -[__NSCFString characterAtIndex:] + 109
5   Tk                            	0x020baac7 0x2000000 + 764615
6   Tk                            	0x020b670f 0x2000000 + 747279
7   Tk                            	0x020c0efe 0x2000000 + 790270
8   Tcl                           	0x006f240e Tcl_DoOneEvent + 308
9   _tkinter.so                   	0x002d4322 Tkapp_MainLoop + 450
10  org.python.python             	0x000c4230 PyEval_EvalFrameEx + 25344
11  org.python.python             	0x000c6a2c PyEval_EvalCodeEx + 2012
12  org.python.python             	0x000c4825 PyEval_EvalFrameEx + 26869
13  org.python.python             	0x000c554c PyEval_EvalFrameEx + 30236
14  org.python.python             	0x000c6a2c PyEval_EvalCodeEx + 2012
15  org.python.python             	0x000c6b77 PyEval_EvalCode + 87
16  org.python.python             	0x000eaf5c PyRun_FileExFlags + 172
17  org.python.python             	0x000eb284 PyRun_SimpleFileExFlags + 532
18  org.python.python             	0x00103412 Py_Main + 3410
19  Python                        	0x00001f65 start + 53

Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0   libsystem_kernel.dylib        	0x92ab7992 kevent64 + 10
1   libdispatch.dylib             	0x9331f8bd _dispatch_mgr_invoke + 238
2   libdispatch.dylib             	0x9331f556 _dispatch_mgr_thread + 52

Thread 2:
0   libsystem_kernel.dylib        	0x92ab7046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x94719dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x9471dcce start_wqthread + 30

Thread 3:
0   libsystem_kernel.dylib        	0x92ab7046 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x94719dcf _pthread_wqthread + 372
2   libsystem_pthread.dylib       	0x9471dcce start_wqthread + 30

Thread 4:
0   libsystem_kernel.dylib        	0x92ab6ace __select + 10
1   Tcl                           	0x007248e0 0x677000 + 710880
2   libsystem_pthread.dylib       	0x947185fb _pthread_body + 144
3   libsystem_pthread.dylib       	0x94718485 _pthread_start + 130
4   libsystem_pthread.dylib       	0x9471dcf2 thread_start + 34

Thread 5:
0   libsystem_kernel.dylib        	0x92ab1f7a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x92ab116c mach_msg + 68
2   com.apple.CoreFoundation      	0x9837ef69 __CFRunLoopServiceMachPort + 169
3   com.apple.CoreFoundation      	0x9837e541 __CFRunLoopRun + 1393
4   com.apple.CoreFoundation      	0x9837dd5a CFRunLoopRunSpecific + 394
5   com.apple.CoreFoundation      	0x9837dbbb CFRunLoopRunInMode + 123
6   com.apple.AppKit              	0x9b291f18 _NSEventThread + 283
7   libsystem_pthread.dylib       	0x947185fb _pthread_body + 144
8   libsystem_pthread.dylib       	0x94718485 _pthread_start + 130
9   libsystem_pthread.dylib       	0x9471dcf2 thread_start + 34

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000001  ebx: 0x014db000  ecx: 0x00000000  edx: 0x00000000
  edi: 0x004ec5b0  esi: 0x9846d5fe  ebp: 0xbfffe708  esp: 0xbfffe700
   ss: 0x00000023  efl: 0x00000286  eip: 0x9846e007   cs: 0x0000001b
   ds: 0x00000023   es: 0x00000023   fs: 0x00000000   gs: 0x0000000f
  cr2: 0x0468a000
  
Logical CPU:     0
Error Code:      0x00000000
Trap Number:     3


Binary Images:
    0x1000 -     0x1ff7 +Python (???) <5E42C8AF-4D60-8991-99DF-D9F7D9BE5018> /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
    0x4000 -   0x146fff +org.python.python (2.7.6, [c] 2004-2013 Python Software Foundation. - 2.7.6) <9C0C57BD-C006-1A8D-90F5-422FD3D05652> /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x2d0000 -   0x2d7ff7 +_tkinter.so (???) <7DDA96E8-45E2-2385-2045-37F603882100> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
  0x677000 -   0x741ff7  Tcl (8.5.9 - 8.5.9) <B4D8EBCA-4404-3367-9656-141348996C28> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x7f5000 -   0x7f8ff7 +strop.so (???) <099FF8EE-ED78-C47B-C64F-6B0510025DEF> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
 0x2000000 -  0x20ecffc  Tk (8.5.9 - 8.5.9) <BEA92DB4-E461-33E6-89C6-402837548EF8> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
 0x211a000 -  0x2123ff7 +_socket.so (???) <B989F71D-43D0-8163-05EE-29462ABD15A8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
 0x212e000 -  0x212fff7 +_functools.so (???) <A69F8971-17DD-6EF8-4ACB-ACADE9A3001B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
 0x2132000 -  0x2136ff7 +_ssl.so (???) <5B67DF16-508B-3839-42DE-0270C85627CA> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
 0x213b000 -  0x213cff7 +cStringIO.so (???) <721E10B1-65B4-ABA6-90E6-D92952BE3AF8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
 0x2140000 -  0x2141ff7 +time.so (???) <5ECA4EBE-2EC9-3107-DCF4-45050F936643> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
 0x2186000 -  0x2189ff7 +_collections.so (???) <78F6EE64-6C57-7632-ADBE-FABDF9630120> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
 0x218e000 -  0x2191ff7 +operator.so (???) <C61843E8-61D2-104C-C3BC-A296888E7B24> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
 0x21f7000 -  0x21f8ff7 +_heapq.so (???) <FA517395-8DD2-B833-7C71-297CA2E5CC71> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
 0x21fc000 -  0x21fdff7 +fcntl.so (???) <7D79E04D-6165-E55E-0917-AC482EB3FC59> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
 0x2600000 -  0x2605ff7 +itertools.so (???) <7FAA1ED6-582E-BEEA-379F-F82A7923D051> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
 0x260d000 -  0x2620ff7 +_io.so (???) <1B9DFDC8-9D70-4256-B603-31A943100A2F> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
 0x2675000 -  0x2677ff7 +select.so (???) <5DF162CA-80BD-B25D-0243-E8D56AC37868> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so
 0x267c000 -  0x267fff7 +_struct.so (???) <21694FA7-1A29-5746-7D5C-4F57EB4BA72A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
 0x2686000 -  0x2688fe7 +binascii.so (???) <600CFC44-CBCF-E606-E378-AA5D6F00CB56> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
 0x274c000 -  0x2750ff7 +math.so (???) <E69F8DAC-CC96-392E-FFDE-749ACA982564> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
 0x2755000 -  0x2756ff7 +_hashlib.so (???) <8E1D90CA-C55F-B334-F047-8743905D87BD> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
 0x275a000 -  0x275bff7 +_random.so (???) <BCF247FD-CE8B-1290-4A4F-419542E24D4A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
 0x275e000 -  0x275fff7 +_locale.so (???) <C642A507-EFA8-4FB6-133A-4DF30A04C569> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
 0x2762000 -  0x2770ff7 +cPickle.so (???) <F739315F-6A1E-86E9-88EC-CEFCCA285AE6> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
 0x46e6000 -  0x46f1ffa  com.apple.CommerceCore (1.0 - 42) <E59717F2-6770-3DBC-8510-F7AA61E60F57> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
 0x6e25000 -  0x6e4aff9  com.apple.framework.familycontrols (4.1 - 410) <A33A97EE-C735-38BA-9B49-5D78DAA3DEDA> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
 0x74a3000 -  0x74a3ffd +cl_kernels (???) <EDFF895E-8B10-42FD-8BB9-6DAE1FF30917> cl_kernels
 0x74a5000 -  0x7590ff7  unorm8_bgra.dylib (2.3.58) <44644D3C-3D0E-3CBB-9265-664D95EC791F> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/ImageFormats/unorm8_bgra.dylib
0x8fe91000 - 0x8fec3417  dyld (239.3) <4B280BB1-55F8-313F-86A6-8ADD644ED69E> /usr/lib/dyld
0x90008000 - 0x90030ff7  libRIP.A.dylib (599.7) <461297C0-DDA9-3613-8F27-D7F1AC57208F> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x90031000 - 0x90032fff  libsystem_blocks.dylib (63) <2AC67D5E-ECD4-3644-A53C-9684F9B7AA33> /usr/lib/system/libsystem_blocks.dylib
0x90092000 - 0x900fdff9  com.apple.Heimdal (4.0 - 2.0) <E3091095-A893-3089-8DA1-8705B3BE5BF9> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
0x900fe000 - 0x90102fff  com.apple.CommonPanels (1.2.6 - 96) <E7CA63C6-CEE9-3F0A-93A7-C12C653FFB80> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x90122000 - 0x9013eff9  com.apple.Ubiquity (1.3 - 289) <1CEDC83D-7282-3B4D-8CF7-4FE045012391> /System/Library/PrivateFrameworks/Ubiquity.framework/Versions/A/Ubiquity
0x904be000 - 0x904eeff3  libtidy.A.dylib (15.12) <3DBE95FE-8FA7-3584-9202-E37B54B3B064> /usr/lib/libtidy.A.dylib
0x904ef000 - 0x90520ffa  libsystem_m.dylib (3047.16) <28E614E8-7802-3E84-960A-AD4721EF10F7> /usr/lib/system/libsystem_m.dylib
0x90521000 - 0x90528ff2  com.apple.NetFS (6.0 - 4.0) <915AA303-C02B-3B0C-8208-D8AAA4350DB4> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x90529000 - 0x90551fff  libsystem_info.dylib (449.1.3) <BB68E8CC-422F-3121-8C86-D0F766FB696D> /usr/lib/system/libsystem_info.dylib
0x90552000 - 0x90564fff  libbsm.0.dylib (33) <1BE92DB5-0D2F-3BB5-BCC6-8A71EF2A3450> /usr/lib/libbsm.0.dylib
0x90565000 - 0x9056effa  com.apple.CommonAuth (4.0 - 2.0) <6CB82D57-3C55-39E5-9036-8047DF3E6F57> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
0x905de000 - 0x907a4ffb  libicucore.A.dylib (511.27) <653147E9-7326-337A-99E1-B42E4D801E53> /usr/lib/libicucore.A.dylib
0x907a5000 - 0x90868ff1  com.apple.CoreText (352.0 - 367.15) <746AD442-F7B4-3273-A36D-C7103D26F727> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
0x90bee000 - 0x90c11ff7  libc++abi.dylib (48) <5367BE5A-D475-3FB4-972D-E1DC999A709A> /usr/lib/libc++abi.dylib
0x90d91000 - 0x90d9fff7  com.apple.Sharing (132.2 - 132.2) <87DBFC7A-9689-3B8E-AD16-5A9DFF9DE625> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
0x90da0000 - 0x90e3cfff  com.apple.QD (3.50 - 298) <F73FD4D4-17A4-37D6-AC06-7CA5A8BA1212> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x90e3d000 - 0x90e4bff3  com.apple.opengl (9.0.83 - 9.0.83) <16CFFD50-217E-3E18-88AF-7F2AD980628B> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x90e4c000 - 0x90e4cfff  com.apple.Accelerate (1.9 - Accelerate 1.9) <C85070A7-D942-3CFA-981F-5864480788C8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x90e4d000 - 0x91137fd2  com.apple.vImage (7.0 - 7.0) <256972F0-3DBC-3CE1-9EE8-B48243868729> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x9119f000 - 0x91491ff8  com.apple.CoreImage (9.0.54) <D7BC3E53-EF5B-3A14-8808-8D45EE505B48> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/CoreImage.framework/Versions/A/CoreImage
0x91492000 - 0x9149bfff  com.apple.speech.recognition.framework (4.2.4 - 4.2.4) <CF8E5706-F744-3139-8A51-D52BF055D19F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x914fb000 - 0x91513fff  com.apple.CFOpenDirectory (10.9 - 173.1.1) <630A5CCF-8FC3-379D-B0BD-41DCE1F0B624> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x91514000 - 0x91515fff  libSystem.B.dylib (1197.1.1) <C58F0CC9-C1FD-3024-9358-D3359A6BBCAD> /usr/lib/libSystem.B.dylib
0x91516000 - 0x91553ffb  libGLImage.dylib (9.0.83) <FA15FEB5-54E4-313B-8E78-A2D2E6C88FE1> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x91bf7000 - 0x91bfaffb  libutil.dylib (34) <B496031E-E763-3DEB-84D2-85C0F3DF2012> /usr/lib/libutil.dylib
0x91bfb000 - 0x91cf9fff  libJP2.dylib (1038) <EE0B9985-625D-39E6-B425-03FB75BA2594> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x91cfa000 - 0x91de5ff4  com.apple.DiskImagesFramework (10.9 - 371.1) <FC13BD5A-0FB7-35D5-A8DF-0510CFA996FE> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
0x91e4e000 - 0x91eceff7  com.apple.CoreServices.OSServices (600.4 - 600.4) <1227DF22-E2DA-3764-A1CA-10CC0CEBE377> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x91ecf000 - 0x91f1bff7  libcups.2.dylib (372) <9A2BE8DC-37E4-3019-B665-1036FE7868EA> /usr/lib/libcups.2.dylib
0x91f1c000 - 0x91f1cfff  com.apple.Accelerate.vecLib (3.9 - vecLib 3.9) <DDAC0B59-F886-3AB1-98E8-C71FFF161CD4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x9237f000 - 0x92385ffc  libCGXCoreImage.A.dylib (599.7) <87F9F4B2-487E-3B11-A869-D6CBDAB39055> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x92386000 - 0x92393ff7  com.apple.HelpData (2.1.4 - 90) <5BACC236-5B40-33AC-B088-87EDEFAF1D3E> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x92394000 - 0x923d6fff  libGLU.dylib (9.0.83) <0D9BFE5A-435E-3C66-AF96-D3567B8FC87B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x923d7000 - 0x92401fff  libxslt.1.dylib (13) <249D54AB-1D82-38FE-ABEC-0D575450C73B> /usr/lib/libxslt.1.dylib
0x9240a000 - 0x9249cffe  libsystem_c.dylib (997.1.1) <D06FD754-8CE3-3EB7-BE05-2EF939BBE05F> /usr/lib/system/libsystem_c.dylib
0x92665000 - 0x92665fff  com.apple.ApplicationServices (48 - 48) <7967F6FA-2984-3CC3-AD9A-7B9AEC562A2A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x92666000 - 0x9266ffff  libsystem_notify.dylib (121) <623269F5-1518-3035-A916-8AF83C972154> /usr/lib/system/libsystem_notify.dylib
0x92670000 - 0x9267bfff  com.apple.CrashReporterSupport (10.9 - 538) <7A5FF845-433C-33E3-99B5-F6AA5B825734> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
0x9267c000 - 0x926c4fff  com.apple.PerformanceAnalysis (1.47 - 47) <16935C0F-7F9F-316E-9D46-11973DE0904A> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
0x926c5000 - 0x92718fff  com.apple.htmlrendering (77 - 1.1.4) <408FA30F-4FE9-3162-9FFD-677E8569C1EA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x92719000 - 0x92724fff  libcsfde.dylib (380) <C9E61AFB-1A9D-324B-9827-06B182CDD7B0> /usr/lib/libcsfde.dylib
0x92725000 - 0x92749fff  libxpc.dylib (300.1.17) <252BC88F-A5CA-3E67-AEDB-3D7B9F4537E2> /usr/lib/system/libxpc.dylib
0x92853000 - 0x92866fff  com.apple.ImageCapture (9.0 - 9.0) <63D5C96F-1893-3F35-ADFB-EE451AFD87E6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x92867000 - 0x9286bffa  libcache.dylib (62) <9730D7F2-D226-3F30-8D26-BF598CB781F6> /usr/lib/system/libcache.dylib
0x9286c000 - 0x928cdff7  com.apple.Symbolication (1.4 - 129) <E5948C08-6ADF-3D86-9134-6AE49CF1DA0F> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
0x928ce000 - 0x928fcff3  com.apple.DebugSymbols (106 - 106) <FC70F4C9-B2A6-352F-9563-6C085E9DDDB8> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
0x928fd000 - 0x92a09fff  com.apple.ImageIO.framework (3.3.0 - 1038) <0B4A6607-9FBC-3A6C-984A-0542DE8385FB> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x92a90000 - 0x92a90fff  libodfde.dylib (20) <98FC02AE-C596-3ED5-80D1-C502FF6115ED> /usr/lib/libodfde.dylib
0x92a91000 - 0x92a96ff7  com.apple.print.framework.Print (9.0 - 260) <A6C465F6-C5D1-353A-9F33-19B9CEDBBC2A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x92a9f000 - 0x92abcff4  libsystem_kernel.dylib (2422.1.72) <C5641F6C-E271-380A-A656-AE4C04345602> /usr/lib/system/libsystem_kernel.dylib
0x92abd000 - 0x92ba0ff7  libcrypto.0.9.8.dylib (50) <B367D3A3-FC1F-326C-92EC-CAD81666524D> /usr/lib/libcrypto.0.9.8.dylib
0x92ba1000 - 0x92ba1ffd  libOpenScriptingUtil.dylib (157) <4D06E8ED-D312-34EA-A448-DFF45ADC3CE5> /usr/lib/libOpenScriptingUtil.dylib
0x92c43000 - 0x92c4bfff  libcopyfile.dylib (103) <1B1484BD-08B6-3BA9-94CA-A7C24B610EB3> /usr/lib/system/libcopyfile.dylib
0x92c4c000 - 0x92d32ff7  com.apple.coreui (2.1 - 231) <1C1AE894-C5C2-3F1C-BF29-B152ECD9BD88> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x92d33000 - 0x92d68ffd  libssl.0.9.8.dylib (50) <F3BEA2DF-DB84-37F0-B4C7-97C0A4DF19C9> /usr/lib/libssl.0.9.8.dylib
0x92d69000 - 0x92d99ff7  com.apple.CoreServicesInternal (184.8 - 184.8) <88528205-9452-3EEC-BB27-DAAA7EC81E04> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
0x92d9a000 - 0x92e6afef  libvDSP.dylib (423.32) <E2FA7230-A001-3F6B-9ACF-6998C51AD7DC> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x92e6b000 - 0x92e73fff  liblaunch.dylib (842.1.4) <3798500D-4436-3AEB-B273-7F2428C33A4A> /usr/lib/system/liblaunch.dylib
0x92e74000 - 0x92ebafff  libcurl.4.dylib (78) <EC84399F-5EA8-321B-B122-99730CC557C8> /usr/lib/libcurl.4.dylib
0x92ec6000 - 0x92ecaffa  libGIF.dylib (1038) <5CEB4EDF-B0B6-33A6-BDDE-8C0D3226FA72> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x92ecb000 - 0x92edfff9  com.apple.MultitouchSupport.framework (245.13 - 245.13) <6860A0D0-3654-3B02-B2E9-C4D2637167B8> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x92ee0000 - 0x92ee3ffa  libCGXType.A.dylib (599.7) <2738FF52-4B47-31AD-B7E5-412F6AFACC2A> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x92ee4000 - 0x92ef0ffc  libbz2.1.0.dylib (29) <3CEF1E92-BA42-3F8A-8E8D-9E1F7658E5C7> /usr/lib/libbz2.1.0.dylib
0x92ef1000 - 0x9321cff6  com.apple.Foundation (6.9 - 1056) <C8AE9C03-3460-354A-A8B6-EF4955BE600D> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x9321d000 - 0x93309ff7  libxml2.2.dylib (26) <32040145-6FD6-3AD2-B98B-39F73BF9AC47> /usr/lib/libxml2.2.dylib
0x93317000 - 0x9331bfff  libheimdal-asn1.dylib (323.12) <9EA2A221-301B-3B9A-BBF2-38134145B5A8> /usr/lib/libheimdal-asn1.dylib
0x9331c000 - 0x93334ffd  libdispatch.dylib (339.1.9) <6249BAE5-044F-3A7A-9CCC-03FF7E6B405B> /usr/lib/system/libdispatch.dylib
0x93368000 - 0x933c4ffa  com.apple.print.framework.PrintCore (9.0 - 428) <3E248391-2669-328B-B84F-8763FE8E92BB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x933c5000 - 0x9344efff  com.apple.CoreSymbolication (3.0 - 141) <178DDF5C-B6DA-39BD-84F5-FD3FA7E93BF8> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
0x93472000 - 0x93474fff  com.apple.securityhi (9.0 - 55005) <51765C73-80D1-33E3-9589-3E88380CE007> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x93480000 - 0x9351fff7  libCoreStorage.dylib (380) <55467C87-E1A3-3057-B428-9BCEFD39E36D> /usr/lib/libCoreStorage.dylib
0x93520000 - 0x935e7ff7  com.apple.DiscRecording (8.0 - 8000.4.6) <84A7EC09-3BBD-3E04-A88C-6D3B724448FF> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
0x935e8000 - 0x9367fff7  com.apple.ink.framework (10.9 - 207) <EF00BCCB-B270-3F3D-9424-EF5F4BC23E25> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x93682000 - 0x9368effe  libkxld.dylib (2422.1.72) <F9B35FA5-C936-3286-A055-2B0780A674AC> /usr/lib/system/libkxld.dylib
0x9368f000 - 0x93690ffc  com.apple.TrustEvaluationAgent (2.0 - 25) <064B485D-56E0-3DD7-BBE2-E08A5BFFF8B3> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x93695000 - 0x9369bffb  libunwind.dylib (35.3) <099D1A6F-A1F0-3D05-BF1C-0A7BB32D39C2> /usr/lib/system/libunwind.dylib
0x9369c000 - 0x936acff5  com.apple.LangAnalysis (1.7.0 - 1.7.0) <71DE7754-0A47-3F35-B1BF-B1FE7E1311E0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x936ad000 - 0x936adfff  com.apple.Cocoa (6.8 - 20) <407DC9E6-BBCE-3D34-9BBB-00C90584FFDF> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x936ba000 - 0x937ccffc  libsqlite3.dylib (158) <B3DB0FED-FE4C-314D-8329-CF7708C8AAF4> /usr/lib/libsqlite3.dylib
0x9385a000 - 0x938ebfff  com.apple.ColorSync (4.9.0 - 4.9.0) <8366AE10-0396-3100-B87A-A176E8ECE7B6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x938ec000 - 0x938f4fee  libcldcpuengine.dylib (2.3.58) <713322D8-A643-3B9F-8194-9C4020D8A4D6> /System/Library/Frameworks/OpenCL.framework/Versions/A/Libraries/libcldcpuengine.dylib
0x938f5000 - 0x938f5fff  com.apple.Carbon (154 - 157) <6E680560-FD53-3C00-BDF7-7AFA28747DC8> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x939a2000 - 0x939bdff5  com.apple.openscripting (1.4 - 157) <5C161A52-8D2F-3D56-A988-05727BED7A59> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x939be000 - 0x939c4ff7  com.apple.AOSNotification (1.7.0 - 760.3) <63F7E7F8-6FA3-38D3-9907-CDF360CA9354> /System/Library/PrivateFrameworks/AOSNotification.framework/Versions/A/AOSNotification
0x939ef000 - 0x93a3fff7  libcorecrypto.dylib (161.1) <135FD99E-2211-3DF4-825C-C9F816107F0C> /usr/lib/system/libcorecrypto.dylib
0x93a40000 - 0x93a45ff3  libsystem_platform.dylib (24.1.4) <875321B9-34EF-3FCC-880C-633FA05223F5> /usr/lib/system/libsystem_platform.dylib
0x93a46000 - 0x93b7dff3  com.apple.desktopservices (1.8 - 1.8) <4D853961-F911-3FE2-A7DF-3130EA1D8CEB> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x93b92000 - 0x93c86fff  libFontParser.dylib (111.1) <D8F9B2A4-41A6-3407-8D80-13A841F97BE5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x93d9f000 - 0x93da1fff  libquarantine.dylib (71) <EE3B510E-1AEC-3171-8A1A-D6A5A42CF35C> /usr/lib/system/libquarantine.dylib
0x93da2000 - 0x93dbbfff  com.apple.Kerberos (3.0 - 1) <91F17EB2-C70C-359C-B09D-96B52D2A9C9F> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x94717000 - 0x9471effb  libsystem_pthread.dylib (53.1.4) <8B1B7B84-1B5D-32A8-AC0D-1E689E5C8A4C> /usr/lib/system/libsystem_pthread.dylib
0x9471f000 - 0x9475bff4  com.apple.RemoteViewServices (2.0 - 94) <BEEE6ADF-7DA3-3D68-BCB0-9863BE1A1F46> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
0x9475c000 - 0x947b2ff6  com.apple.ScalableUserInterface (1.0 - 1) <2C81641B-FA30-32FF-8B3E-3CB9BF53B2D9> /System/Library/Frameworks/QuartzCore.framework/Versions/A/Frameworks/ScalableUserInterface.framework/Versions/A/ScalableUserInterface
0x947d3000 - 0x947ebff7  libsystem_malloc.dylib (23.1.10) <69F485C9-B3E7-3E36-A06C-D7DFD29D22E1> /usr/lib/system/libsystem_malloc.dylib
0x947ec000 - 0x94822fff  com.apple.IconServices (25 - 25.17) <A4B5242B-765E-3D58-B066-BBEDB5947AAD> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
0x9483a000 - 0x9483effc  com.apple.IOSurface (91 - 91) <DECEEB72-3C7E-3C21-9237-E5AD293F8B09> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x9483f000 - 0x9488dff9  com.apple.HIServices (1.22 - 466) <30636237-408A-3552-90C1-1279348DF7CB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x9488e000 - 0x9497effb  libiconv.2.dylib (41) <848FEBA7-2E3E-3ECB-BD59-007F32468787> /usr/lib/libiconv.2.dylib
0x949d3000 - 0x949d7ff7  libmacho.dylib (845) <D8E93E59-1F80-3413-B9CF-78B848F6E873> /usr/lib/system/libmacho.dylib
0x951a8000 - 0x95354ff1  com.apple.QuartzCore (1.8 - 332.0) <07F9B77F-35A2-3D21-99FA-CD3FCE5B9C7B> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x95357000 - 0x95395ff7  com.apple.NavigationServices (3.8 - 215) <A093AAF0-248E-313E-BA82-01F69E269895> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x95396000 - 0x9539affc  libpam.2.dylib (20) <50623D44-795F-3E28-AA85-23E0E7E2AE0E> /usr/lib/libpam.2.dylib
0x9539b000 - 0x953c2fff  com.apple.CoreVideo (1.8 - 117.2) <A53FDD90-F200-3F7C-8A8E-5DE36D3DFBB0> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x953c3000 - 0x953c5ffe  libCVMSPluginSupport.dylib (9.0.83) <BD30BDD1-DD5B-3F31-A09B-C274EA93CD7C> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
0x953c6000 - 0x953c6fff  com.apple.CoreServices (59 - 59) <06747539-5035-3307-8645-9BC4E7F89023> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x953c7000 - 0x953f0ff5  com.apple.shortcut (2.6 - 2.6) <F9F32E6F-E641-36D0-B648-058D5E146D38> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x95657000 - 0x9565aff7  com.apple.help (1.3.3 - 46) <AB6292FA-D3BC-3D56-B3A5-2BE630A503E7> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x956aa000 - 0x956aeffe  libCoreVMClient.dylib (58.1) <0EB8FFD7-AFED-3A63-810E-29629831D43D> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x956af000 - 0x956bbff7  com.apple.OpenDirectory (10.9 - 173.1.1) <2AA24814-2DC6-3E28-B71B-186B686F0F19> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x956bc000 - 0x956bfff9  com.apple.TCC (1.0 - 1) <A5FCF7AA-3F56-3A19-9DF1-661F1F02F79D> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
0x956c0000 - 0x956c1fff  liblangid.dylib (117) <F18F76C6-7E4B-34AD-AE81-C1C031BF2F7D> /usr/lib/liblangid.dylib
0x959c4000 - 0x959c4ffd  com.apple.audio.units.AudioUnit (1.9 - 1.9) <8A37963C-DF6F-3DFF-94E9-407DC5DFEDA9> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x959ce000 - 0x95ccfff7  com.apple.CoreServices.CarbonCore (1077.14 - 1077.14) <42E10BD1-995B-3FB4-8A6D-5FD071FB8BD1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x95cd0000 - 0x95cdaff7  com.apple.speech.synthesis.framework (4.6.2 - 4.6.2) <16E20DCD-89F4-3C8E-9DBA-EED359807038> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x95e88000 - 0x95e92ff7  com.apple.DirectoryService.Framework (10.9 - 173.1.1) <D6735614-EF4B-389F-BF99-7D8416A504BA> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x95e95000 - 0x95e98ffe  com.apple.LoginUICore (3.0 - 3.0) <6FE961A4-3C17-3004-B50B-FD78FDC28350> /System/Library/PrivateFrameworks/LoginUIKit.framework/Versions/A/Frameworks/LoginUICore.framework/Versions/A/LoginUICore
0x95e99000 - 0x95f31ff7  com.apple.Metadata (10.7.0 - 800.12.2) <5E9EA0AC-EE9E-362E-9DAC-9B7D21A53A2A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x95f32000 - 0x95f3afff  libsystem_dnssd.dylib (522.1.11) <1C015806-B971-34F9-B162-3DF7897351D0> /usr/lib/system/libsystem_dnssd.dylib
0x95f3b000 - 0x96008ff7  com.apple.backup.framework (1.5.1 - 1.5.1) <91998CDF-3547-3183-A962-D9E981C14891> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x96009000 - 0x96016ff7  com.apple.AppleFSCompression (56 - 1.0) <0C44B3E4-C4A7-3A65-9C1A-334CA3E35BDB> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
0x961f1000 - 0x96566ff9  com.apple.HIToolbox (2.1 - 696) <43CB31D6-4C2B-30FA-A374-DB7C5728E7AD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x96567000 - 0x96568ffa  libsystem_sandbox.dylib (278.10) <F3C9C427-AF9F-3CE0-95FF-DC9ACA0B5760> /usr/lib/system/libsystem_sandbox.dylib
0x96569000 - 0x965c2ffa  libTIFF.dylib (1038) <691DAAFD-D72B-3BE9-AE5C-84AF86BE66CD> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x965c3000 - 0x96636fff  com.apple.SearchKit (1.4.0 - 1.4.0) <6F607AB6-7553-37BA-BEC5-98FD7C27FAD7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x96773000 - 0x967abff7  com.apple.MediaKit (15 - 709) <82E0F8C0-313C-379C-9994-4D21587D0C0C> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
0x96de5000 - 0x96f57ffb  com.apple.audio.toolbox.AudioToolbox (1.9 - 1.9) <E5FFD35D-18CF-333C-BECE-39F8E47BE707> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x98040000 - 0x98071ffd  com.apple.GSS (4.0 - 2.0) <6BA01155-4DAD-30EE-B480-D224650EA010> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
0x980d5000 - 0x980e0ffb  libcommonCrypto.dylib (60049) <F8E60C43-22EE-3E0B-9546-3365056901F1> /usr/lib/system/libcommonCrypto.dylib
0x980f9000 - 0x981a5ffb  libvMisc.dylib (423.32) <43873EFF-FB43-3301-BEE8-F2C3A046D7A6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x98252000 - 0x98291ff7  com.apple.bom (12.0 - 192) <50F9D23C-9C9A-38BF-B4E2-66D93BE2A174> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
0x98292000 - 0x98307ffb  com.apple.framework.IOKit (2.0.1 - 907.1.13) <86D72735-9DFB-35C8-83F7-CE0DCF17D354> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x98308000 - 0x9850aff7  com.apple.CoreFoundation (6.9 - 855.11) <50F70E07-043A-3A2F-87EF-A36BA6C5C9D9> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x9850e000 - 0x98563fff  libc++.1.dylib (120) <10C0A136-64F9-3CC2-9420-013247032120> /usr/lib/libc++.1.dylib
0x98564000 - 0x98572fff  libxar.1.dylib (202) <B73748D4-F830-3C71-98B3-7A3ABF5136FD> /usr/lib/libxar.1.dylib
0x98576000 - 0x985bcff7  libFontRegistry.dylib (127) <A0930DB2-A6C6-3C6E-B4A2-119E0D76FD7D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x985bd000 - 0x98612ff7  com.apple.audio.CoreAudio (4.2.0 - 4.2.0) <0F1C111F-1E64-33BB-A69F-14643B3037D5> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x98640000 - 0x9865cfff  libCRFSuite.dylib (34) <FFF76EBA-DF35-3A5F-857F-3F4B1C9F4C77> /usr/lib/libCRFSuite.dylib
0x9865d000 - 0x98681fff  libJPEG.dylib (1038) <212B0986-9227-397C-9493-BCB190EC020E> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x9869c000 - 0x98711ff1  com.apple.ApplicationServices.ATS (360 - 363.1) <5C9BC698-0CC1-3F6A-9F9D-BCC3A9C3D6DC> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x98712000 - 0x98788ff3  com.apple.securityfoundation (6.0 - 55122) <25149798-A37E-316F-84AB-93029EAF33D8> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x98789000 - 0x98b4eff6  libLAPACK.dylib (1094.5) <E6286E68-3501-31AC-813E-75B3B3968011> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x98b4f000 - 0x98b69ff7  com.apple.GenerationalStorage (2.0 - 160.2) <8755F7F1-2402-387C-A32A-2270E7D680C8> /System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/GenerationalStorage
0x98b6a000 - 0x98b85ff6  libPng.dylib (1038) <F39168D4-ABEB-3C2D-A763-B9D3E1EF43BC> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x98b86000 - 0x98b87fff  libDiagnosticMessagesClient.dylib (100) <B936B1D4-90BB-395D-8EA9-E1237608E7D0> /usr/lib/libDiagnosticMessagesClient.dylib
0x98ba9000 - 0x98ba9fff  libkeymgr.dylib (28) <1B097DEA-011E-3B1C-86D5-6C7FAD5C765A> /usr/lib/system/libkeymgr.dylib
0x98baa000 - 0x98babfff  libremovefile.dylib (33) <ED35EA79-EB06-3B84-A6D4-B1A9D6B8648D> /usr/lib/system/libremovefile.dylib
0x98ef3000 - 0x98f5cfff  com.apple.SystemConfiguration (1.13 - 1.13) <542075CD-9085-3F30-B84B-DD0277D6A40E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x98f5d000 - 0x98f65ff7  libCGCMS.A.dylib (599.7) <A7404924-9A2B-3324-A934-BD08953E7098> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGCMS.A.dylib
0x98f66000 - 0x98f6bff6  libcompiler_rt.dylib (35) <9924DF2E-D80B-3A21-920D-544A4597203F> /usr/lib/system/libcompiler_rt.dylib
0x98f6c000 - 0x98f7cff7  libsasl2.2.dylib (170) <CA1C07F6-8E17-315E-AE49-AB696DDE6707> /usr/lib/libsasl2.2.dylib
0x98f7d000 - 0x98fafff7  libTrueTypeScaler.dylib (111.1) <A568EE4C-1588-3F8B-8640-F02CEFC5AF09> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x98fb0000 - 0x9921dff6  com.apple.security (7.0 - 55471) <5FCF76B2-92C6-3404-87D3-91B3F6E203AA> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x9921e000 - 0x99256fff  com.apple.LDAPFramework (2.4.28 - 194.5) <0C42A932-15E8-3CD1-AC35-1DF7D41B25A2> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x99257000 - 0x992a6fff  com.apple.opencl (2.3.57 - 2.3.57) <93385E1C-00D9-31BE-9652-7F3C09484B3E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x992a7000 - 0x992e4ff7  libauto.dylib (185.5) <CD008E66-4A0C-35F5-8D72-80D76A716A03> /usr/lib/libauto.dylib
0x992e5000 - 0x992e6ffd  libunc.dylib (28) <22A126A1-DCFB-3BE5-A66B-C973F0A5D839> /usr/lib/system/libunc.dylib
0x992e7000 - 0x992eafff  libdyld.dylib (239.3) <729B32AC-EEE2-3739-8CE3-F90838D51906> /usr/lib/system/libdyld.dylib
0x99340000 - 0x9934bff6  com.apple.NetAuth (5.0 - 5.0) <3B2E9615-EE12-38FC-BDCF-09529FF9464B> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
0x993a8000 - 0x993b2fff  com.apple.bsd.ServiceManagement (2.0 - 2.0) <B84F3916-236A-347B-9C1F-3DE571496737> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
0x993b3000 - 0x997e7ff7  com.apple.vision.FaceCore (3.0.0 - 3.0.0) <5B12F3E9-84F6-3183-B85D-FD19EF800ADB> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
0x997e8000 - 0x997fafff  libsystem_asl.dylib (217.1.4) <51EB17C9-9F5B-39F3-B6CD-8EF238B05B89> /usr/lib/system/libsystem_asl.dylib
0x99896000 - 0x99898ffb  libRadiance.dylib (1038) <F0D3F13B-5628-3DF9-8B86-A4D914567B25> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x99a7f000 - 0x99a8dff7  libz.1.dylib (53) <858B4D9F-D87E-3D81-B07A-DF9632BD185F> /usr/lib/libz.1.dylib
0x9a92a000 - 0x9a956ff7  com.apple.DictionaryServices (1.2 - 208) <33873336-BECD-3F62-A315-C45F24C1818C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x9a957000 - 0x9a982ff7  libsystem_network.dylib (241.3) <71EBA489-386D-3608-ADE6-CB50EBD1AB1B> /usr/lib/system/libsystem_network.dylib
0x9a983000 - 0x9a9e1ffd  com.apple.AE (665.5 - 665.5) <54F2F247-160C-3A22-A6E3-5D49655A67AB> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x9a9e7000 - 0x9ab49ff3  com.apple.CFNetwork (673.0.3 - 673.0.3) <5E0E9AE8-073B-3F2B-B0C7-A0129DE787F6> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x9ab4a000 - 0x9ab4cfff  libsystem_configuration.dylib (596.12) <1C31C3F6-568D-3854-AE03-A5DA2F39297E> /usr/lib/system/libsystem_configuration.dylib
0x9ab4d000 - 0x9ab78ff5  com.apple.ChunkingLibrary (2.0 - 155.1) <50BBBBF8-F30B-39EA-A512-11A47F429F2C> /System/Library/PrivateFrameworks/ChunkingLibrary.framework/Versions/A/ChunkingLibrary
0x9ab79000 - 0x9ab82fff  com.apple.audio.SoundManager (4.1 - 4.1) <68B7CEB7-AF09-3E24-8548-6ABF065B5186> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x9ab83000 - 0x9acd9ff0  libBLAS.dylib (1094.5) <74310C2F-4FDB-3995-A01A-5AFB83010A43> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x9acda000 - 0x9ace2ffe  libGFXShared.dylib (9.0.83) <35644AAA-B1E7-367C-90C0-378024F8A46A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x9ace3000 - 0x9ad12fff  com.apple.framework.SystemAdministration (1.0 - 1.0) <05E81260-7DC7-3546-B45D-15B3E5DF056D> /System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/SystemAdministration
0x9ad1b000 - 0x9ad1dff2  com.apple.EFILogin (2.0 - 2) <BC558029-74C0-3A69-B376-8F4CBF8C338F> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin
0x9ad1e000 - 0x9ad27fff  com.apple.DiskArbitration (2.6 - 2.6) <6379523D-3196-370C-AE4A-8EA586E36909> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9ad28000 - 0x9ad35fff  com.apple.Librarian (1.2 - 1) <F85681E3-3398-327B-829B-1D8078C38C22> /System/Library/PrivateFrameworks/Librarian.framework/Versions/A/Librarian
0x9ad36000 - 0x9ae11ff7  com.apple.LaunchServices (572.23 - 572.23) <7E52FB5C-9ECF-3CB9-BF18-6652B8D8CDE0> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x9ae12000 - 0x9ae2fffb  libresolv.9.dylib (54) <3EC12A7F-6BA1-3976-9F1F-6A4B76303028> /usr/lib/libresolv.9.dylib
0x9ae30000 - 0x9b094fff  com.apple.CoreData (107 - 481) <F699EC21-57D9-3AE6-A17B-C1D1092780BD> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x9b0c1000 - 0x9bcdcff3  com.apple.AppKit (6.9 - 1265) <AE258D94-0272-394F-BBB7-9B5C165A4A78> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x9bcdd000 - 0x9be854af  libobjc.A.dylib (551.1) <31CBE178-E972-30D1-ADC6-4B8345CAE326> /usr/lib/libobjc.A.dylib
0x9bebc000 - 0x9becbfff  libGL.dylib (9.0.83) <E76D1F2A-D98B-3464-AD0B-FC1EBBADF027> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x9becc000 - 0x9bf35fff  com.apple.datadetectorscore (5.0 - 354.0) <0C6C812D-3E7A-31A4-BFDE-CD3316AA35B6> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x9bf36000 - 0x9c32eff3  com.apple.CoreGraphics (1.600.0 - 599.7) <DB004990-F06F-3768-AE4C-191B3C748EFC> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 40384
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=140.6M resident=69.2M(49%) swapped_out_or_unallocated=71.5M(51%)
Writable regions: Total=76.2M written=10.2M(13%) resident=20.2M(26%) swapped_out=0K(0%) unallocated=56.0M(74%)
 
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  3920K
CG image                            536K
CG raster data                       24K
CG shared images                    204K
CoreGraphics                          4K
CoreImage                             4K
CoreServices                        256K
Kernel Alloc Once                     4K
MALLOC                             45.2M
MALLOC (admin)                       48K
Memory Tag 242                       12K
OpenCL                                8K
Stack                              65.7M
VM_ALLOCATE                        16.5M
__DATA                             14.4M
__IMAGE                             528K
__LINKEDIT                         44.0M
__OBJC                             1880K
__PAGEZERO                            4K
__TEXT                             96.6M
__UNICODE                           544K
mapped file                       160.1M
shared memory                         4K
===========                      =======
TOTAL                             450.2M

Model: MacBookPro6,2, BootROM MBP61.0057.B0F, 2 processors, Intel Core i7, 2.8 GHz, 8 GB, SMC 1.58f17
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53533531323634485A2D3147314131
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1067 MHz, 0x802C, 0x31364A53533531323634485A2D3147314131
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.106.98.100.22)
Bluetooth: Version 4.2.0f6 12982, 3 services, 23 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS725050A9A362, 500,11 GB
Serial ATA Device: HL-DT-ST DVDRW  GS23N
USB Device: Hub
USB Device: External HDD
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM2070 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Internal Memory Card Reader
USB Device: Hub
USB Device: Keyboard Hub
USB Device: Apple Keyboard
USB Device: Built-in iSight
USB Device: IR Receiver
Thunderbolt Bus: 


Thanks,
Regards,
Benny

----------
components: IDLE
messages: 206956
nosy: Benjamin.Eggerstedt
priority: normal
severity: normal
status: open
title: IDLE crashes on Unicode characters
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20073>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:01:49 2013
From: report at bugs.python.org (Dolda2000)
Date: Thu, 26 Dec 2013 20:01:49 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
Message-ID: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>


New submission from Dolda2000:

It seems open() is slightly broken in Python 3, in that one cannot open non-seekable files in read-write mode. One such common use is open("/dev/tty", "r+") for interacting directly with the controlling TTY regardless of standard stream redirections. Note that this is a regression for Python 2, where this worked as expected.

What happens is the following:
>>> open("/dev/tty", "r+")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: File or stream is not seekable.

Just for the record, the same thing happens with "w+" and "rb+".

This also means that the getpass module is slightly broken, since it will always fail whenever stdin is redirected.

----------
components: IO
messages: 206957
nosy: Dolda2000
priority: normal
severity: normal
status: open
title: open() of read-write non-seekable streams broken
type: behavior
versions: Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:12:54 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 20:12:54 +0000
Subject: [issue16351] Add a function to get GC statistics
In-Reply-To: <1351445420.88.0.605881847233.issue16351@psf.upfronthosting.co.za>
Message-ID: <3dr2Qs32tqz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 17bd04fbf3d3 by R David Murray in branch 'default':
whatsnew for gc.get_stats, plus doc tweaks.
http://hg.python.org/cpython/rev/17bd04fbf3d3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16351>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:19:14 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 20:19:14 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>
Message-ID: <1388089154.9.0.304514629828.issue20046@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch. It doesn't include any additions to locale alias table (including devanagari). Added several tests cases (many other test cases for removed aliases already exist). optimize() is called only once, looks as second run has no effect until UTF-8 aliases are enabled.

----------
versions: +Python 3.4
Added file: http://bugs.python.org/file33272/locale_optimize_aliases_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:21:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 20:21:11 +0000
Subject: [issue20073] IDLE crashes on Unicode characters
In-Reply-To: <1388086497.78.0.557218598478.issue20073@psf.upfronthosting.co.za>
Message-ID: <1388089271.39.0.0195272753101.issue20073@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +hynek, kbk, ned.deily, roger.serwy, ronaldoussoren, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20073>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:22:57 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Dec 2013 20:22:57 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388089377.7.0.238680566041.issue20074@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think getpass will fail, since it uses os.open, not open.

Presumably you can work around the problem by opening the stream twice: once for reading and once for writing.  I'll leave it to Antoine to say whether or not that is in fact the expected solution, or if this is a design bug.

----------
nosy: +pitrou, r.david.murray
versions: +Python 3.4 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:28:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 20:28:44 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388089724.24.0.478822799938.issue20074@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Use unbuffered binary file.

>>> open("/dev/tty", "r+b", buffering=0)
<_io.FileIO name='/dev/tty' mode='rb+'>

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:35:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 20:35:20 +0000
Subject: [issue20075] help(open) eats first line
Message-ID: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The output of help(open) (and `pydoc open`) in 3.4 is:

Help on built-in function open in module io:

open(...)
    errors=None, newline=None, closefd=True, opener=None) -> file object
    
    Open file and return a stream.  Raise IOError upon failure.
...

In 3.3 and older it works correctly:

Help on built-in function open in module io:

open(...)
    open(file, mode='r', buffering=-1, encoding=None,
         errors=None, newline=None, closefd=True, opener=None) -> file object
    
    Open file and return a stream.  Raise IOError upon failure.
...

----------
components: Interpreter Core
keywords: 3.3regression
messages: 206962
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: help(open) eats first line
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Thu Dec 26 21:53:02 2013
From: report at bugs.python.org (Ned Deily)
Date: Thu, 26 Dec 2013 20:53:02 +0000
Subject: [issue20073] IDLE crashes on Unicode characters
In-Reply-To: <1388086497.78.0.557218598478.issue20073@psf.upfronthosting.co.za>
Message-ID: <1388091182.96.0.219537478776.issue20073@psf.upfronthosting.co.za>


Ned Deily added the comment:

Please follow the instructions at http://www.python.org/getit/mac/tcltk/ and install an up-to-date third-party version of Tcl/Tk 8.5 such as ActiveTcl 8.5.15.0.  This crash has been fixed in the newer versions of Cocoa Tk but still present in the Apple-supplied Tk 8.5 in OS X.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20073>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:09:16 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Dec 2013 21:09:16 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1388089154.9.0.304514629828.issue20046@psf.upfronthosting.co.za>
Message-ID: <52BC9AF6.2060303@egenix.com>


Marc-Andre Lemburg added the comment:

On 26.12.2013 21:19, Serhiy Storchaka wrote:
> 
> Here is updated patch. It doesn't include any additions to locale alias table (including devanagari). Added several tests cases (many other test cases for removed aliases already exist). optimize() is called only once, looks as second run has no effect until UTF-8 aliases are enabled.

Looks good. Could you add a test for the optimization function ?

It should make sure that a complete set of now removed locale
names are properly optimized away, e.g.

     'nl_nl':                                'nl_NL.ISO8859-1',
-    'nl_nl.88591':                          'nl_NL.ISO8859-1',
-    'nl_nl.iso88591':                       'nl_NL.ISO8859-1',
-    'nl_nl.iso885915':                      'nl_NL.ISO8859-15',
-    'nl_nl.iso885915 at euro':                 'nl_NL.ISO8859-15',
-    'nl_nl.utf8 at euro':                      'nl_NL.UTF-8',
-    'nl_nl at euro':                           'nl_NL.ISO8859-15',

and

     'ja_jp':                                'ja_JP.eucJP',
-    'ja_jp.ajec':                           'ja_JP.eucJP',
     'ja_jp.euc':                            'ja_JP.eucJP',
-    'ja_jp.eucjp':                          'ja_JP.eucJP',
-    'ja_jp.iso-2022-jp':                    'ja_JP.JIS7',
-    'ja_jp.iso2022jp':                      'ja_JP.JIS7',
-    'ja_jp.jis':                            'ja_JP.JIS7',
-    'ja_jp.jis7':                           'ja_JP.JIS7',
     'ja_jp.mscode':                         'ja_JP.SJIS',
     'ja_jp.pck':                            'ja_JP.SJIS',
-    'ja_jp.sjis':                           'ja_JP.SJIS',
-    'ja_jp.ujis':                           'ja_JP.eucJP',

This should then cover all the Latin-1 encodings and also
an Asian one.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:32:56 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 Dec 2013 21:32:56 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388093576.72.0.0541653157362.issue20075@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Interestingly, it doesn't look like pydoc's fault:

P:\ath\to\cpython\>PCbuild\python_d.exe -ISc "import sys;print(sys.version);print(open.__doc__[:75]);print('pydoc' in sys.modules)"
3.4.0b1 (default:94a04b8b3a12, Dec 26 2013, 09:27:14) [MSC v.1600 32 bit (Intel)]
     errors=None, newline=None, closefd=True, opener=None) -> file object


False

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:47:36 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Dec 2013 21:47:36 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1875808.QJB8RMQZ2H@raxxla>
Message-ID: <52BCA3F1.10806@egenix.com>


Marc-Andre Lemburg added the comment:

On 26.12.2013 22:43, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> Could you add a test for the optimization function ?
> 
> I have no ideas. The optimization function is a part of the makelocalealias.py 
> which ran manually very rarely (last time 3.5 year ago). It isn't exposed 
> outside the script and I'm not sure that it worths the complication of the 
> testing.

I probably wasn't clear: I meant some tests that show that the
alias definitions (on the left) from the X11 file are actually mapped to the
correct alias locales (on the right).

>> It should make sure that a complete set of now removed locale
>> names are properly optimized away, e.g.
>>
>>      'nl_nl':                                'nl_NL.ISO8859-1',
>> -    'nl_nl.88591':                          'nl_NL.ISO8859-1',
>> -    'nl_nl.iso88591':                       'nl_NL.ISO8859-1',
>> -    'nl_nl.iso885915':                      'nl_NL.ISO8859-15',
>> -    'nl_nl.iso885915 at euro':                 'nl_NL.ISO8859-15',
>> -    'nl_nl.utf8 at euro':                      'nl_NL.UTF-8',
>> -    'nl_nl at euro':                           'nl_NL.ISO8859-15',
> 
> These cases are covered by test_english and test_euro_modifier.

Ok.

>>      'ja_jp':                                'ja_JP.eucJP',
>> -    'ja_jp.ajec':                           'ja_JP.eucJP',
>>      'ja_jp.euc':                            'ja_JP.eucJP',
>> -    'ja_jp.eucjp':                          'ja_JP.eucJP',
>> -    'ja_jp.iso-2022-jp':                    'ja_JP.JIS7',
>> -    'ja_jp.iso2022jp':                      'ja_JP.JIS7',
>> -    'ja_jp.jis':                            'ja_JP.JIS7',
>> -    'ja_jp.jis7':                           'ja_JP.JIS7',
>>      'ja_jp.mscode':                         'ja_JP.SJIS',
>>      'ja_jp.pck':                            'ja_JP.SJIS',
>> -    'ja_jp.sjis':                           'ja_JP.SJIS',
>> -    'ja_jp.ujis':                           'ja_JP.eucJP',
> 
> Here is a test which includes tests for japanese cases end tests for the euc 
> encoding (it maps to different encodings depending on language).

Thanks. I think this is good enough now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:47:41 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 21:47:41 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388094460.99.0.358309965495.issue20075@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed. However in Modules/_io/_iomodule.c:

PyDoc_STRVAR(open_doc,
"open(file, mode='r', buffering=-1, encoding=None,\n"
"     errors=None, newline=None, closefd=True, opener=None) -> file object\n"
"\n"
"Open file and return a stream.  Raise IOError upon failure.\n"
...

Perhaps Larry has relations to this.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Thu Dec 26 23:01:32 2013
From: report at bugs.python.org (Meador Inge)
Date: Thu, 26 Dec 2013 22:01:32 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388095292.85.0.54074583757.issue20075@psf.upfronthosting.co.za>


Meador Inge added the comment:

Looks like the changes from 78ec18f5cb45 attempt to skip the signature,
but can't handle multi-line signatures.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Thu Dec 26 23:47:30 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Dec 2013 22:47:30 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <106779183.O53krBhlYm@raxxla>
Message-ID: <52BCB1FC.4080006@egenix.com>


Marc-Andre Lemburg added the comment:

On 26.12.2013 23:19, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
>> I probably wasn't clear: I meant some tests that show that the
>> alias definitions (on the left) from the X11 file are actually mapped to the
>> correct alias locales (on the right).
> 
> This is how the optimization function works. It updates alias table with the 
> X11 file, and then removes the alias entities one by one and checks that the 
> alias definition are mapped to to correct alias locales.
> 
> Here is a patch which adds a self-check in the makelocalealias.py script.

Thanks, this makes that part of the implementation waterproof as well.

Good to go, I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Thu Dec 26 23:57:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Dec 2013 22:57:05 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>
Message-ID: <3dr64J5qk7z7Ljn@mail.python.org>


Roundup Robot added the comment:

New changeset 63bc68d7f449 by Serhiy Storchaka in branch 'default':
Issue #20046: Locale alias table no longer contains entities which can be
http://hg.python.org/cpython/rev/63bc68d7f449

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Fri Dec 27 00:00:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 23:00:11 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <1387653657.74.0.379588693101.issue20046@psf.upfronthosting.co.za>
Message-ID: <1388098811.25.0.73391176753.issue20046@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Marc-Andre for your reviews.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________

From report at bugs.python.org  Fri Dec 27 00:29:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 23:29:09 +0000
Subject: [issue20076] Add UTF-8 locale aliases
Message-ID: <1388100548.94.0.295897364372.issue20076@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The makelocalealias.py ignores UTF-8 mapping. Expected that this encoding is available for all locales. After enabling UTF-8 mapping in makelocalealias.py most aliases are optimized out except following:

+    'be_bg.utf8':                           'bg_BG.UTF-8',
+    'c.utf8':                               'en_US.UTF-8',
+    'en_dl.utf8':                           'en_DL.UTF-8',
+    'en_zw.utf8':                           'en_ZS.UTF-8',
+    'ks_in at devanagari.utf8':                'ks_IN.UTF-8 at devanagari',
+    'pa_pk.utf8':                           'pa_PK.UTF-8',
+    'sd_in at devanagari.utf8':                'sd_IN.UTF-8 at devanagari',
+    'sr_yu.utf8':                           'sr_RS.UTF-8',
+    'sr_yu.utf8 at cyrillic':                  'sr_RS.UTF-8',
+    'te_in.utf8':                           'te_IN.UTF-8',
+    'zh_sg.utf8':                           'zh_SG.UTF-8',

Some of them maps to other country (en_zw.utf8 to en_ZS.UTF-8, sr_yu.utf8 to sr_RS.UTF-8) and these mappings are different from base mappings (en_zw to en_ZW.ISO8859-1, sr_yu to sr_RS.UTF-8 at latin). The devanagari mappings just maps illformed locales. c.utf8 is yet one special case. Other mappings have no base entity without encoding.

Here is a patch which enables UTF-8 mapping in makelocalealias.py and adds all these mappings to locale alias table.

----------
components: Library (Lib)
files: locale_utf8_aliases.patch
keywords: patch
messages: 206974
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add UTF-8 locale aliases
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33275/locale_utf8_aliases.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20076>
_______________________________________

From report at bugs.python.org  Fri Dec 27 01:21:10 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 27 Dec 2013 00:21:10 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388103670.9.0.0359519435121.issue20075@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Hi guys,

probably this patch can fix it?

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33276/20075.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 01:53:17 2013
From: report at bugs.python.org (Sophie Chancheong)
Date: Fri, 27 Dec 2013 00:53:17 +0000
Subject: [issue20054] IDLE won't work (Mac)
In-Reply-To: <1387808634.38.0.491200238888.issue20054@psf.upfronthosting.co.za>
Message-ID: <1388105597.12.0.0788637041655.issue20054@psf.upfronthosting.co.za>


Sophie Chancheong added the comment:

Sorry for not replying,

I followed the solution on the other thread and got it to work! Thank you so much for your help!!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20054>
_______________________________________

From report at bugs.python.org  Fri Dec 27 02:16:10 2013
From: report at bugs.python.org (Mitchell Model)
Date: Fri, 27 Dec 2013 01:16:10 +0000
Subject: [issue20077] Format of TypeError differs between comparison and
 arithmetic operators
Message-ID: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za>


New submission from Mitchell Model:

[ctypes correct component for this?]

The TypeError messages given for incompatible types in comparison operators differ from incompatible types in arithmetic operators. The arithmetic operator error messages show the names of the types in single quotes, while the comparison error messages do not use quotes but follow the name of the type with a pair of parens. Seems like these should be analogous.

 class foo(): pass
... 
>>> foo() + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'foo' and 'int'
>>> foo() < 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: foo() < int()

----------
components: ctypes
messages: 206977
nosy: MLModel
priority: normal
severity: normal
status: open
title: Format of TypeError differs between comparison and arithmetic operators
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20077>
_______________________________________

From report at bugs.python.org  Fri Dec 27 03:11:20 2013
From: report at bugs.python.org (Nandiya)
Date: Fri, 27 Dec 2013 02:11:20 +0000
Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite
 loop on maliciously binary edited zips
Message-ID: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za>


New submission from Nandiya:

I am using the zipfile module on a webserver which provides a service which processes files in zips uploaded by users, while hardening against zip bombs, I tried binary editing a zip to put in false file size information. The result is interesting, when with a ZIP_STORED file, or with carefully crafted ZIP_DEFLATED file (and perhaps ZIP_BZIP2 and ZIP_LZMA for craftier hackers than I), when the stated file size exceeds the size of the archive itself, ZipExtFile.read goes into an infinite loop, consuming 100% CPU.

The following methods on such an archive all result in an infinite loop:
ZipExtFile.read
ZipExtFile.read(n)
ZipExtFile.readlines
ZipFile.extract
ZipFile.extractall


ZipExtFile.read1 silently returns corrupt data but does not hang.

Obviously the module doesn't need to bend over backwards to deal gracefully with deliberately and maliciously crafted input, since all the user hopes for is to bring the program crashing down, but the 100% CPU infinite loop is probably one of the less satisfactory possible failure modes. It should either raise an exception or do something like read1 and silently return corrupt data.

This is low priority except for security since unless a zip is maliciously crafted some kind of exception will almost certainly be raised due to a decompression or invalid zip exception.

----------
components: IO, Library (Lib)
files: malzip.py
messages: 206978
nosy: nandiya
priority: normal
severity: normal
status: open
title: zipfile - ZipExtFile.read goes into 100% CPU infinite loop on maliciously binary edited zips
type: security
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file33277/malzip.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20078>
_______________________________________

From report at bugs.python.org  Fri Dec 27 05:04:29 2013
From: report at bugs.python.org (Julian Gindi)
Date: Fri, 27 Dec 2013 04:04:29 +0000
Subject: [issue19683] test_minidom has many empty tests
In-Reply-To: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>
Message-ID: <1388117069.21.0.668748551833.issue19683@psf.upfronthosting.co.za>


Julian Gindi added the comment:

Modernizing these tests will be a decent undertaking but seems important. I'll go a head and try to fix these up further. Thanks for the guidance and motivation on this one :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19683>
_______________________________________

From report at bugs.python.org  Fri Dec 27 05:44:10 2013
From: report at bugs.python.org (Dolda2000)
Date: Fri, 27 Dec 2013 04:44:10 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388119450.73.0.900253854476.issue20074@psf.upfronthosting.co.za>


Dolda2000 added the comment:

>I don't think getpass will fail, since it uses os.open, not open.

It also uses fdopen() on the resulting file descriptor, however, which has the same problem.

>Use unbuffered binary file.

It's nice that that's at least possible, but I, for one, would still consider it a bug that it isn't possible to open it in text mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 07:11:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 27 Dec 2013 06:11:43 +0000
Subject: [issue20076] Add UTF-8 locale aliases
In-Reply-To: <1388100548.94.0.295897364372.issue20076@psf.upfronthosting.co.za>
Message-ID: <1388124703.92.0.0248955668402.issue20076@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/issue20076>
_______________________________________

From report at bugs.python.org  Fri Dec 27 08:07:34 2013
From: report at bugs.python.org (Dolda2000)
Date: Fri, 27 Dec 2013 07:07:34 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388128054.71.0.699710478113.issue20074@psf.upfronthosting.co.za>


Dolda2000 added the comment:

Just to demonstrate failure of getpass, by the way:

$ cat >/tmp/pwtest.py
import getpass
print(getpass.getpass())
$ python3 /tmp/pwtest.py </dev/null
/usr/lib/python3.3/getpass.py:83: GetPassWarning: Can not control echo on the terminal.
  passwd = fallback_getpass(prompt, stream)
Warning: Password input may be echoed.
Password: Traceback (most recent call last):
  File "/usr/lib/python3.3/getpass.py", line 63, in unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
termios.error: (25, 'Inappropriate ioctl for device')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/pwtest.py", line 2, in <module>
    print(getpass.getpass())
  File "/usr/lib/python3.3/getpass.py", line 83, in unix_getpass
    passwd = fallback_getpass(prompt, stream)
  File "/usr/lib/python3.3/getpass.py", line 118, in fallback_getpass
    return _raw_input(prompt, stream)
  File "/usr/lib/python3.3/getpass.py", line 134, in _raw_input
    raise EOFError
EOFError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 08:42:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 07:42:45 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388130165.59.0.999570456648.issue20074@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> It's nice that that's at least possible, but I, for one, would still consider it a bug that it isn't possible to open it in text mode.

>>> io.TextIOWrapper(open("/dev/tty", "r+b", buffering=0))
<_io.TextIOWrapper name='/dev/tty' encoding='UTF-8'>

> Just to demonstrate failure of getpass, by the way:

Looks as this was fixed in issue18116 for 3.4. David, perhaps issue18116 should be backported to older Python versions.

----------
nosy: +benjamin.peterson, hynek, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 08:49:02 2013
From: report at bugs.python.org (Dolda2000)
Date: Fri, 27 Dec 2013 07:49:02 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388130542.6.0.716968699634.issue20074@psf.upfronthosting.co.za>


Dolda2000 added the comment:

Python 3.3.3 (default, Dec  8 2013, 14:51:59) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import io
>>> io.TextIOWrapper(open("/dev/tty", "rb+"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
io.UnsupportedOperation: File or stream is not seekable.

Was this also fixed in 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 08:55:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 07:55:03 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388130903.74.0.763084044212.issue20075@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 09:13:36 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 27 Dec 2013 08:13:36 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388132016.63.0.803185604911.issue20075@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

The patch does not fix it. It becomes like this:

open(...)
    Open file and return a stream.  Raise IOError upon failure.

It's not just help(open) has problem, help(sqlite3.connect) got it as well:

connect(...)
    check_same_thread, factory, cached_statements, uri])
    
    Opens a connection to the SQLite database file *database*. You can use

----------
nosy: +vajrasky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 09:45:46 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 Dec 2013 08:45:46 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1388133946.75.0.825546293796.issue19944@psf.upfronthosting.co.za>


Eric Snow added the comment:

Any thoughts on the latest patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Fri Dec 27 10:08:21 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 09:08:21 +0000
Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite
 loop on maliciously binary edited zips
In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za>
Message-ID: <1388135301.42.0.637072996835.issue20078@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20078>
_______________________________________

From report at bugs.python.org  Fri Dec 27 10:42:36 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 27 Dec 2013 09:42:36 +0000
Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite
 loop on maliciously binary edited zips
In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za>
Message-ID: <1388137356.27.0.726275769703.issue20078@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20078>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:12:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 10:12:28 +0000
Subject: [issue20079] Add support for glibc supported locales
Message-ID: <1388139147.62.0.637898307439.issue20079@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds to locale alias table the mappings for locales supported in recent glibc (v 2.18). It also modifies the makelocalealias.py script so that it parses the SUPPORTED file from glibc sources and supports command line options for source paths.

----------
components: Library (Lib)
files: locale_glibc_supported.patch
keywords: patch
messages: 206987
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for glibc supported locales
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33278/locale_glibc_supported.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20079>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:14:05 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 10:14:05 +0000
Subject: [issue20079] Add support for glibc supported locales
In-Reply-To: <1388139147.62.0.637898307439.issue20079@psf.upfronthosting.co.za>
Message-ID: <1388139245.61.0.664536780728.issue20079@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Totally added 100 new mappings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20079>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:35:00 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Dec 2013 10:35:00 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388140500.98.0.21728038592.issue20075@psf.upfronthosting.co.za>


Larry Hastings added the comment:

The best fix would be to convert the docstrings to something inspect can parse.  Preferably by converting the functions to use Argument Clinic, though you could manually mark up the docstring by hand if necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 11:56:02 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 27 Dec 2013 10:56:02 +0000
Subject: [issue20080] Unused variable in Lib/sqlite3/test/factory.py
Message-ID: <1388141762.46.0.0728784342465.issue20080@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

There is unused variable t in Lib/sqlite3/test/factory.py.

    def CheckSqliteRowAsTuple(self):
        """Checks if the row object can be converted to a tuple"""
        self.con.row_factory = sqlite.Row
        row = self.con.execute("select 1 as a, 2 as b").fetchone()
        t = tuple(row)

    def CheckSqliteRowAsDict(self):

Attached the patch to give the purpose to variable t.

----------
components: Tests
files: unused_variable_in_factory_py.patch
keywords: patch
messages: 206990
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Unused variable in Lib/sqlite3/test/factory.py
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33279/unused_variable_in_factory_py.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20080>
_______________________________________

From report at bugs.python.org  Fri Dec 27 14:03:56 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 13:03:56 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388130542.6.0.716968699634.issue20074@psf.upfronthosting.co.za>
Message-ID: <1938721.BRsFbur4G7@raxxla>


Serhiy Storchaka added the comment:

> >>> import io
> >>> io.TextIOWrapper(open("/dev/tty", "rb+"))
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> io.UnsupportedOperation: File or stream is not seekable.

buffering=0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 14:05:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 13:05:45 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388140500.98.0.21728038592.issue20075@psf.upfronthosting.co.za>
Message-ID: <2285809.yi6YseUnXv@raxxla>


Serhiy Storchaka added the comment:

> The best fix would be to convert the docstrings to something inspect can
> parse.  Preferably by converting the functions to use Argument Clinic,
> though you could manually mark up the docstring by hand if necessary.

We can't check all docstrings in the stdlib and in all third-party libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:04:14 2013
From: report at bugs.python.org (Mikael Knutsson)
Date: Fri, 27 Dec 2013 14:04:14 +0000
Subject: [issue9351] argparse set_defaults on subcommands should override top
 level set_defaults
In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za>
Message-ID: <1388153054.04.0.990765896769.issue9351@psf.upfronthosting.co.za>


Mikael Knutsson added the comment:

Just wanted to drop in here to let you know that I hit this behaviour recently when writing a small tool using both configparser and argparse and the workaround proves rather annoying (custom namespace object or similar).

Would be awesome if this moved forward with the proposed patch!

----------
nosy: +mikn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9351>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:12:39 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 27 Dec 2013 14:12:39 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388153558.99.0.532609392104.issue20075@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Yes, so basically signature line in help(open) is not shown because ast.parse fails to parse the return value

-> file object

According to grammar, it should be 
-> file 
or 
-> 'file object' 
or something like this.

as for sqlite, it fails to parse square brackets:

connect(database[, timeout, detect_types, isolation_level,\n\
        check_same_thread, factory, cached_statements, uri])

As an idea, maybe we can come up with a failover i.e. if ast can't parse the signature, just use __text_signature__ instead of signature object:

Lib/pydoc.py:1325
if not argspec:
-   argspec = '(...)'
+   argspec = object.__text_signature__


Or probably just don't show the signature if it is not formatted correctly as it is now (after the patch applied).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 15:14:09 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Dec 2013 14:14:09 +0000
Subject: [issue19944] Make importlib.find_spec load packages as needed
In-Reply-To: <1386678541.87.0.362363609573.issue19944@psf.upfronthosting.co.za>
Message-ID: <1388153649.01.0.216906008434.issue19944@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The "simple" patch actually looks like a good way to end up with find_spec specific bugs because it diverges from the more thoroughly tested main import path (e.g. it looks to me like it doesn't release the import lock properly)

So the _FoundSpec version actually looks better to me, because it keeps find_spec more inline with actual imports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19944>
_______________________________________

From report at bugs.python.org  Fri Dec 27 16:41:40 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 27 Dec 2013 15:41:40 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388158900.78.0.626425734745.issue20075@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The patch looks good to me (aside from extra whitespace on the blank lines in methodobject.c, and I agree with Serhiy about s/brackets/parens/).  Also, I like the suggestion of using __text_signature__ instead of '(...)'.  However, just to avoid any possible issues with __text_signature__ being blank or missing, I would go with `argspec = getattr(object, '__text_signature__', '') or '(...)'` instead of straight `object.__text_signature__` (and note that there are two places to change in pydoc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 16:56:31 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 27 Dec 2013 15:56:31 +0000
Subject: [issue20080] Unused variable in Lib/sqlite3/test/factory.py
In-Reply-To: <1388141762.46.0.0728784342465.issue20080@psf.upfronthosting.co.za>
Message-ID: <1388159791.02.0.0882139548415.issue20080@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think you want to either also testing the number of elements in t, or in just compare t to (row["a"], row["b"]) (untested).

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20080>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:31:55 2013
From: report at bugs.python.org (Dolda2000)
Date: Fri, 27 Dec 2013 16:31:55 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388161915.45.0.277991420787.issue20074@psf.upfronthosting.co.za>


Dolda2000 added the comment:

Oh sorry, my bad. I messed up. :)

Given that that works, though, why can't open() handle opening /dev/tty directly in text mode? Clearly, TextIOWrapper can handle the necessary buffering without the stream having to be seekable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:48:22 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Dec 2013 16:48:22 +0000
Subject: [issue18116] getpass.unix_getpass() always fallback to sys.stdin
In-Reply-To: <1370130607.39.0.486408621645.issue18116@psf.upfronthosting.co.za>
Message-ID: <3drYrP6JPyz7Lk3@mail.python.org>


Roundup Robot added the comment:

New changeset 100f632d4306 by R David Murray in branch '3.3':
#18116: backport fix to 3.3 since real-world failure mode demonstrated.
http://hg.python.org/cpython/rev/100f632d4306

New changeset 29a5a5b39dd6 by R David Murray in branch 'default':
Mostly-null merge of #18116 backport (updated NEWS entry).
http://hg.python.org/cpython/rev/29a5a5b39dd6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18116>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:48:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Dec 2013 16:48:23 +0000
Subject: [issue17484] add tests for getpass
In-Reply-To: <1363731601.11.0.00161818926238.issue17484@psf.upfronthosting.co.za>
Message-ID: <3drYrQ4bpNz7Lk3@mail.python.org>


Roundup Robot added the comment:

New changeset 100f632d4306 by R David Murray in branch '3.3':
#18116: backport fix to 3.3 since real-world failure mode demonstrated.
http://hg.python.org/cpython/rev/100f632d4306

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17484>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:48:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Dec 2013 16:48:23 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <3drYrR3KcHz7Lkj@mail.python.org>


Roundup Robot added the comment:

New changeset 100f632d4306 by R David Murray in branch '3.3':
#18116: backport fix to 3.3 since real-world failure mode demonstrated.
http://hg.python.org/cpython/rev/100f632d4306

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 17:54:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Dec 2013 16:54:26 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388163266.97.0.950543744422.issue20074@psf.upfronthosting.co.za>


R. David Murray added the comment:

Having buffering doesn't make the stream seekable.  So the question is, is the *design* of the IO module that '+' requires a seekable stream the best behavior, or can that constraint be relaxed?  You have to keep in mind that the IO module is a bunch of building blocks, which are plugged together automatically for the most common scenarios.  The goal is a portable, consistent IO system, not one that completely mimics unix/C IO primitives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 18:01:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Dec 2013 17:01:27 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388163266.97.0.950543744422.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388163685.2298.5.camel@fsol>


Antoine Pitrou added the comment:

> Having buffering doesn't make the stream seekable.  So the question
> is, is the *design* of the IO module that '+' requires a seekable
> stream the best behavior, or can that constraint be relaxed?

A non-seekable read/write stream doesn't really make sense (think about
it).
What you may be thinking about, instead, is a pair of non-seekable
streams, one readable and one writable. There is BufferedRWPair for
that:
http://docs.python.org/dev/library/io.html#io.BufferedRWPair

(granted, BufferedRWPair isn't wired in open(), so you have to do all
the wrapping yourself)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 18:08:13 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 27 Dec 2013 17:08:13 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388164093.92.0.368206377055.issue20075@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Thank you for the comments! I'll update the patch.


BTW is it safe to update Lib/inspect.py:2004 ?

- return cls(parameters, return_annotation=cls.empty)
+ return cls(parameters, return_annotation=f.returns.s or cls.empty)

Looks like the return value is not shown in signature (if it parsed correctly) because currently we explicitly pass cls.empty instance, but if we'd pass f.returns.s, the return value is shown.

Or it is correct behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 18:45:42 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 27 Dec 2013 17:45:42 +0000
Subject: [issue20081] sys.getwindowsversion does nto show some fields
Message-ID: <1388166342.38.0.63182866145.issue20081@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

On Windows 7:

>>> v = sys.getwindowsversion()
>>> v
sys.getwindowsversion(major=6, minor=1, build=7600, platform=2, service_pack='')
>>> v.service_pack_major
0
>>> v.service_pack_minor
0
>>> v.suite_mask
254

Doc states:

> For compatibility with prior versions, only the first 5 elements are retrievable by indexing.

...so I guess that's why service_pack_minor, service_pack_major and suite_mask fields are not shown.
Nevertheless I think this is a inconvenience which should be fixed, at least in the next major Python version.

----------
messages: 207005
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: sys.getwindowsversion does nto show some fields
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20081>
_______________________________________

From report at bugs.python.org  Fri Dec 27 18:49:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Dec 2013 17:49:51 +0000
Subject: [issue20081] sys.getwindowsversion does not show some fields
In-Reply-To: <1388166342.38.0.63182866145.issue20081@psf.upfronthosting.co.za>
Message-ID: <1388166591.82.0.196119368186.issue20081@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: sys.getwindowsversion does nto show some fields -> sys.getwindowsversion does not show some fields

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20081>
_______________________________________

From report at bugs.python.org  Fri Dec 27 19:15:33 2013
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 27 Dec 2013 18:15:33 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1388168133.43.0.158530410734.issue20059@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/issue20059>
_______________________________________

From report at bugs.python.org  Fri Dec 27 19:16:16 2013
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 27 Dec 2013 18:16:16 +0000
Subject: [issue20050] distutils should check PyPI certs when connecting to it
In-Reply-To: <1387673525.81.0.630232623355.issue20050@psf.upfronthosting.co.za>
Message-ID: <1388168176.86.0.569460522882.issue20050@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/issue20050>
_______________________________________

From report at bugs.python.org  Fri Dec 27 19:18:25 2013
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 27 Dec 2013 18:18:25 +0000
Subject: [issue20078] zipfile - ZipExtFile.read goes into 100% CPU infinite
 loop on maliciously binary edited zips
In-Reply-To: <1388110280.6.0.508484621949.issue20078@psf.upfronthosting.co.za>
Message-ID: <1388168305.13.0.162738060721.issue20078@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/issue20078>
_______________________________________

From report at bugs.python.org  Fri Dec 27 19:37:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Dec 2013 18:37:11 +0000
Subject: [issue20081] sys.getwindowsversion does not show some fields
In-Reply-To: <1388166342.38.0.63182866145.issue20081@psf.upfronthosting.co.za>
Message-ID: <1388169431.11.0.342452165546.issue20081@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is essentially a duplicate of item (3) in issue 1820, although I'm not entirely clear on what the repr would actually look like.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20081>
_______________________________________

From report at bugs.python.org  Fri Dec 27 19:57:13 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 27 Dec 2013 18:57:13 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388170633.94.0.763535040675.issue20075@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

So, looks like it works for me and all tests pass.
Here's a new patch.
Feel free to revert Lib/inspect.py:2004-2009 if this is incorrect behavior.

----------
Added file: http://bugs.python.org/file33280/20075-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 20:11:25 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 27 Dec 2013 19:11:25 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388171485.58.0.281621469404.issue20075@psf.upfronthosting.co.za>


Larry Hastings added the comment:

One of the relevant PEPs (PEP 8?  PEP 7?  the annotations PEP?) states that the Python standard library is not permitted to use annotations.  And considering that Argument Clinic is an internal-only tool, we could probably justify the decision to not allow annotations to creep through.

That said, I think it's harmless, and it might be useful to somebody, so go ahead and propagate the annotation from the __text_signature__ into inspect.Signature if we get a valid one.  But please create a separate issue for it.  (I encourage you to cut-and-paste this text into the description of that new issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Fri Dec 27 20:59:52 2013
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 27 Dec 2013 19:59:52 +0000
Subject: [issue1565525] tracebacks eat up memory by holding references to
 locals and globals when they are not wanted
Message-ID: <1388174392.17.0.260884401373.issue1565525@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <amk at amk.ca>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1565525>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:29:54 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Dec 2013 20:29:54 +0000
Subject: [issue20062] Add section on vim to devguide
In-Reply-To: <1387898616.8.0.449305088689.issue20062@psf.upfronthosting.co.za>
Message-ID: <1388176194.32.0.951085527083.issue20062@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

I think there should not be any section about any editor in the devguide. It's beyond scope, and it risks going stale.

----------
nosy: +tshepang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20062>
_______________________________________

From report at bugs.python.org  Fri Dec 27 21:37:38 2013
From: report at bugs.python.org (Dolda2000)
Date: Fri, 27 Dec 2013 20:37:38 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388176658.42.0.365420743595.issue20074@psf.upfronthosting.co.za>


Dolda2000 added the comment:

>So the question is, is the *design* of the IO module that '+' requires a seekable stream the best behavior, or can that constraint be relaxed?

What purpose does that constraint serve? Is there any reason it shouldn't be relaxed?

It seems to work quite well without it in Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 22:27:15 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Dec 2013 21:27:15 +0000
Subject: [issue20042] Python Launcher, Windows,
 fails on scripts w/ non-latin names
In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za>
Message-ID: <1388179635.17.0.636851010237.issue20042@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Python Launcher for Windows fails to invoke scripts with non-latin names -> Python Launcher, Windows, fails on scripts w/ non-latin names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20042>
_______________________________________

From report at bugs.python.org  Fri Dec 27 22:30:27 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Dec 2013 21:30:27 +0000
Subject: [issue20062] Add section on vim to devguide
In-Reply-To: <1387898616.8.0.449305088689.issue20062@psf.upfronthosting.co.za>
Message-ID: <1388179827.24.0.245240747839.issue20062@psf.upfronthosting.co.za>


R. David Murray added the comment:

We have pointers to external resources all over the docs.  Yes, they go stale sometimes, and when somebody notices, we update them.  "What do you use for development" is a common topic of discussion, so I don't see any reason not to include some pointers in the devguide.  (Not tutorials, just pointers to resources.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20062>
_______________________________________

From report at bugs.python.org  Fri Dec 27 22:36:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Dec 2013 21:36:12 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388180172.28.0.105226049235.issue20074@psf.upfronthosting.co.za>


R. David Murray added the comment:

Antoine already answered that question: it does not make sense to have a single stream that is open for *update* if it is not seekable.  The fact C conflates "update" with "both read and write" can be seen as a design bug in C :)
 
The remaining question might be: is there a sensible way (that fits with the design of the IO system) to hook BufferedRWPair up to open?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20074>
_______________________________________

From report at bugs.python.org  Fri Dec 27 23:29:13 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Dec 2013 22:29:13 +0000
Subject: [issue20077] Format of TypeError differs between comparison and
 arithmetic operators
In-Reply-To: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za>
Message-ID: <1388183353.2.0.268728640828.issue20077@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Interpreter Core -ctypes
nosy: +ncoghlan
versions: +Python 3.5 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20077>
_______________________________________

From report at bugs.python.org  Fri Dec 27 23:38:14 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 27 Dec 2013 22:38:14 +0000
Subject: [issue20077] Format of TypeError differs between comparison and
 arithmetic operators
In-Reply-To: <1388106970.8.0.6745803605.issue20077@psf.upfronthosting.co.za>
Message-ID: <1388183894.37.0.296567620992.issue20077@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

I created a patch for it, please review

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file33281/20077.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20077>
_______________________________________

From report at bugs.python.org  Sat Dec 28 00:25:28 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 27 Dec 2013 23:25:28 +0000
Subject: [issue20075] help(open) eats first line
In-Reply-To: <1388090120.87.0.478863756961.issue20075@psf.upfronthosting.co.za>
Message-ID: <1388186728.46.0.589132466251.issue20075@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

I'm sorry, I'm not sure I caught the idea. So, I need to create an issue with description

"propagate the annotation from the __text_signature__ into inspect.Signature if we get a valid one." ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20075>
_______________________________________

From report at bugs.python.org  Sat Dec 28 00:33:13 2013
From: report at bugs.python.org (Erik Bray)
Date: Fri, 27 Dec 2013 23:33:13 +0000
Subject: [issue20082] Misbehavior of BufferedRandom.write with raw file in
 append mode
Message-ID: <1388187192.84.0.682821163597.issue20082@psf.upfronthosting.co.za>


New submission from Erik Bray:

In #18876 I pointed out the following issue:

BufferedWriter/Random doesn't know the raw file was opened with O_APPEND so the writes it shows in the buffer differ from what will actually end up in the file.  For example:

>>> f = open('test', 'wb')
>>> f.write(b'testest')
7
>>> f.close()
>>> f = open('test', 'ab+')
>>> f.tell()
7
>>> f.write(b'A')
1
>>> f.seek(0)
0
>>> f.read()
b'testestA'
>>> f.seek(0)
0
>>> f.read(1)
b't'
>>> f.write(b'B')
1
>>> f.seek(0)
0
>>> f.read()
b'tBstestA'
>>> f.flush()
>>> f.seek(0)
0
>>> f.read()
b'testestAB'

In this example, I read 1 byte from the beginning of the file, then write one byte.  Because of O_APPEND, the effect of the write() call on the raw file is to append, regardless of where BufferedWriter seeks it to first.  But before the f.flush() call f.read() just shows what's in the buffer which is not what will actually be written to the file.  (Naturally, unbuffered io does not have this particular problem.)


Now that #18876 we can test if a file was opened in append mode and correct for this.  The attach patch includes a pretty simple solution that manually calls buffered_seek at the beginning of bufferedwriter_write if the raw file is in append mode.  In doing so it made sense to split buffered_seek into two separate functions.

This might be overkill, however.

----------
components: IO
files: buffered-append-1.patch
keywords: patch
messages: 207015
nosy: erik.bray
priority: normal
severity: normal
status: open
title: Misbehavior of BufferedRandom.write with raw file in append mode
type: behavior
Added file: http://bugs.python.org/file33282/buffered-append-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20082>
_______________________________________

From report at bugs.python.org  Sat Dec 28 02:38:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 28 Dec 2013 01:38:25 +0000
Subject: [issue20062] Add section on vim to devguide
In-Reply-To: <1387898616.8.0.449305088689.issue20062@psf.upfronthosting.co.za>
Message-ID: <1388194705.92.0.850665117583.issue20062@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I don't think the devguide is a good place for this unless some editors support features that are particularly interesting for CPython development (e.g. something to check refleaks).
If the features are generic enough that any Python programmer would find them interesting, something could be said in the Python FAQs [0] or the wiki [1].  The FAQs already mention this briefly and have a link to the wiki.

[0]: http://docs.python.org/3/faq/general.html
[1]: https://wiki.python.org/moin/PythonEditors

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20062>
_______________________________________

From report at bugs.python.org  Sat Dec 28 02:49:23 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 01:49:23 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
Message-ID: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>


New submission from Freek Dijkstra:

smtplib has limited support for non-ASCII domain names in the From to To mail address. It only works for punycode-encoded domain names, submitted as unicode string (e.g. server.rcpt(u"user at xn--e1afmkfd.ru").

The following two calls fail:

server.rcpt(u"user@??????.ru"):
  File smtplib.py, line 332, in send
    s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode character '\u03c0' in position 19: ordinal not in range(128)
http://hg.python.org/cpython/file/3.3/Lib/smtplib.py#l332

server.rcpt(b"user at xn--e1afmkfd.ru"):
  File email/_parseaddr.py, line 236, in gotonext
    if self.field[self.pos] in self.LWS + '\n\r':
TypeError: 'in <string>' requires string as left operand, not int
http://hg.python.org/cpython/file/3.3/Lib/email/_parseaddr.py#l236

There are three ways to solve this (from trivial to complex):
* Make it clear in the documentation what type of input is expected.
* Accept punycode-encoded domain names in email addresses, either in string or binary format.
* Accept Unicode-encoded domain names, and do the punycode encoding in the smtplib if required.

See also 

References:
https://tools.ietf.org/html/rfc5891: Internationalized Domain Names in Applications (IDNA): Protocol

----------
components: Library (Lib)
messages: 207017
nosy: macfreek
priority: normal
severity: normal
status: open
title: smtplib: support for IDN (international domain names)
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 02:51:55 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 01:51:55 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
Message-ID: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>


New submission from Freek Dijkstra:

smtplib has no support for non-ASCII user names in the From to To mail address.

The following two calls fail:

server.rcpt(u"?????@example.com"):
  File smtplib.py, line 332, in send
    s = s.encode("ascii")
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128)
http://hg.python.org/cpython/file/3.3/Lib/smtplib.py#l332

server.rcpt(b'\xcf\x8c\xce\xbd\xce\xbf\xce\xbc\xce\xb1 at example.com'):
  File email/_parseaddr.py, line 236, in gotonext
    if self.field[self.pos] in self.LWS + '\n\r':
TypeError: 'in <string>' requires string as left operand, not int
http://hg.python.org/cpython/file/3.3/Lib/email/_parseaddr.py#l236

There are two ways to solve this:
* Allow users of smptlib to support internationalised email by passing already encoded headers and email addresses. The users is responsible for the encoding and setting the SMTPUTF8 ESMTP option.
* Accept Unicode-encoded email addresses, and convert that to UTF-8 in the library. smtplib is responsible for the encoding and setting the SMTPUTF8 ESMTP option.

References:
https://tools.ietf.org/html/rfc6531: SMTP Extension for Internationalized Email

See also Issue20083, which deals with international domain names in email addresses (the part behind the "@"). This issue deals with the part before the "@".

Note that this is different from RFC 2047, which merely allows non-ASCII encoding in text values in the headers (such as the name of a recipient or the mail subject).

----------
components: Library (Lib)
messages: 207018
nosy: macfreek
priority: normal
severity: normal
status: open
title: smtplib: support for UTF-8 encoded headers (SMTPUTF8)
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sat Dec 28 02:53:10 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 01:53:10 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
In-Reply-To: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>
Message-ID: <1388195590.26.0.203998893942.issue20083@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

This issue deals with international domain names in email addresses (the part behind the "@"). See issue 20084 for the issue that deals with the part before the "@".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 03:16:57 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Dec 2013 02:16:57 +0000
Subject: [issue4492] httplib code thinks it closes connection, but does not
In-Reply-To: <1228241719.92.0.946688230988.issue4492@psf.upfronthosting.co.za>
Message-ID: <1388197017.07.0.684098985829.issue4492@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/issue4492>
_______________________________________

From report at bugs.python.org  Sat Dec 28 03:47:37 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Dec 2013 02:47:37 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1388198857.28.0.544495035302.issue7464@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sounds like urlopen() is relying on garbage collection to close the socket and connection. Maybe it would be better to explicitly close the socket, even if you do eliminate all the garbage reference cycles.

My test code for Issue 19524 might be useful here. It verifies close() has been called on the HTTP socket.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:01:32 2013
From: report at bugs.python.org (stubz)
Date: Sat, 28 Dec 2013 03:01:32 +0000
Subject: [issue20085] Python2.7, wxPython and IDLE 2.7
Message-ID: <1388199692.1.0.186486001282.issue20085@psf.upfronthosting.co.za>


New submission from stubz:

I new to this so I have no idea what's going on ...
I'm using Mint 16 Cinnamon and apparently Python 2.7+ 3.3 are installed
I started puttering with wxPython 2.8 and I have issues ...

I started a tutorial, saved some work.py and got things to run, I guess ...

When I try to open and edit a work.py file I get a blank window ... ?

I also lose my number pad, auto indents and can't close that blank window, I basically have to show down the computer to get it to go away ...

I don't know if this is Mint, Python, IDLE or me, but it's annoying ...

Can anyone giving me an idea as to what's going on ?

----------
messages: 207021
nosy: stubz
priority: normal
severity: normal
status: open
title: Python2.7, wxPython and IDLE 2.7
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20085>
_______________________________________

From report at bugs.python.org  Sat Dec 28 04:27:09 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Dec 2013 03:27:09 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1388201229.92.0.878927791932.issue20059@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/issue20059>
_______________________________________

From report at bugs.python.org  Sat Dec 28 05:28:49 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Dec 2013 04:28:49 +0000
Subject: [issue20074] open() of read-write non-seekable streams broken
In-Reply-To: <1388088109.09.0.0894725958863.issue20074@psf.upfronthosting.co.za>
Message-ID: <1388204929.71.0.0871573172712.issue20074@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/issue20074>
_______________________________________

From report at bugs.python.org  Sat Dec 28 09:08:24 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 28 Dec 2013 08:08:24 +0000
Subject: [issue16778] Logger.findCaller needs to be smarter
In-Reply-To: <1356452428.01.0.563947098769.issue16778@psf.upfronthosting.co.za>
Message-ID: <1388218104.14.0.894098357605.issue16778@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


Added file: http://bugs.python.org/file33283/58f0edef2b19.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16778>
_______________________________________

From report at bugs.python.org  Sat Dec 28 09:15:56 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 28 Dec 2013 08:15:56 +0000
Subject: [issue16778] Logger.findCaller needs to be smarter
In-Reply-To: <1356452428.01.0.563947098769.issue16778@psf.upfronthosting.co.za>
Message-ID: <1388218556.24.0.0810647785881.issue16778@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Too late for 3.4 now, bumping to 3.5. Implementation now uses a set and '__name__' in f.f_globals to match module names passed in - this seems good enough. I plan to commit this as soon as default is updated to 3.5, unless there are alternative suggestions.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16778>
_______________________________________

From report at bugs.python.org  Sat Dec 28 09:18:27 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 28 Dec 2013 08:18:27 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1388218707.17.0.296815088744.issue9998@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Sat Dec 28 09:22:25 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 28 Dec 2013 08:22:25 +0000
Subject: [issue15452] Improve the security model for logging listener()
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1388218945.66.0.329880619523.issue15452@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Sat Dec 28 09:33:20 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 28 Dec 2013 08:33:20 +0000
Subject: [issue1521950] shlex.split() does not tokenize like the shell
Message-ID: <1388219600.48.0.362845196416.issue1521950@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Let's hope we can get this into 3.5. I updated my patch a while ago to address RDM's comments.

----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1521950>
_______________________________________

From report at bugs.python.org  Sat Dec 28 10:00:19 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 09:00:19 +0000
Subject: [issue20086] test_locale fails on PPC64 PowerLinux
Message-ID: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

See http://buildbot.python.org/all/builders/PPC64%20PowerLinux%202.7/builds/396/steps/test/logs/stdio.

======================================================================
ERROR: test_getsetlocale_issue1813 (test.test_locale.TestMiscellaneous)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/2.7.edelsohn-powerlinux-ppc64/build/Lib/test/test_locale.py", line 480, in test_getsetlocale_issue1813
    locale.setlocale(locale.LC_CTYPE, loc)
  File "/home/shager/cpython-buildarea/2.7.edelsohn-powerlinux-ppc64/build/Lib/locale.py", line 579, in setlocale
    return _setlocale(category, locale)
Error: unsupported locale setting

----------------------------------------------------------------------

----------
components: Library (Lib), Tests
messages: 207024
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_locale fails on PPC64 PowerLinux
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20086>
_______________________________________

From report at bugs.python.org  Sat Dec 28 10:29:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 09:29:49 +0000
Subject: [issue20087] Mismatch between glibc and X11 locale.alias
Message-ID: <1388222989.89.0.773650778168.issue20087@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The locale module uses locale alias table derived from X11 locale.alias file for mapping bare locale names without encodings to locale names with encodings. However sometimes glibc default encoding for a locale differs from that used in X11 locale.alias.

Here is full differences table:

                 GLibc                 X11 locale.alias

az_az            az_AZ.UTF-8           az_AZ.ISO8859-9E
ca_ad            ca_AD.ISO8859-15      ca_AD.ISO8859-1
ca_fr            ca_FR.ISO8859-15      ca_FR.ISO8859-1
ca_it            ca_IT.ISO8859-15      ca_IT.ISO8859-1
cy_gb            cy_GB.ISO8859-14      cy_GB.ISO8859-1
en_in            en_IN.UTF-8           en_IN.ISO8859-1
et_ee            et_EE.ISO8859-1       et_EE.ISO8859-15
fi_fi            fi_FI.ISO8859-1       fi_FI.ISO8859-15
gd_gb            gd_GB.ISO8859-15      gd_GB.ISO8859-1
hi_in            hi_IN.UTF-8           hi_IN.ISCII-DEV
iu_ca            iu_CA.UTF-8           iu_CA.NUNACOM-8
iw_il            iw_IL.ISO8859-8       he_IL.ISO8859-8
ka_ge            ka_GE.GEORGIAN_PS     ka_GE.GEORGIAN-ACADEMY
lo_la            lo_LA.UTF-8           lo_LA.MULELAO-1
mi_nz            mi_NZ.ISO8859-13      mi_NZ.ISO8859-1
nr_za            nr_ZA.UTF-8           nr_ZA.ISO8859-1
nso_za           nso_ZA.UTF-8          nso_ZA.ISO8859-15
ru_ru            ru_RU.ISO8859-5       ru_RU.UTF-8
rw_rw            rw_RW.UTF-8           rw_RW.ISO8859-1
sq_al            sq_AL.ISO8859-1       sq_AL.ISO8859-2
ss_za            ss_ZA.UTF-8           ss_ZA.ISO8859-1
ta_in            ta_IN.UTF-8           ta_IN.TSCII-0
tg_tj            tg_TJ.KOI8_T          tg_TJ.KOI8-C
th_th            th_TH.TIS_620         th_TH.ISO8859-11
tn_za            tn_ZA.UTF-8           tn_ZA.ISO8859-15
ts_za            ts_ZA.UTF-8           ts_ZA.ISO8859-1
tt_ru            tt_RU.UTF-8           tt_RU.TATAR-CYR
ur_pk            ur_PK.UTF-8           ur_PK.CP1256
uz_uz            uz_UZ.ISO8859-1       uz_UZ.UTF-8
uz_uz at cyrillic   uz_UZ.UTF-8 at cyrillic  uz_UZ.UTF-8
vi_vn            vi_VN.UTF-8           vi_VN.TCVN
zh_cn            zh_CN.GB2312          zh_CN.gb2312
zh_tw            zh_TW.BIG5            zh_TW.big5
zh_tw.euctw      zh_TW.EUC_TW          zh_TW.eucTW

For example with the en_IN encoding:

>>> import locale, _locale
>>> _locale.setlocale(locale.LC_CTYPE)
'en_IN'
>>> locale.getlocale()
('en_IN', 'ISO8859-1')
>>> locale.nl_langinfo(locale.CODESET)
'UTF-8'
>>> locale.setlocale(locale.LC_CTYPE, locale.getlocale())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 592, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

----------
components: Library (Lib)
messages: 207025
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Mismatch between glibc and X11 locale.alias
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20087>
_______________________________________

From report at bugs.python.org  Sat Dec 28 10:44:03 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 09:44:03 +0000
Subject: [issue20088] locale.getlocale() fails if locale name doesn't include
 encoding
Message-ID: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>>> import locale, _locale
>>> _locale.setlocale(locale.LC_CTYPE, 'en_AG')
'en_AG'
>>> _locale.setlocale(locale.LC_CTYPE)
'en_AG'
>>> locale.getlocale(locale.LC_CTYPE)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/locale.py", line 575, in getlocale
    return _parse_localename(localename)
  File "/home/serhiy/py/cpython/Lib/locale.py", line 484, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: en_AG

One solution is proposed in issue20079: map all supported in glibc locale names without encoding to locale names with encoding. But see issue20087. And default encoding can be different on other systems (not based on glibc).

Other solution is not guess an encoding, but use locale.nl_langinfo(locale.CODESET) in locale.getlocale(). And left in locale alias table only nonstandard mappings (such as english_uk -> en_GB.ISO8859-1 and sr_yu.iso88595 -> sr_CS.ISO8859-5).

----------
components: Library (Lib)
messages: 207026
nosy: lemburg, loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: locale.getlocale() fails if locale name doesn't include encoding
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20088>
_______________________________________

From report at bugs.python.org  Sat Dec 28 11:28:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 10:28:37 +0000
Subject: [issue20086] test_locale fails on PPC64 PowerLinux
In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za>
Message-ID: <1388226517.04.0.596214495635.issue20086@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20086>
_______________________________________

From report at bugs.python.org  Sat Dec 28 11:39:01 2013
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 28 Dec 2013 10:39:01 +0000
Subject: [issue20061] make pdb through separate terminal more convenient
In-Reply-To: <1387897760.7.0.840181972955.issue20061@psf.upfronthosting.co.za>
Message-ID: <1388227141.19.0.783959401553.issue20061@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/issue20061>
_______________________________________

From report at bugs.python.org  Sat Dec 28 13:32:17 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 28 Dec 2013 12:32:17 +0000
Subject: [issue20086] test_locale fails on PPC64 PowerLinux
In-Reply-To: <1388221219.09.0.925570468901.issue20086@psf.upfronthosting.co.za>
Message-ID: <1388233937.31.0.530735457806.issue20086@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I don't know why this fails exactly. I had a similar failure though that was fixed by using the @run_with_locale decorator.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20086>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:09:03 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 28 Dec 2013 14:09:03 +0000
Subject: [issue20089] email.message_from_string no longer working in Python 3.4
Message-ID: <1388239743.81.0.886859790367.issue20089@psf.upfronthosting.co.za>


New submission from Florian Apolloner:

Given this email:
---
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: =?utf-8?q?Ch=C3=A8re_maman?=
From: from at example.com
To: to at example.com
Date: Sat, 28 Dec 2013 13:08:07 -0000
Message-ID: <20131228130807.3669.79195 at localhost>

Je t'aime tr?s fort
---

I get this traceback:
---
  File "/home/florian/sources/cpython/Lib/email/__init__.py", line 40, in message_from_string
    return Parser(*args, **kws).parsestr(s)
  File "/home/florian/sources/cpython/Lib/email/parser.py", line 70, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "/home/florian/sources/cpython/Lib/email/parser.py", line 60, in parse
    return feedparser.close()
  File "/home/florian/sources/cpython/Lib/email/feedparser.py", line 170, in close
    self._call_parse()
  File "/home/florian/sources/cpython/Lib/email/feedparser.py", line 163, in _call_parse
    self._parse()
  File "/home/florian/sources/cpython/Lib/email/feedparser.py", line 449, in _parsegen
    self._cur.set_payload(EMPTYSTRING.join(lines))
  File "/home/florian/sources/cpython/Lib/email/message.py", line 311, in set_payload
    " payload") from None
TypeError: charset argument must be specified when non-ASCII characters are used in the payload
---

This is new in 3.4 since that's the first version which requires set_payload to provide a charset argument, imo message_from_string should figure that out from the message.

----------
messages: 207028
nosy: apollo13
priority: normal
severity: normal
status: open
title: email.message_from_string no longer working in Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20089>
_______________________________________

From report at bugs.python.org  Sat Dec 28 15:20:57 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 28 Dec 2013 14:20:57 +0000
Subject: [issue20089] email.message_from_string no longer working in Python 3.4
In-Reply-To: <1388239743.81.0.886859790367.issue20089@psf.upfronthosting.co.za>
Message-ID: <1388240457.4.0.485135628502.issue20089@psf.upfronthosting.co.za>


Changes by Florian Apolloner <florian at apolloner.eu>:


----------
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20089>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:14:34 2013
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 28 Dec 2013 15:14:34 +0000
Subject: [issue20090] slight ambiguity in README.txt instructions for building
 docs
Message-ID: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za>


New submission from Mitchell Model:

I tried to build the docs for v3.4.0b1 following the instructions in the Doc/README.txt. My default python is v3.3. I got the following error message:
"Error: Sphinx needs to be executed with Python 2.4 or newer (not 3.0 though)."
I wondered what was weird about 3.0 as opposed to later versions that it wouldn't work. Fortunately I had run into other situations where tools expected Python 2 but wouldn't work with Python 3, so after a few minutes of head scratching I tried using Python 2, whi

Sphinx needs to be executed with Python 2 (v. 2.4 or newer), not Python 3

 so that it makes clear that it requires Python 2 not Python 3 and puts the grammatical emphasis where it belongs.

More importantly, perhaps, the Doc README should be changed to state that make must use Python 2.

----------
assignee: docs at python
components: Build, Documentation
messages: 207029
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: slight ambiguity in README.txt instructions for building docs
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20090>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:17:22 2013
From: report at bugs.python.org (Mitchell Model)
Date: Sat, 28 Dec 2013 15:17:22 +0000
Subject: [issue20091] An index entery for __main__ in "30.5 runpy" is missing
Message-ID: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>


New submission from Mitchell Model:

An index entry should be added for __main__ as it appears in the documentation of runpy (30.5 in 3.3, 31.5 in 3.4).

----------
assignee: docs at python
components: Documentation
messages: 207030
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: An index entery for __main__ in "30.5 runpy" is missing
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20091>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:43:15 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Dec 2013 15:43:15 +0000
Subject: [issue20089] email.message_from_string no longer working in Python 3.4
In-Reply-To: <1388239743.81.0.886859790367.issue20089@psf.upfronthosting.co.za>
Message-ID: <1388245395.53.0.220806340251.issue20089@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  There's definitely a backward compatibility issue here of some sort, but how are you parsing this email?  And does it work or fail in some other way on 3.3 tip?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20089>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:44:40 2013
From: report at bugs.python.org (Florian Apolloner)
Date: Sat, 28 Dec 2013 15:44:40 +0000
Subject: [issue20089] email.message_from_string no longer working in Python 3.4
In-Reply-To: <1388239743.81.0.886859790367.issue20089@psf.upfronthosting.co.za>
Message-ID: <1388245480.95.0.672857267408.issue20089@psf.upfronthosting.co.za>


Florian Apolloner added the comment:

Yes, it works on python3.3 (from debian); I am parsing directly via email.message_from_string:
Python 3.3.3 (default, Dec  8 2013, 14:51:59) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> msg="""Content-Type: text/plain; charset="utf-8"
... MIME-Version: 1.0
... Content-Transfer-Encoding: 8bit
... Subject: =?utf-8?q?Ch=C3=A8re_maman?=
... From: from at example.com
... To: to at example.com
... Date: Sat, 28 Dec 2013 13:08:07 -0000
... Message-ID: <20131228130807.3669.79195 at localhost>
... 
... Je t'aime tr?s fort"""
>>> email.message_from_string(msg)
<email.message.Message object at 0x7fcfbcbf9090>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20089>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:45:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Dec 2013 15:45:30 +0000
Subject: [issue20091] An index entry for __main__ in "30.5 runpy" is missing
In-Reply-To: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>
Message-ID: <1388245530.0.0.814623125905.issue20091@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: An index entery for __main__ in "30.5 runpy" is missing -> An index entry for __main__ in "30.5 runpy" is missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20091>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:47:35 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Dec 2013 15:47:35 +0000
Subject: [issue20089] email.message_from_string no longer working in Python 3.4
In-Reply-To: <1388239743.81.0.886859790367.issue20089@psf.upfronthosting.co.za>
Message-ID: <1388245655.25.0.74305156287.issue20089@psf.upfronthosting.co.za>


R. David Murray added the comment:

Nevermind, I failed to notice the message_from_string part of the traceback.

Different question: what are you doing with the message after you parse it?  It is not an RFC valid message if you parse it from a string, so the only way to make it produce an RFC valid output is if you emit it as a string *and* encode the output to utf-8.

I'll have to think about how this "should" work...a clearer error message may be the answer, but if so I suppose I'll need an actual deprecation period before shipping the charset fix for set_payload.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20089>
_______________________________________

From report at bugs.python.org  Sat Dec 28 16:51:02 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 28 Dec 2013 15:51:02 +0000
Subject: [issue19143] Finding the Windows version getting messier
In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za>
Message-ID: <1388245862.9.0.864668818881.issue19143@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/issue19143>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:00:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Dec 2013 16:00:23 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <3ds8kZ1MZCz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset fef075ddaec9 by Antoine Pitrou in branch 'default':
Issue #19648: implement empty tests in pickletester.  Patch by Gennadiy Zlobin.
http://hg.python.org/cpython/rev/fef075ddaec9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:01:27 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 16:01:27 +0000
Subject: [issue19648] Empty tests in pickletester need to be implemented or
 removed
In-Reply-To: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>
Message-ID: <1388246487.33.0.318641928115.issue19648@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've pushed the patch. Thank you for your contribution!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19648>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:13:59 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 16:13:59 +0000
Subject: [issue19422] Neither DTLS nor error for SSLSocket.sendto() of UDP
 socket
In-Reply-To: <1382965011.03.0.394041339056.issue19422@psf.upfronthosting.co.za>
Message-ID: <1388247239.25.0.225782033694.issue19422@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Actually, it seems the patch is flawed:

>>> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> sock.type
2
>>> sock.settimeout(0)
>>> sock.type
2050

But getsockopt() returns the expected value:

>>> sock.getsockopt(socket.SOL_SOCKET, socket.SO_TYPE)
2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19422>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:31:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Dec 2013 16:31:01 +0000
Subject: [issue19422] Neither DTLS nor error for SSLSocket.sendto() of UDP
 socket
In-Reply-To: <1382965011.03.0.394041339056.issue19422@psf.upfronthosting.co.za>
Message-ID: <3ds9Pw0lB5z7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset a00842b783cf by Antoine Pitrou in branch '3.3':
Issue #19422: Explicitly disallow non-SOCK_STREAM sockets in the ssl module, rather than silently let them emit clear text data.
http://hg.python.org/cpython/rev/a00842b783cf

New changeset f7dc02e6987a by Antoine Pitrou in branch 'default':
Issue #19422: Explicitly disallow non-SOCK_STREAM sockets in the ssl module, rather than silently let them emit clear text data.
http://hg.python.org/cpython/rev/f7dc02e6987a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19422>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:35:21 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Dec 2013 16:35:21 +0000
Subject: [issue19422] Neither DTLS nor error for SSLSocket.sendto() of UDP
 socket
In-Reply-To: <1382965011.03.0.394041339056.issue19422@psf.upfronthosting.co.za>
Message-ID: <3ds9Vw4sfRz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 44841d81bf14 by Antoine Pitrou in branch '2.7':
Issue #19422: Explicitly disallow non-SOCK_STREAM sockets in the ssl module, rather than silently let them emit clear text data.
http://hg.python.org/cpython/rev/44841d81bf14

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19422>
_______________________________________

From report at bugs.python.org  Sat Dec 28 17:36:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 16:36:28 +0000
Subject: [issue19422] Neither DTLS nor error for SSLSocket.sendto() of UDP
 socket
In-Reply-To: <1382965011.03.0.394041339056.issue19422@psf.upfronthosting.co.za>
Message-ID: <1388248588.79.0.458909478276.issue19422@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch is stricter (it checks for SOCK_STREAM). Pushed!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19422>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:17:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Dec 2013 17:17:31 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388251051.28.0.14690387822.issue20084@psf.upfronthosting.co.za>


R. David Murray added the comment:

Duplicate of issue 8489.

----------
components: +email
nosy: +barry, r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> Support RFC 6531 in smptlib
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:26:08 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Dec 2013 17:26:08 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388251568.72.0.0475093025959.issue20084@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sat Dec 28 18:46:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Dec 2013 17:46:01 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
In-Reply-To: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>
Message-ID: <1388252761.48.0.0930489552937.issue20083@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the suggestion.

Once the issue 11783 patch is committed, smtplib can be changed to use formataddr in quoteaddr, which will result in the domain being punycoded automatically.  (It's too bad I forgot about that issue, since the 3.4 beta deadline has already passed :(

The input to the commands is string, not bytes, so you can already pre-encode yourself, as you noted.  The commands don't accept bytes, and should not, since the data they cause to be sent on the wire may not contain non-ASCII characters; there is thus no need to generate binary.  SMTPUTF8 will of course require generating binary data in these contexts, but in that case the correct way to generate the binary is by utf-8 encoding the unicode input, so there will again be no reason for the commands to accept binary input, and it will be better if they don't.  (If you need to generate invalid data, say for a test scenario, you can drop down to executing 'send' calls manually.)

(Note: using the 'u' prefix in python3, while supported for backward compatibility, is only confusing when used outside of that context...I thought you were talking about 2.7 until I read carefully.)

----------
components: +email
dependencies: +email parseaddr and formataddr should be IDNA aware
nosy: +barry, r.david.murray
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 19:49:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Dec 2013 18:49:10 +0000
Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive
In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>
Message-ID: <3dsDTL2BMhz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset 763f4416c4fd by Antoine Pitrou in branch 'default':
Issue #19918: Fix PurePath.relative_to() under Windows.
http://hg.python.org/cpython/rev/763f4416c4fd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19918>
_______________________________________

From report at bugs.python.org  Sat Dec 28 19:49:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 18:49:45 +0000
Subject: [issue19918] PureWindowsPath.relative_to() is not case insensitive
In-Reply-To: <1386414151.7.0.591578690469.issue19918@psf.upfronthosting.co.za>
Message-ID: <1388256585.88.0.518913859717.issue19918@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks! I've tweaked the patch a bit and committed it.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19918>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:16:40 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 19:16:40 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
In-Reply-To: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>
Message-ID: <1388258199.99.0.0211414017105.issue20083@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

Great to hear that a patch already exists (sorry I couldn't find in in the tracker).

Feel free to close this issue as duplicate of issue 11783.

(As for the u"string", I wanted to distinguish it from b'string'. I don't use it in code (since the backward compatibility is only present in 3.3+, not in 3.2). Sorry for the confusion.)

----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:18:45 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Dec 2013 19:18:45 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
In-Reply-To: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>
Message-ID: <1388258325.54.0.347843525935.issue20083@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, that issue is about the email library.  So we need this one too for the equivalent enhancement to smtplib.

----------
resolution: duplicate -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:28:10 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 19:28:10 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1388258890.29.0.533819100723.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

No answer to Xavier's regression? The way this issue is being treated is a bit worrying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:38:05 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Dec 2013 19:38:05 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <3dsFYm5DcVz7LkK@mail.python.org>


Roundup Robot added the comment:

New changeset b668c409c10a by Antoine Pitrou in branch 'default':
Fix breakage in TestSuite.countTestCases() introduced by issue #11798.
http://hg.python.org/cpython/rev/b668c409c10a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:45:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 28 Dec 2013 19:45:58 +0000
Subject: [issue16778] Logger.findCaller needs to be smarter
In-Reply-To: <1356452428.01.0.563947098769.issue16778@psf.upfronthosting.co.za>
Message-ID: <1388259958.26.0.128217928043.issue16778@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/issue16778>
_______________________________________

From report at bugs.python.org  Sat Dec 28 20:56:32 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 28 Dec 2013 19:56:32 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
Message-ID: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>


New submission from Ethan Furman:

In order to create a coherent integer type class both __int__ and __index__ must be defined or the resulting instances will behave inconsistently in different places.

For example, if __index__ is not defined then the class cannot be used in slices, and if __int__ is not defined then int(integer_type) will fail.

At this point the programmer must remember to define both, but since they should return the same value we can have the type constructor automatically assign __int__ to __index__ when the latter is defined and the former is not.  This would be similar to how we currently treat __ne__ when __eq__ is defined.

----------
messages: 207048
nosy: ethan.furman
priority: low
severity: normal
status: open
title: type() constructor should bind __int__ to __index__ when __index__ is defined and __int__ is not
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:00:12 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 28 Dec 2013 20:00:12 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388260812.66.0.569530720485.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Enhancement portion split off into issue20092.

Attached patch includes doc change, tests, and code changes.

If I'm overstepping my bounds, I'm sure somebody will slap me with a fish. ;)

----------
keywords: +patch
stage: test needed -> patch review
title: hex() and %x, oct() and %o do not behave the same -> %c, %o, %x, %X accept non-integer values instead of raising an exception
type: enhancement -> behavior
versions: +Python 3.4 -Python 3.5
Added file: http://bugs.python.org/file33284/issue19995.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:08:52 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 28 Dec 2013 20:08:52 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388261332.86.0.916055117887.issue20092@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

__ne__ is not "bound" to __eq__. The comparison code simply falls back onto __eq__ if __ne__ is not defined.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:23:56 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 28 Dec 2013 20:23:56 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388262236.54.0.452323443048.issue20092@psf.upfronthosting.co.za>


Ethan Furman added the comment:

True.  I meant similar in that Python will use what's available to fill in the blank:

  class has __eq__ but user tried != ?  use __eq__ and invert result

  class has __index__ but user tried int() ?  use __index__ as-is

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:31:06 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 20:31:06 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388262666.71.0.873309539219.issue20084@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

Are you sure that issue 8489 is a duplicate? While both concern RFC 6531, the patch for 8489 only seems to add test to check how smtplib.SMTP.login() handles a username with non-ASCII characters. This issue concerns the smtplib.SMTP.rcpt() (and indirectly smtplib.SMTP.send()).

>From your comment in issue 20083 you seem to prefer that all input is in strings, not bytes. I think that is sensible, but it means that smtplib is responsible for doing the encoding, including the UTF-8 encoding instead of ASCII encoding for mails that support the SMTPUTF8 extension.

Would the following be reasonable?

* The smtplib.SMTP class gets a new attribute, header_encoding
* The header_encoding attribute is 'ascii' by default.
* header_encoding is used by the send() method, and perhaps also by the login() method, but not by the data() method (for that, a body_encoding sounds more reasonable).
* A user may set header_encoding explicitly

Open questions are:

* Should the library automatically set header_encoding to UTF-8? If so, when? If the connected server announces the SMTPUTF8 extension?
* What should happen if the users submits non-ASCII data in any of the headers, but the server has not announced the SMTPUTF8 extension? Currently, this raises a UnicodeEncodeError exception, but I think it should be more explicit that it is a combination of Unicode input combined with lack of support from the MTA.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:41:45 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 28 Dec 2013 20:41:45 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388263305.66.0.590724508105.issue20092@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/issue20092>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:44:17 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sat, 28 Dec 2013 20:44:17 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
In-Reply-To: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>
Message-ID: <1388263457.72.0.596022822689.issue20083@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

Since smtplib.quoteaddr() uses email.utils.parseaddr(), and the patch for issue 11783 fixes email.utils.parseaddr(), that patch will hopefully solve this issue as well (though a test case wouldn't hurt for sure).

What I had not realised is that hostnames are also used elsewhere, in particular in the ehlo() and helo() but also in connect(). Do you consider that a separate issue or part of this issue?

Are there other places where you think a fix is needed?

I may be able to create a patch, though bear with me: I never checked out the source for Python or the standard library (other than installing point releases through my package manager).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sat Dec 28 21:46:45 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 28 Dec 2013 20:46:45 +0000
Subject: [issue20087] Mismatch between glibc and X11 locale.alias
In-Reply-To: <1388222989.89.0.773650778168.issue20087@psf.upfronthosting.co.za>
Message-ID: <1388263605.28.0.0863108531732.issue20087@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/issue20087>
_______________________________________

From report at bugs.python.org  Sat Dec 28 22:12:54 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 28 Dec 2013 21:12:54 +0000
Subject: [issue20088] locale.getlocale() fails if locale name doesn't include
 encoding
In-Reply-To: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za>
Message-ID: <1388265174.66.0.482937507454.issue20088@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/issue20088>
_______________________________________

From report at bugs.python.org  Sat Dec 28 22:13:21 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 28 Dec 2013 21:13:21 +0000
Subject: [issue20079] Add support for glibc supported locales
In-Reply-To: <1388139147.62.0.637898307439.issue20079@psf.upfronthosting.co.za>
Message-ID: <1388265201.1.0.676324966357.issue20079@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/issue20079>
_______________________________________

From report at bugs.python.org  Sat Dec 28 22:13:32 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Dec 2013 21:13:32 +0000
Subject: [issue20085] Python2.7, wxPython and IDLE 2.7
In-Reply-To: <1388199692.1.0.186486001282.issue20085@psf.upfronthosting.co.za>
Message-ID: <1388265212.47.0.748005963319.issue20085@psf.upfronthosting.co.za>


Ned Deily added the comment:

It is hard to know exactly what is going on without more information and this bug tracker is not set up to answer usage questions. There are better places for help, for example, the Python tutor mailing list (https://mail.python.org/mailman/listinfo/tutor) or stackoverflow.com or possibly a wxPython list.  If it turns out that there is likely a problem with Python itself, please re-open the issue with appropriate supporting documentation.  Good luck!

----------
nosy: +ned.deily
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20085>
_______________________________________

From report at bugs.python.org  Sat Dec 28 23:34:04 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Dec 2013 22:34:04 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
In-Reply-To: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>
Message-ID: <1388270044.17.0.653362045491.issue12692@psf.upfronthosting.co.za>


Martin Panter added the comment:

Any chance of backporting this to version 3.3? I think it is a real-world issue beyond the test suite. See Issue 19524.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12692>
_______________________________________

From report at bugs.python.org  Sat Dec 28 23:36:02 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Dec 2013 22:36:02 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1388270162.76.0.365036260948.issue19524@psf.upfronthosting.co.za>


Martin Panter added the comment:

Just discovered the same fix of manually closing the socket object was already made independently of my patch in the ?default? branch! See Issue 12692.

http://hg.python.org/cpython/rev/92656b5df2f2

The main difference is my patch should also close the connection if HTTPConnection.getresponse() fails, which could be of some value. And the regression test could still be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Sun Dec 29 00:38:44 2013
From: report at bugs.python.org (Michael Foord)
Date: Sat, 28 Dec 2013 23:38:44 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1388273924.62.0.478190749641.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

What's the purpose of _removed_tests in your fix, it doesn't appear to be used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sun Dec 29 01:50:27 2013
From: report at bugs.python.org (Jason Gerard DeRose)
Date: Sun, 29 Dec 2013 00:50:27 +0000
Subject: [issue20093] Wrong OSError message from os.rename() when dst is a
 non-empty directory
Message-ID: <1388278227.56.0.603151192526.issue20093@psf.upfronthosting.co.za>


New submission from Jason Gerard DeRose:

Under Python 3.3, if renaming a directory with `os.rename()` when the destination is an existing, non-empty directory, like this:

os.rename('/tmp/foo', '/tmp/bar')

You'll get an OSError with a message like this:

OSError: [Errno 39] Directory not empty: '/tmp/bar'

However, in the current Python 3.4.0b1 package in Ubuntu Trusty, this error message will contain the source directory name instead of the destination directory name, like this:

OSError: [Errno 39] Directory not empty: '/tmp/foo'

I've attached a test case, which also covers renaming directories relative to an open directory descriptor. This test case works on Python 3.3, fails on Python 3.4 Beta1.

----------
components: Library (Lib)
files: test_os_rename.py
messages: 207058
nosy: jderose
priority: normal
severity: normal
status: open
title: Wrong OSError message from os.rename() when dst is a non-empty directory
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33285/test_os_rename.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20093>
_______________________________________

From report at bugs.python.org  Sun Dec 29 02:11:10 2013
From: report at bugs.python.org (Jason Gerard DeRose)
Date: Sun, 29 Dec 2013 01:11:10 +0000
Subject: [issue16074] Bad error message in os.rename, os.link, and os.symlink
In-Reply-To: <1348820000.8.0.496903200143.issue16074@psf.upfronthosting.co.za>
Message-ID: <1388279470.66.0.905792677067.issue16074@psf.upfronthosting.co.za>


Jason Gerard DeRose added the comment:

vajrasky, one more errno to consider:

[Errno 39] Directory not empty: '/tmp/bar'

This is when renaming a directory: src directory exists; dst directory exists and is non-empty.

In 3.4 Beta1, this error message now includes the src instead of the dst (flipped behaviour from Python 3.3). I'm not sure whether this changed because of changes being tracked in this bug on not, so I filed a separate issue: http://bugs.python.org/issue20093

----------
nosy: +jderose

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16074>
_______________________________________

From report at bugs.python.org  Sun Dec 29 02:37:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Dec 2013 01:37:48 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
In-Reply-To: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>
Message-ID: <3dsPXp24v3z7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset a43e96695203 by Senthil Kumaran in branch '3.3':
Backporing the fix from Issue #12692
http://hg.python.org/cpython/rev/a43e96695203

New changeset 031417ee8351 by Senthil Kumaran in branch 'default':
#12692: null merge with 3.3
http://hg.python.org/cpython/rev/031417ee8351

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12692>
_______________________________________

From report at bugs.python.org  Sun Dec 29 02:38:25 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 29 Dec 2013 01:38:25 +0000
Subject: [issue12692] test_urllib2net is triggering a ResourceWarning
In-Reply-To: <1312520551.96.0.100282355939.issue12692@psf.upfronthosting.co.za>
Message-ID: <1388281105.32.0.177109280578.issue12692@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

@Martin. Agree that this should have been backported. I have done that.
Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12692>
_______________________________________

From report at bugs.python.org  Sun Dec 29 02:57:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 01:57:20 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388282240.23.0.294109826823.issue20084@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  Perhaps it would be better to close that one as a duplicate of this one, since this one doesn't start out as an error report that then got converted into an enhancement request...

The patch on that issue doesn't have anything to do with what the issue turned into, which is indeed a bit confusing.

I haven't given much thought to *how* to implement this support.  Depending on utf8smtp capability being present seems the best course.  If support isn't available, then the library should continue to raise an error, as it does now, but indeed the message could be improved.

In real life, of course, we want our message to get delivered regardless of whether or not smtputf8 is available.  To make that work, it will be advisable for the application to use the send_message interface rather than the sendmail interface: pass in a Message object, which can be automatically serialized as utf8 if smtputf8 is available, and the normal CTE encoding dances if not.  This of course will require support from the email package, specifically a 'utf8 only' serialization mode.

If one is using smtplib only, then the application is responsible both for checking for the smtputf8 capability and branching accordingly, and for getting all the data correct...when I said "string only" I was referring to the methods in question (RCPT, etc).  DATA is a different story, and that has to handle both ascii-only strings or properly encoded (per the email RFCs) binary.  Automatic encoding of non-ascii string DATA is dangerous, and would only work if the input is correctly formatted for the utf8 charset throughout.  Personally I'd rather use the email package to ensure that...so if an application wants to bypass the email package, I think requiring it to manually encode the DATA string into utf8 is an acceptable interface requirement, to make it *clear* that there is no way to automatically encode an arbitrary email message (other than by using the email package).

These are just preliminary thoughts...there is probably more design work to be done before this can be implemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sun Dec 29 03:06:54 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 02:06:54 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388282814.72.0.904000235284.issue20084@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is another possible approach, but I haven't decided yet whether or not I like it.  The email package string parser could (and may for other reasons) become smart enough to convert unicode into the charset declared in the MIME part when it is parsing the string version of a message.  In that case, smtplib could use the string parser to parse the DATA payload, and if it parses successfully it can then use the same code path as I'm proposing for send_message to generate the right output depending on whether or not the smtputf8 capability is present.  That would place a new constraint on what was acceptable as a DATA payload, though, so I'm not at all sure it is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sun Dec 29 03:12:48 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 02:12:48 +0000
Subject: [issue20083] smtplib: support for IDN (international domain names)
In-Reply-To: <1388195363.36.0.929515660511.issue20083@psf.upfronthosting.co.za>
Message-ID: <1388283168.05.0.797449566758.issue20083@psf.upfronthosting.co.za>


R. David Murray added the comment:

A call to formataddr will need to be added to quoteaddr.  And yes, test cases are needed.

I don't believe that the format of the HELO/EHLO message is defined by the RFC, so I don't think we can automatically parse it.  I think we just have to leave the domain name encoded as punycode there.  Regardless, though, yes I would consider that a separate issue.

If you want to work on a patch, that would be great.  For guidance on doing so, you can take a look at http://docs.python.org/devguide.

You can also help me to remember to commit 11783 after the final release of 3.4.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20083>
_______________________________________

From report at bugs.python.org  Sun Dec 29 03:19:26 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 02:19:26 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388283566.16.0.0461258457714.issue20092@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is not clear to me that that would be correct, though.  Isn't the whole point of __index__ that some types can act as indicies even though they are *not* integers?  Shouldn't it be up to the type to decide if converting them to int is a sensible thing to do?  Maybe that's being silly/pendantic, though.  On the gripping hand, it feels like this is another case of what you have pointed out elsewhere, that it is not clear that we actually have a consistent API here...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sun Dec 29 07:07:39 2013
From: report at bugs.python.org (stubz)
Date: Sun, 29 Dec 2013 06:07:39 +0000
Subject: [issue20085] Python2.7, wxPython and IDLE 2.7
In-Reply-To: <1388199692.1.0.186486001282.issue20085@psf.upfronthosting.co.za>
Message-ID: <1388297259.92.0.947473214926.issue20085@psf.upfronthosting.co.za>


stubz added the comment:

Cheerz mate,

In as much as your reply was no help, it's kinda what I figured ...
I'm a newbie to linux & python, but I know enough to cause myself serious grief, and well, usually do ...
I'll get it sorted at some point ...
Hell of a lot easy to work thru then windows tho :)
Ciao,
Stubz

----------
resolution: invalid -> works for me
status: closed -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20085>
_______________________________________

From report at bugs.python.org  Sun Dec 29 08:54:34 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Dec 2013 07:54:34 +0000
Subject: [issue20090] slight ambiguity in README.txt instructions for building
 docs
In-Reply-To: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za>
Message-ID: <1388303674.0.0.208838601127.issue20090@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20090>
_______________________________________

From report at bugs.python.org  Sun Dec 29 09:03:10 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Dec 2013 08:03:10 +0000
Subject: [issue20079] Add support for glibc supported locales
In-Reply-To: <1388139147.62.0.637898307439.issue20079@psf.upfronthosting.co.za>
Message-ID: <1388304190.69.0.02659120442.issue20079@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20079>
_______________________________________

From report at bugs.python.org  Sun Dec 29 09:11:38 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 08:11:38 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388304698.46.0.263644104501.issue20092@psf.upfronthosting.co.za>


Ethan Furman added the comment:

In issue19995, in msg206339, Guido exhorted:
--------------------------------------------
>> [Ethan claimed] it is possible to want a type that can be used as an
>> index or slice but that is still not a number
>
> I'm sorry, but this requirement is absurd. An index *is* a number. You
> have to make up your mind. (I know, in the context of the example that
> started this, this is funny, but I still stand by it.)
>
> Finally, the correct name should perhaps have been __integer__ but I don't
> see enough reason to change it now.

The de facto API that is forming is that if an actual int is needed from an actual integer type (not float, not complex, not etc.), then __index__ is used.  If __index__ is not defined by some numeric type then it will not be considered a true int in certain key places in Python, such as as indices, arguments to hex(), etc.

Making the change suggested in the title would help solidify the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sun Dec 29 10:16:30 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 09:16:30 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388308590.25.0.405554160511.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Ran full test suite; some errors came up in test_format from the following test lines:

    testformat("%#x", 1.0, "0x1")
    testformat("%x", float(big), "123456_______________", 6)
    testformat("%o", float(big), "123456__________________________", 6)
    testformat("%x", float(0x42), "42")
    testformat("%o", float(0o42), "42")

Removed as float() is not supposed to be valid input.

Also fixed two memory leaks in unicodeobject from my changes, and a float->oct bug in tarfile.

----------
Added file: http://bugs.python.org/file33286/issue19995.stoneleaf.02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Sun Dec 29 12:14:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 29 Dec 2013 11:14:46 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1388315686.59.0.796493632477.issue11798@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It is used, see countTestCases().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sun Dec 29 13:29:28 2013
From: report at bugs.python.org (Freek Dijkstra)
Date: Sun, 29 Dec 2013 12:29:28 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388320168.08.0.586245047402.issue20084@psf.upfronthosting.co.za>


Freek Dijkstra added the comment:

> we want our message to get delivered regardless of whether or not smtputf8 is available.

This is not possible if the user specifies an (sender or recipient) email address with non-ASCII characters and the first-hop mail system does not support SMTPUTF8. Section 8 of RFC 6530 seems to suggest that in that case either an all-ASCII email address should be used, and if that is not available, the mail should bounce. In my interpretation smtplib should fail by raising an Exception.

> [...] a Message object, which can be automatically serialised as utf8 if smtputf8 is available [...]

I hadn't given the mail body much thought. I think that this is covered by the existing 8BITMIME extension, in which case the client can add the header 'Content-Type: text/plain; charset="utf-8"'. From what I understand SMTPUTF8 only concerns the encoding of the header. I prefer that this particular issue (enhancement request) only concerns the mail headers, not the mail body. (I see that you also have some ideas on this, perhaps this is for a different issue?)

PS: I planned to use smtplib to see if I could understand the standard for international email addresses. Turns out I'm not reading the standard to see how smtplib should work. Also nice, but not what I had intended to do. :). It seems that STMPUTF8 is not yet implemented that much. I've learned that my production MTA does not support it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sun Dec 29 14:44:05 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 13:44:05 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388324645.35.0.945276548175.issue20092@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  A link to that issue would have been helpful :).

To summarize for anyone like me who didn't follow that issue: __index__ means the object can be losslessly converted to an int (is a true int), while __int__ may be an approximate conversion.  Thus it makes sense for an object to have an __int__ but not __index__, but vice-versa does not make sense.

Is someone updating the docs to reflect this, or should that be spun off as a separate issue as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:06:21 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 14:06:21 +0000
Subject: [issue20084] smtplib: support for UTF-8 encoded headers (SMTPUTF8)
In-Reply-To: <1388195515.33.0.10832843598.issue20084@psf.upfronthosting.co.za>
Message-ID: <1388325981.74.0.439426554675.issue20084@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, I've been doing a lot of reading of standards while trying to hide all the messy details from users of the new API I've added to the email package.  I haven't gotten to smtplib yet :)

But, this stuff is messy.  If you want to understand a standard, you really have to read it, and lots of others standards besides, and then look at what various packages have chosen to implement, and figure out all the ways you think they did it wrong :)  As you have observed, implementations of SMTPUTF8 are scarce on the ground so far.

SMTPUTF8 may be about headers, but because the natural way of representing non-ascii headers in Python is as a (unicode) string, and SEND takes a single string (or bytes) argument, you can't separate dealing with the encoding of the headers from dealing with the encoding of the body unless you *parse* the payload as an email message so you can do the right thing with the body.  Thus you can't address adding SMTPUTF8 to smtplib without figuring out the API for the whole message, not just the headers.

So yes, the client can 'add Content-Type: text/plain; charset="utf-8"', but the process of doing that is exactly what I was talking about :)

Now, one option, as I said, it to put the burden on the application: it can check to see if SMTPUTF8 is available, and if so provide a DATA formatted with utf8 headers and charset='utf-8' bodies, and if it is not available, provide a DATA formatted with RFC2047 headers and charset="utf-8" bodies.  But I'd rather make smtplib (with the help of the email package) do the hard work, rather than have every application have to do it.  

Still, we could start with a patch that just makes it possible for an application to do it itself.  That would just need to accept non-ascii in the RCPT etc commands, pass it through as utf8 if SMTPUTF8 is available, and raise an error otherwise.

You are correct that the more convenient API I'm talking about also needs to be enhanced to provide a way to specify the alternate ASCII-only address.  I'd forgotten about that detail.  That's going to be very annoying from a clean-API point of view :(

And yes, it should raise an exception if SMTPUTF8 is not available and no ascii address was provided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20084>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:49:55 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Dec 2013 14:49:55 +0000
Subject: [issue16778] Logger.findCaller needs to be smarter
In-Reply-To: <1356452428.01.0.563947098769.issue16778@psf.upfronthosting.co.za>
Message-ID: <1388328595.08.0.481984514521.issue16778@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think we need to look seriously at the frame annotations idea discussed in other issues. Eliminating noise from tracebacks and correctly reporting user code rather than infrastructure could should be achievable through local state rather than needing global registries.

The workaround we put in place for importlib is an awful hack, and there's a problem where PEP 3144 allows the creation of exception *trees*, but we can currently only record stacks properly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16778>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:57:18 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 14:57:18 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388329038.19.0.222577494877.issue20092@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I have the following as part of the patch for that issue:
---------------------------------------------------------
diff -r b668c409c10a Doc/reference/datamodel.rst
--- a/Doc/reference/datamodel.rst	Sat Dec 28 20:37:58 2013 +0100
+++ b/Doc/reference/datamodel.rst	Sun Dec 29 06:55:11 2013 -0800
@@ -2073,23 +2073,31 @@ left undefined.
       builtin: float
       builtin: round
 
    Called to implement the built-in functions :func:`complex`,
    :func:`int`, :func:`float` and :func:`round`.  Should return a value
    of the appropriate type.
 
 
 .. method:: object.__index__(self)
 
-   Called to implement :func:`operator.index`.  Also called whenever Python needs
-   an integer object (such as in slicing, or in the built-in :func:`bin`,
-   :func:`hex` and :func:`oct` functions). Must return an integer.
+   Called to implement :func:`operator.index`, and whenever Python needs to
+   losslessly convert the numeric object to an integer object (such as in
+   slicing, or in the built-in :func:`bin`, :func:`hex` and :func:`oct`
+   functions). Presence of this method indicates that the numeric object is
+   an integer type.  Must return an integer.
+
+   .. note::
+
+      When :meth:`__index__` is defined, :meth:`__int__` should also be defined,
+      and both shuld return the same value, in order to have a coherent integer
+      type class.
---------------------------------------------------------

If for some reason that patch doesn't make it into 3.4 I'll split the doc change off to its own issue, unless you think it should be split off anyway?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sun Dec 29 15:58:26 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 29 Dec 2013 14:58:26 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
 non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1388329106.81.0.251132788362.issue9291@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

The bug as reported against setuptools: https://bitbucket.org/pypa/setuptools/issue/127/unicodedecodeerror-when-install-in-windows

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:20:29 2013
From: report at bugs.python.org (Dmitry Shachnev)
Date: Sun, 29 Dec 2013 15:20:29 +0000
Subject: [issue20093] Wrong OSError message from os.rename() when dst is a
 non-empty directory
In-Reply-To: <1388278227.56.0.603151192526.issue20093@psf.upfronthosting.co.za>
Message-ID: <1388330429.19.0.168843547078.issue20093@psf.upfronthosting.co.za>


Dmitry Shachnev added the comment:

This is a result of http://hg.python.org/cpython/rev/6903f5214e99.

Looks like we should check the error code and conditionally set the file name to either src or dst.

----------
nosy: +haypo, mitya57

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20093>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:30:10 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 29 Dec 2013 15:30:10 +0000
Subject: [issue16778] Logger.findCaller needs to be smarter
In-Reply-To: <1356452428.01.0.563947098769.issue16778@psf.upfronthosting.co.za>
Message-ID: <1388331010.61.0.146274687191.issue16778@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> the frame annotations idea discussed in other issues

If you mean #19585 and #18861, they seem to be related to exceptions - the logging use case is not exception-related. I couldn't find any other discussions about frame annotations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16778>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:56:08 2013
From: report at bugs.python.org (Mike Short)
Date: Sun, 29 Dec 2013 15:56:08 +0000
Subject: [issue19890] Typo in multiprocessing docs
In-Reply-To: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>
Message-ID: <1388332568.2.0.629849290367.issue19890@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file33287/multiprocessing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19890>
_______________________________________

From report at bugs.python.org  Sun Dec 29 16:58:34 2013
From: report at bugs.python.org (Mike Short)
Date: Sun, 29 Dec 2013 15:58:34 +0000
Subject: [issue19890] Typo in multiprocessing docs
In-Reply-To: <1386198252.12.0.881873603907.issue19890@psf.upfronthosting.co.za>
Message-ID: <1388332714.19.0.0208794607383.issue19890@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
nosy: +Mike.Short

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19890>
_______________________________________

From report at bugs.python.org  Sun Dec 29 17:46:38 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 16:46:38 +0000
Subject: [issue20094] intermitent failures with test_dbm
Message-ID: <1388335598.36.0.994619281921.issue20094@psf.upfronthosting.co.za>


New submission from Ethan Furman:

Following errors occur about half the time:

======================================================================
ERROR: test_anydbm_creation (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 75, in test_anydbm_creation
    self.read_helper(f)
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 117, in read_helper
    self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

======================================================================
ERROR: test_anydbm_modification (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 90, in test_anydbm_modification
    self.read_helper(f)
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 117, in read_helper
    self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

======================================================================
ERROR: test_anydbm_read (test.test_dbm.TestCase-dbm.ndbm)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 96, in test_anydbm_read
    self.read_helper(f)
  File "/home/ethan/source/python/issue19995/Lib/test/test_dbm.py", line 117, in read_helper
    self.assertEqual(self._dict[key], f[key.encode("ascii")])
KeyError: b'0'

----------
messages: 207079
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: intermitent failures with test_dbm
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20094>
_______________________________________

From report at bugs.python.org  Sun Dec 29 17:48:41 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 16:48:41 +0000
Subject: [issue20094] intermitent failures with test_dbm
In-Reply-To: <1388335598.36.0.994619281921.issue20094@psf.upfronthosting.co.za>
Message-ID: <1388335721.1.0.3352302529.issue20094@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Actually, make that about 1/5 of the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20094>
_______________________________________

From report at bugs.python.org  Sun Dec 29 18:56:52 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 29 Dec 2013 17:56:52 +0000
Subject: [issue11798] Test cases not garbage collected after run
In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za>
Message-ID: <1388339812.33.0.534943981016.issue11798@psf.upfronthosting.co.za>


Michael Foord added the comment:

Ah yes, I see - sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11798>
_______________________________________

From report at bugs.python.org  Sun Dec 29 19:07:59 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 29 Dec 2013 18:07:59 +0000
Subject: [issue19732] python fails to build when configured with
 --with-system-libmpdec
In-Reply-To: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za>
Message-ID: <1388340479.54.0.47990088008.issue19732@psf.upfronthosting.co.za>


Matthias Klose added the comment:

your current repo doesn't create and install the .so symlink, and thus won't be used for linking.

Also the sphinx docs are missing, which were included in 2.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19732>
_______________________________________

From report at bugs.python.org  Sun Dec 29 19:29:54 2013
From: report at bugs.python.org (gudge)
Date: Sun, 29 Dec 2013 18:29:54 +0000
Subject: [issue19940] ssl.cert_time_to_seconds() returns wrong results if
 local timezone is not UTC
In-Reply-To: <1386660552.46.0.291263983729.issue19940@psf.upfronthosting.co.za>
Message-ID: <1388341794.11.0.831553684383.issue19940@psf.upfronthosting.co.za>


gudge added the comment:

Can you please provide some hints on how to handle
http://bugs.python.org/issue19940#msg205860.

The value of format_regex

1) Without locale set:
re.compile('(?P<b>jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\\s+(?P<d>3[0-1]|[1-2]\\d|0[1-    9]|[1-9]| [1-9])\\s+(?P<H>2[0-3]|[0-1]\\d|\\d):(?P<M>[0-5]\\d|\\d):(?P<S>6[0-1]|[0-5]\\d|\\d)\\s    +(?P<Y>\\d\\d\\d\\d, re.IGNORECASE)

2) With locale set:
re.compile('(?P<b>sty|lut|mar|kwi|maj|cze|lip|sie|wrz|pa\\?|lis|gru)\\s+(?P<d>3[0-1]|[1-2]\\d|0[    1-9]|[1-9]| [1-9])\\s+(?P<H>2[0-3]|[0-1]\\d|\\d):(?P<M>[0-5]\\d|\\d):(?P<S>6[0-1]|[0-5]\\d|\\d)\    \s+(?P<Y>\\d\\d\\d\, re.IGNORECASE)

The value of months are different.

Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19940>
_______________________________________

From report at bugs.python.org  Sun Dec 29 21:06:52 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Dec 2013 20:06:52 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388347612.14.0.051272066525.issue20092@psf.upfronthosting.co.za>


R. David Murray added the comment:

Nah, splitting it doesn't seem worth it unless you think the patch won't make it in.

(Not that I looked at it earlier, but he patch on the issue doesn't look like what you just posted here...and here there's a typo: shuld).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Sun Dec 29 21:30:07 2013
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 29 Dec 2013 20:30:07 +0000
Subject: [issue20092] type() constructor should bind __int__ to __index__ when
 __index__ is defined and __int__ is not
In-Reply-To: <1388260592.79.0.323683192221.issue20092@psf.upfronthosting.co.za>
Message-ID: <1388349007.09.0.156182447811.issue20092@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I updated it as I liked your wording better.  :)  Doing more testing to see if anything else needs fixing before I make the next patch for the tracker on that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20092>
_______________________________________

From report at bugs.python.org  Mon Dec 30 00:39:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Dec 2013 23:39:07 +0000
Subject: [issue20031] unittest.TextTestRunner missing run() documentation.
In-Reply-To: <1387530499.44.0.66291527317.issue20031@psf.upfronthosting.co.za>
Message-ID: <3dsysQ41y2z7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 19464d77ec2e by Michael Foord in branch 'default':
Closes issue 20031. Document unittest.TextTestRunner.run method.
http://hg.python.org/cpython/rev/19464d77ec2e

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20031>
_______________________________________

From report at bugs.python.org  Mon Dec 30 00:54:33 2013
From: report at bugs.python.org (Michael Foord)
Date: Sun, 29 Dec 2013 23:54:33 +0000
Subject: [issue18566] In unittest.TestCase docs for setUp() and tearDown()
 don't mention AssertionError
In-Reply-To: <1374901937.1.0.747872580847.issue18566@psf.upfronthosting.co.za>
Message-ID: <1388361273.4.0.126431242357.issue18566@psf.upfronthosting.co.za>


Michael Foord added the comment:

Yep, those docs are just wrong. I'm trying to think of a concise rewording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18566>
_______________________________________

From report at bugs.python.org  Mon Dec 30 01:09:32 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Dec 2013 00:09:32 +0000
Subject: [issue16778] Logger.findCaller needs to be smarter
In-Reply-To: <1388331010.61.0.146274687191.issue16778@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fwhRRYEb0BykTLVQWedv9thAgk5rnk1hkzE=_K6vwFow@mail.gmail.com>


Nick Coghlan added the comment:

My idea is to annotate the frames appropriately so they can be *displayed*
differently when showing a traceback (either hiding them entirely or
displaying additional information). This would be another use case -
annotating the frame to say the logging module should skip over it when
looking for the caller.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16778>
_______________________________________

From report at bugs.python.org  Mon Dec 30 01:19:14 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 30 Dec 2013 00:19:14 +0000
Subject: [issue18310] itertools.tee() can't accept keyword arguments
In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za>
Message-ID: <1388362754.35.0.643385495026.issue18310@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Why has this been closed?  I've just run into exactly the same problem.  It states here http://docs.python.org/3/library/itertools.html#itertools.tee "itertools.tee(iterable, n=2) - Return n independent iterators from a single iterable."

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18310>
_______________________________________

From report at bugs.python.org  Mon Dec 30 01:51:27 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 30 Dec 2013 00:51:27 +0000
Subject: [issue18310] itertools.tee() can't accept keyword arguments
In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za>
Message-ID: <1388364687.78.0.670045084693.issue18310@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The docs for tee are the same going right back to its introduction in 2.4.  The itertools count function takes start and step keywords, why can't tee take a keyword as it's documented to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18310>
_______________________________________

From report at bugs.python.org  Mon Dec 30 03:59:42 2013
From: report at bugs.python.org (Anthony Kong)
Date: Mon, 30 Dec 2013 02:59:42 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1388372382.64.0.33662015343.issue19771@psf.upfronthosting.co.za>


Changes by Anthony Kong <anthony.hw.kong at gmail.com>:


----------
nosy: +Anthony.Kong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19771>
_______________________________________

From report at bugs.python.org  Mon Dec 30 06:08:06 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 30 Dec 2013 05:08:06 +0000
Subject: [issue18310] itertools.tee() can't accept keyword arguments
In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za>
Message-ID: <1388380086.4.0.0338807306379.issue18310@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

It's just the docs that need changing to clarify the situation as (say) a,b,c = tee(range, 3) works perfectly.  Sorry I didn't have the foresight to check this before :(

----------
components: +Documentation -Library (Lib)
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18310>
_______________________________________

From report at bugs.python.org  Mon Dec 30 11:18:22 2013
From: report at bugs.python.org (Liam Marsh)
Date: Mon, 30 Dec 2013 10:18:22 +0000
Subject: [issue20095] what is that result!?
Message-ID: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>


New submission from Liam Marsh:

when does 3*0.1 make 0.30000000000000004 ?
YES it is the same program!

----------
components: Regular Expressions
messages: 207092
nosy: Liam.Marsh, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: what is that result!?
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20095>
_______________________________________

From report at bugs.python.org  Mon Dec 30 12:29:52 2013
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 30 Dec 2013 11:29:52 +0000
Subject: [issue7464] circular reference in HTTPResponse by urllib2
In-Reply-To: <1260379633.84.0.693013946466.issue7464@psf.upfronthosting.co.za>
Message-ID: <1388402992.45.0.020437243186.issue7464@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson added the comment:

No, the socket is actually closed when response's close() method is called.  The problem is that the HTTPResponse object, buried deep within the nested classes returned from do_open(), has a circular reference, and _it_ will not go away.

No one is _relying_ on garbage collection in the sense that this is not, I think, designed behaviour, merely an unintentional effect of storing a bound method in the object inance.

As always, circular reference should be avoided when possible since relying on gc is not something to be done lightly.

Now, I think that changing the complicated wrapping at this stage is not possible, but merely replacing the bound method with a weak method might just do the trick.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7464>
_______________________________________

From report at bugs.python.org  Mon Dec 30 12:42:41 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Dec 2013 11:42:41 +0000
Subject: [issue20095] what is that result!?
In-Reply-To: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>
Message-ID: <1388403761.92.0.772178972654.issue20095@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

This is how binary floating-point arithmetic works.  See

http://docs.python.org/3/tutorial/floatingpoint.html

for some explanations.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20095>
_______________________________________

From report at bugs.python.org  Mon Dec 30 12:43:28 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Dec 2013 11:43:28 +0000
Subject: [issue20095] what is that result!?
In-Reply-To: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>
Message-ID: <1388403808.94.0.778349216426.issue20095@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
components: +Interpreter Core -Regular Expressions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20095>
_______________________________________

From report at bugs.python.org  Mon Dec 30 13:16:32 2013
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Dec 2013 12:16:32 +0000
Subject: [issue19732] python fails to build when configured with
 --with-system-libmpdec
In-Reply-To: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za>
Message-ID: <1388405792.16.0.510881481809.issue19732@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I wanted to force people to link explicitly with -l:libmpdec.so.2 in
order to avoid picking up a wrong version.  But indeed that won't work
since the GNU linker happily picks up the static lib with -lmpdec if
libmpdec.so is missing.

The docs are part of my website repo and are copied manually as
part of the release process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19732>
_______________________________________

From report at bugs.python.org  Mon Dec 30 13:41:20 2013
From: report at bugs.python.org (Liam Marsh)
Date: Mon, 30 Dec 2013 12:41:20 +0000
Subject: [issue20095] what is that result!?
In-Reply-To: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>
Message-ID: <1388407280.93.0.934761202087.issue20095@psf.upfronthosting.co.za>


Liam Marsh added the comment:

can you add an approximation of the result in the command?
(ex: the biggest precision in the values is 0.1, so it won't show after 4.0)
meen while, thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20095>
_______________________________________

From report at bugs.python.org  Mon Dec 30 16:51:47 2013
From: report at bugs.python.org (=?utf-8?q?Kim_Gr=C3=A4sman?=)
Date: Mon, 30 Dec 2013 15:51:47 +0000
Subject: [issue18314] Have os.unlink remove junction points
In-Reply-To: <1372335321.1.0.479247042071.issue18314@psf.upfronthosting.co.za>
Message-ID: <1388418707.17.0.699182247009.issue18314@psf.upfronthosting.co.za>


Kim Gr?sman added the comment:

I really needed the well-wishing with regard to buffer sizing :-)

Here's a patch for a couple of fronts:
- Teach os.unlink about junction points
- Introduce _winapi.CreateJunction
- Introduce a new test suite in test_os.py for junction points

I pulled the definition of _REPARSE_DATA_BUFFER out into a new header called winreparse.h.

I'd appreciate critical review of _winapi.CreateJunction to make sure I haven't missed anything. I'm not familiar with the Python/C interop idioms, so I might have missed something wrt arguments/return values handling.

Happy new year!

----------
Added file: http://bugs.python.org/file33288/unlink-junctions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18314>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:06:01 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Dec 2013 16:06:01 +0000
Subject: [issue20047] bytearray partition bug
In-Reply-To: <1387655561.39.0.594856092375.issue20047@psf.upfronthosting.co.za>
Message-ID: <1388419561.01.0.510864109517.issue20047@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/issue20047>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:20:06 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Dec 2013 16:20:06 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388420406.38.0.481572988072.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Better doc enhancement thanks to R. David Murray (thanks!).

----------
Added file: http://bugs.python.org/file33289/issue19995.stoneleaf.03.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:25:31 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Dec 2013 16:25:31 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388420731.13.0.187394174252.issue19995@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/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:35:30 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 30 Dec 2013 16:35:30 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388421330.91.0.178426352025.issue19995@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

While I think this is an improvement, I don't think we can make this change in behavior at this stage in 3.4. Won't it have to go in 3.5?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 17:51:22 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Dec 2013 16:51:22 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388422282.69.0.468576325413.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I can see why we wouldn't want to make this change in a point release, but this is a feature release we're talking about and this seems like buggy behavior:

--> hex(3.14)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'float' object cannot be interpreted as an integer

--> '%x' % 3.14
'3'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:15:44 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 30 Dec 2013 18:15:44 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388427344.47.0.696368935519.issue19995@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree the behavior is bad and should be fixed. But it's a new feature that will break existing code, and 3.4 is in beta, and therefore feature freeze. Unfortunately, I think this has to go into 3.5, unless you can get Larry to grant you an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:38:37 2013
From: report at bugs.python.org (py.user)
Date: Mon, 30 Dec 2013 18:38:37 +0000
Subject: [issue18310] itertools.tee() can't accept keyword arguments
In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za>
Message-ID: <1388428717.21.0.285824889736.issue18310@psf.upfronthosting.co.za>


Changes by py.user <bugzilla-mail-box at yandex.ru>:


----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18310>
_______________________________________

From report at bugs.python.org  Mon Dec 30 19:52:22 2013
From: report at bugs.python.org (py.user)
Date: Mon, 30 Dec 2013 18:52:22 +0000
Subject: [issue18310] itertools.tee() can't accept keyword arguments
In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za>
Message-ID: <1388429542.65.0.437232632537.issue18310@psf.upfronthosting.co.za>


py.user added the comment:

for example
http://docs.python.org/3/library/itertools.html#itertools.permutations

has same description and it's a keyword

compare
"itertools.tee(iterable, n=2)"
"itertools.permutations(iterable, r=None)"


>>> itertools.permutations('abc')
<itertools.permutations object at 0x7ff563b17230>
>>> itertools.permutations('abc', r=2)
<itertools.permutations object at 0x7ff563b17290>
>>> 
>>> 
>>> itertools.tee('abc')
(<itertools._tee object at 0x7ff563a995f0>, <itertools._tee object at 0x7ff563a99638>)
>>> itertools.tee('abc', n=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: tee() takes no keyword arguments
>>>

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18310>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:06:03 2013
From: report at bugs.python.org (py.user)
Date: Mon, 30 Dec 2013 19:06:03 +0000
Subject: [issue18310] itertools.tee() can't accept keyword arguments
In-Reply-To: <1372270091.7.0.0269629805126.issue18310@psf.upfronthosting.co.za>
Message-ID: <1388430363.99.0.567454214628.issue18310@psf.upfronthosting.co.za>


Changes by py.user <bugzilla-mail-box at yandex.ru>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18310>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:43:50 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Dec 2013 19:43:50 +0000
Subject: [issue20096] Mention modernize and future in Python 2/3 porting HOWTO
Message-ID: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://github.com/mitsuhiko/python-modernize
http://python-future.org/

Should also restructure to de-emphasize 2to3 and other approaches. In all honesty it should probably be nearly gutted to just "here are examples of how to write Python 2/3 compatible code", point to appropriate libraries, and be done with it with a minimal mention of 2to3 and 3to2.

----------
assignee: docs at python
components: Documentation
messages: 207103
nosy: brett.cannon, docs at python
priority: normal
severity: normal
status: open
title: Mention modernize and future in Python 2/3 porting HOWTO
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20096>
_______________________________________

From report at bugs.python.org  Mon Dec 30 20:55:00 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 30 Dec 2013 19:55:00 +0000
Subject: [issue20096] Mention modernize and future in Python 2/3 porting HOWTO
In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>
Message-ID: <1388433300.42.0.539513533689.issue20096@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/issue20096>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:20:18 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 30 Dec 2013 20:20:18 +0000
Subject: [issue18604] Consolidate gui available checks in test.support
In-Reply-To: <1375229615.82.0.560303267268.issue18604@psf.upfronthosting.co.za>
Message-ID: <1388434818.65.0.873664330142.issue18604@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a patch for 3.4, and some sample verbose output[1] from the AMD64 Win7 buildbot (which runs buildbot as a service, and thus has no gui available).

[1] http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%20custom/builds/40/steps/test/logs/stdio

----------
keywords: +patch
nosy: +zach.ware
Added file: http://bugs.python.org/file33290/issue18604.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18604>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:26:42 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 30 Dec 2013 20:26:42 +0000
Subject: [issue20097] Bad use of `self` in importlib
Message-ID: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>


New submission from Ram Rachum:

There's a bad usage of `self` here:

    http://hg.python.org/cpython/file/fd846837492d/Lib/importlib/_bootstrap.py#l1431

`self` isn't defined because it's a class method.

----------
components: Library (Lib)
messages: 207105
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Bad use of `self` in importlib
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20097>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:29:38 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 30 Dec 2013 20:29:38 +0000
Subject: [issue20097] Bad use of `self` in importlib
In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>
Message-ID: <1388435378.38.0.309180540487.issue20097@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I don't see a class method at line 1431.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20097>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:32:27 2013
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 30 Dec 2013 20:32:27 +0000
Subject: [issue20097] Bad use of `self` in importlib
In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>
Message-ID: <1388435547.48.0.75879303274.issue20097@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Sorry, bad link, this is the right link:

http://hg.python.org/cpython/file/fd846837492d/Lib/importlib/_bootstrap.py#l1409

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20097>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:40:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Dec 2013 20:40:06 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <3dtVrP130Zz7Lk3@mail.python.org>


Roundup Robot added the comment:

New changeset 83f12a9593db by Zachary Ware in branch 'default':
Issue #19544, #6516: check ZLIB_SUPPORT, not zlib (which might not be bound)
http://hg.python.org/cpython/rev/83f12a9593db

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:40:06 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Dec 2013 20:40:06 +0000
Subject: [issue19544] Port distutils as found in Python 2.7 to Python 3.x.
In-Reply-To: <1384102792.62.0.350506434661.issue19544@psf.upfronthosting.co.za>
Message-ID: <3dtVrP6rzzz7Lk3@mail.python.org>


Roundup Robot added the comment:

New changeset 83f12a9593db by Zachary Ware in branch 'default':
Issue #19544, #6516: check ZLIB_SUPPORT, not zlib (which might not be bound)
http://hg.python.org/cpython/rev/83f12a9593db

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19544>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:40:47 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 30 Dec 2013 20:40:47 +0000
Subject: [issue20097] Bad use of `self` in importlib
In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>
Message-ID: <1388436047.1.0.00803588815961.issue20097@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks! :)

----------
assignee:  -> brett.cannon
nosy: +brett.cannon
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20097>
_______________________________________

From report at bugs.python.org  Mon Dec 30 21:54:23 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Dec 2013 20:54:23 +0000
Subject: [issue19619] Blacklist base64, hex,
 ... codecs from bytes.decode() and str.encode()
In-Reply-To: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za>
Message-ID: <3dtW8t1LH2z7LpB@mail.python.org>


Roundup Robot added the comment:

New changeset 0e10367c88ce by Zachary Ware in branch 'default':
Issue19619: skip zlib error test when zlib not available
http://hg.python.org/cpython/rev/0e10367c88ce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19619>
_______________________________________

From report at bugs.python.org  Mon Dec 30 22:09:26 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Dec 2013 21:09:26 +0000
Subject: [issue6516] reset owner/group to root for distutils tarballs
In-Reply-To: <1247933699.76.0.278346370296.issue6516@psf.upfronthosting.co.za>
Message-ID: <3dtWVG0jmvz7LnS@mail.python.org>


Roundup Robot added the comment:

New changeset 2a872126f4a1 by Zachary Ware in branch 'default':
Issue #19544, #6516: check ZLIB_SUPPORT, not zlib (which might not be bound)
http://hg.python.org/cpython/rev/2a872126f4a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6516>
_______________________________________

From report at bugs.python.org  Mon Dec 30 22:09:27 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Dec 2013 21:09:27 +0000
Subject: [issue19544] Port distutils as found in Python 2.7 to Python 3.x.
In-Reply-To: <1384102792.62.0.350506434661.issue19544@psf.upfronthosting.co.za>
Message-ID: <3dtWVG6PMfz7LnS@mail.python.org>


Roundup Robot added the comment:

New changeset 2a872126f4a1 by Zachary Ware in branch 'default':
Issue #19544, #6516: check ZLIB_SUPPORT, not zlib (which might not be bound)
http://hg.python.org/cpython/rev/2a872126f4a1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19544>
_______________________________________

From report at bugs.python.org  Mon Dec 30 22:51:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Dec 2013 21:51:51 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388440311.04.0.50693943998.issue19995@psf.upfronthosting.co.za>


R. David Murray added the comment:

We don't usually *break* existing working code even if the output is wrong.  If you want to make '%x' % 3.14, etc, raise an error, I think you we should go through a deprecation period first.  The deprecation messages should, of course, be added now.

In other words, I would probably have voted against commit even if we weren't in beta yet.  It's a bit borderline, since the output is *wrong*, but given that we *are* in beta I think we'd better go the deprecation route.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 22:57:04 2013
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Dec 2013 21:57:04 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388440624.95.0.279849037324.issue19995@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I can live with the deprecation route.  I'll create a patch today or tomorrow for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:04:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Dec 2013 22:04:51 +0000
Subject: [issue20097] Bad use of `self` in importlib
In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>
Message-ID: <1388441091.9.0.996333367681.issue20097@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20097>
_______________________________________

From report at bugs.python.org  Mon Dec 30 23:05:31 2013
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Dec 2013 22:05:31 +0000
Subject: [issue20097] Bad use of `self` in importlib
In-Reply-To: <1388435202.0.0.988564041108.issue20097@psf.upfronthosting.co.za>
Message-ID: <1388441131.19.0.553950342228.issue20097@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +Add tests for importlib.machinery.WindowsRegistryFinder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20097>
_______________________________________

From report at bugs.python.org  Thu Dec 26 22:43:12 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 21:43:12 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <52BC9AF6.2060303@egenix.com>
Message-ID: <1875808.QJB8RMQZ2H@raxxla>


Serhiy Storchaka added the comment:

> Could you add a test for the optimization function ?

I have no ideas. The optimization function is a part of the makelocalealias.py 
which ran manually very rarely (last time 3.5 year ago). It isn't exposed 
outside the script and I'm not sure that it worths the complication of the 
testing.

> It should make sure that a complete set of now removed locale
> names are properly optimized away, e.g.
> 
>      'nl_nl':                                'nl_NL.ISO8859-1',
> -    'nl_nl.88591':                          'nl_NL.ISO8859-1',
> -    'nl_nl.iso88591':                       'nl_NL.ISO8859-1',
> -    'nl_nl.iso885915':                      'nl_NL.ISO8859-15',
> -    'nl_nl.iso885915 at euro':                 'nl_NL.ISO8859-15',
> -    'nl_nl.utf8 at euro':                      'nl_NL.UTF-8',
> -    'nl_nl at euro':                           'nl_NL.ISO8859-15',

These cases are covered by test_english and test_euro_modifier.

>      'ja_jp':                                'ja_JP.eucJP',
> -    'ja_jp.ajec':                           'ja_JP.eucJP',
>      'ja_jp.euc':                            'ja_JP.eucJP',
> -    'ja_jp.eucjp':                          'ja_JP.eucJP',
> -    'ja_jp.iso-2022-jp':                    'ja_JP.JIS7',
> -    'ja_jp.iso2022jp':                      'ja_JP.JIS7',
> -    'ja_jp.jis':                            'ja_JP.JIS7',
> -    'ja_jp.jis7':                           'ja_JP.JIS7',
>      'ja_jp.mscode':                         'ja_JP.SJIS',
>      'ja_jp.pck':                            'ja_JP.SJIS',
> -    'ja_jp.sjis':                           'ja_JP.SJIS',
> -    'ja_jp.ujis':                           'ja_JP.eucJP',

Here is a test which includes tests for japanese cases end tests for the euc 
encoding (it maps to different encodings depending on language).

----------
Added file: http://bugs.python.org/file33273/locale_optimize_aliases_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________
-------------- next part --------------
diff -r fff3f28733b4 Lib/locale.py
--- a/Lib/locale.py	Thu Dec 26 21:21:52 2013 +0200
+++ b/Lib/locale.py	Thu Dec 26 23:40:17 2013 +0200
@@ -344,14 +344,32 @@
     # Convert the encoding to a C lib compatible encoding string
     norm_encoding = encodings.normalize_encoding(encoding)
     #print('norm encoding: %r' % norm_encoding)
-    norm_encoding = encodings.aliases.aliases.get(norm_encoding,
+    norm_encoding = encodings.aliases.aliases.get(norm_encoding.lower(),
                                                   norm_encoding)
     #print('aliased encoding: %r' % norm_encoding)
-    encoding = locale_encoding_alias.get(norm_encoding,
-                                         norm_encoding)
+    encoding = norm_encoding
+    norm_encoding = norm_encoding.lower()
+    if norm_encoding in locale_encoding_alias:
+        encoding = locale_encoding_alias[norm_encoding]
+    else:
+        norm_encoding = norm_encoding.replace('_', '')
+        norm_encoding = norm_encoding.replace('-', '')
+        if norm_encoding in locale_encoding_alias:
+            encoding = locale_encoding_alias[norm_encoding]
     #print('found encoding %r' % encoding)
     return langname + '.' + encoding
 
+def _append_modifier(code, modifier):
+    if modifier == 'euro':
+        if '.' not in code:
+            return code + '.ISO8859-15'
+        _, _, encoding = code.partition('.')
+        if encoding in ('ISO8859-15', 'UTF-8'):
+            return code
+        if encoding == 'ISO8859-1':
+            return _replace_encoding(code, 'ISO8859-15')
+    return code + '@' + modifier
+
 def normalize(localename):
 
     """ Returns a normalized locale code for the given locale
@@ -403,7 +421,7 @@
         if code is not None:
             #print('lookup without modifier succeeded')
             if '@' not in code:
-                return code + '@' + modifier
+                return _append_modifier(code, modifier)
             if code.split('@', 1)[1].lower() == modifier:
                 return code
         #print('second lookup failed')
@@ -427,7 +445,8 @@
             if code is not None:
                 #print('lookup without modifier and encoding succeeded')
                 if '@' not in code:
-                    return _replace_encoding(code, encoding) + '@' + modifier
+                    code = _replace_encoding(code, encoding)
+                    return _append_modifier(code, modifier)
                 code, defmod = code.split('@', 1)
                 if defmod.lower() == modifier:
                     return _replace_encoding(code, encoding) + '@' + defmod
@@ -643,6 +662,14 @@
     'jis':                          'JIS7',
     'jis7':                         'JIS7',
     'ajec':                         'eucJP',
+    'koi8c':                        'KOI8-C',
+    'microsoftcp1251':              'CP1251',
+    'microsoftcp1255':              'CP1255',
+    'microsoftcp1256':              'CP1256',
+    '88591':                        'ISO8859-1',
+    '88592':                        'ISO8859-2',
+    '88595':                        'ISO8859-5',
+    '885915':                       'ISO8859-15',
 
     # Mappings from Python codec names to C lib encoding names
     'ascii':                        'ISO8859-1',
@@ -670,10 +697,18 @@
     'utf_8':                        'UTF-8',
     'koi8_r':                       'KOI8-R',
     'koi8_u':                       'KOI8-U',
+    'cp1251':                       'CP1251',
+    'cp1255':                       'CP1255',
+    'cp1256':                       'CP1256',
+
     # XXX This list is still incomplete. If you know more
     # mappings, please file a bug report. Thanks.
 }
 
+for k, v in sorted(locale_encoding_alias.items()):
+    k = k.replace('_', '')
+    locale_encoding_alias.setdefault(k, v)
+
 #
 # The locale_alias table maps lowercase alias names to C locale names
 # (case-sensitive). Encodings are always separated from the locale
@@ -786,55 +821,33 @@
 locale_alias = {
     'a3':                                   'az_AZ.KOI8-C',
     'a3_az':                                'az_AZ.KOI8-C',
-    'a3_az.koi8c':                          'az_AZ.KOI8-C',
     'a3_az.koic':                           'az_AZ.KOI8-C',
     'af':                                   'af_ZA.ISO8859-1',
     'af_za':                                'af_ZA.ISO8859-1',
-    'af_za.iso88591':                       'af_ZA.ISO8859-1',
     'am':                                   'am_ET.UTF-8',
     'am_et':                                'am_ET.UTF-8',
     'american':                             'en_US.ISO8859-1',
-    'american.iso88591':                    'en_US.ISO8859-1',
     'ar':                                   'ar_AA.ISO8859-6',
     'ar_aa':                                'ar_AA.ISO8859-6',
-    'ar_aa.iso88596':                       'ar_AA.ISO8859-6',
     'ar_ae':                                'ar_AE.ISO8859-6',
-    'ar_ae.iso88596':                       'ar_AE.ISO8859-6',
     'ar_bh':                                'ar_BH.ISO8859-6',
-    'ar_bh.iso88596':                       'ar_BH.ISO8859-6',
     'ar_dz':                                'ar_DZ.ISO8859-6',
-    'ar_dz.iso88596':                       'ar_DZ.ISO8859-6',
     'ar_eg':                                'ar_EG.ISO8859-6',
-    'ar_eg.iso88596':                       'ar_EG.ISO8859-6',
     'ar_in':                                'ar_IN.UTF-8',
     'ar_iq':                                'ar_IQ.ISO8859-6',
-    'ar_iq.iso88596':                       'ar_IQ.ISO8859-6',
     'ar_jo':                                'ar_JO.ISO8859-6',
-    'ar_jo.iso88596':                       'ar_JO.ISO8859-6',
     'ar_kw':                                'ar_KW.ISO8859-6',
-    'ar_kw.iso88596':                       'ar_KW.ISO8859-6',
     'ar_lb':                                'ar_LB.ISO8859-6',
-    'ar_lb.iso88596':                       'ar_LB.ISO8859-6',
     'ar_ly':                                'ar_LY.ISO8859-6',
-    'ar_ly.iso88596':                       'ar_LY.ISO8859-6',
     'ar_ma':                                'ar_MA.ISO8859-6',
-    'ar_ma.iso88596':                       'ar_MA.ISO8859-6',
     'ar_om':                                'ar_OM.ISO8859-6',
-    'ar_om.iso88596':                       'ar_OM.ISO8859-6',
     'ar_qa':                                'ar_QA.ISO8859-6',
-    'ar_qa.iso88596':                       'ar_QA.ISO8859-6',
     'ar_sa':                                'ar_SA.ISO8859-6',
-    'ar_sa.iso88596':                       'ar_SA.ISO8859-6',
     'ar_sd':                                'ar_SD.ISO8859-6',
-    'ar_sd.iso88596':                       'ar_SD.ISO8859-6',
     'ar_sy':                                'ar_SY.ISO8859-6',
-    'ar_sy.iso88596':                       'ar_SY.ISO8859-6',
     'ar_tn':                                'ar_TN.ISO8859-6',
-    'ar_tn.iso88596':                       'ar_TN.ISO8859-6',
     'ar_ye':                                'ar_YE.ISO8859-6',
-    'ar_ye.iso88596':                       'ar_YE.ISO8859-6',
     'arabic':                               'ar_AA.ISO8859-6',
-    'arabic.iso88596':                      'ar_AA.ISO8859-6',
     'as':                                   'as_IN.UTF-8',
     'as_in':                                'as_IN.UTF-8',
     'az':                                   'az_AZ.ISO8859-9E',
@@ -843,35 +856,20 @@
     'be':                                   'be_BY.CP1251',
     'be at latin':                             'be_BY.UTF-8 at latin',
     'be_by':                                'be_BY.CP1251',
-    'be_by.cp1251':                         'be_BY.CP1251',
-    'be_by.microsoftcp1251':                'be_BY.CP1251',
-    'be_by.utf8 at latin':                     'be_BY.UTF-8 at latin',
     'be_by at latin':                          'be_BY.UTF-8 at latin',
     'bg':                                   'bg_BG.CP1251',
     'bg_bg':                                'bg_BG.CP1251',
-    'bg_bg.cp1251':                         'bg_BG.CP1251',
-    'bg_bg.iso88595':                       'bg_BG.ISO8859-5',
-    'bg_bg.koi8r':                          'bg_BG.KOI8-R',
-    'bg_bg.microsoftcp1251':                'bg_BG.CP1251',
     'bn_in':                                'bn_IN.UTF-8',
     'bo_in':                                'bo_IN.UTF-8',
     'bokmal':                               'nb_NO.ISO8859-1',
     'bokm\xe5l':                            'nb_NO.ISO8859-1',
     'br':                                   'br_FR.ISO8859-1',
     'br_fr':                                'br_FR.ISO8859-1',
-    'br_fr.iso88591':                       'br_FR.ISO8859-1',
-    'br_fr.iso885914':                      'br_FR.ISO8859-14',
-    'br_fr.iso885915':                      'br_FR.ISO8859-15',
-    'br_fr.iso885915 at euro':                 'br_FR.ISO8859-15',
-    'br_fr.utf8 at euro':                      'br_FR.UTF-8',
-    'br_fr at euro':                           'br_FR.ISO8859-15',
     'bs':                                   'bs_BA.ISO8859-2',
     'bs_ba':                                'bs_BA.ISO8859-2',
-    'bs_ba.iso88592':                       'bs_BA.ISO8859-2',
     'bulgarian':                            'bg_BG.CP1251',
     'c':                                    'C',
     'c-french':                             'fr_CA.ISO8859-1',
-    'c-french.iso88591':                    'fr_CA.ISO8859-1',
     'c.ascii':                              'C',
     'c.en':                                 'C',
     'c.iso88591':                           'en_US.ISO8859-1',
@@ -879,343 +877,131 @@
     'c_c.c':                                'C',
     'ca':                                   'ca_ES.ISO8859-1',
     'ca_ad':                                'ca_AD.ISO8859-1',
-    'ca_ad.iso88591':                       'ca_AD.ISO8859-1',
-    'ca_ad.iso885915':                      'ca_AD.ISO8859-15',
-    'ca_ad.iso885915 at euro':                 'ca_AD.ISO8859-15',
-    'ca_ad.utf8 at euro':                      'ca_AD.UTF-8',
-    'ca_ad at euro':                           'ca_AD.ISO8859-15',
     'ca_es':                                'ca_ES.ISO8859-1',
-    'ca_es.iso88591':                       'ca_ES.ISO8859-1',
-    'ca_es.iso885915':                      'ca_ES.ISO8859-15',
-    'ca_es.iso885915 at euro':                 'ca_ES.ISO8859-15',
-    'ca_es.utf8 at euro':                      'ca_ES.UTF-8',
-    'ca_es at euro':                           'ca_ES.ISO8859-15',
     'ca_fr':                                'ca_FR.ISO8859-1',
-    'ca_fr.iso88591':                       'ca_FR.ISO8859-1',
-    'ca_fr.iso885915':                      'ca_FR.ISO8859-15',
-    'ca_fr.iso885915 at euro':                 'ca_FR.ISO8859-15',
-    'ca_fr.utf8 at euro':                      'ca_FR.UTF-8',
-    'ca_fr at euro':                           'ca_FR.ISO8859-15',
     'ca_it':                                'ca_IT.ISO8859-1',
-    'ca_it.iso88591':                       'ca_IT.ISO8859-1',
-    'ca_it.iso885915':                      'ca_IT.ISO8859-15',
-    'ca_it.iso885915 at euro':                 'ca_IT.ISO8859-15',
-    'ca_it.utf8 at euro':                      'ca_IT.UTF-8',
-    'ca_it at euro':                           'ca_IT.ISO8859-15',
     'catalan':                              'ca_ES.ISO8859-1',
     'cextend':                              'en_US.ISO8859-1',
-    'cextend.en':                           'en_US.ISO8859-1',
     'chinese-s':                            'zh_CN.eucCN',
     'chinese-t':                            'zh_TW.eucTW',
     'croatian':                             'hr_HR.ISO8859-2',
     'cs':                                   'cs_CZ.ISO8859-2',
     'cs_cs':                                'cs_CZ.ISO8859-2',
-    'cs_cs.iso88592':                       'cs_CZ.ISO8859-2',
     'cs_cz':                                'cs_CZ.ISO8859-2',
-    'cs_cz.iso88592':                       'cs_CZ.ISO8859-2',
     'cy':                                   'cy_GB.ISO8859-1',
     'cy_gb':                                'cy_GB.ISO8859-1',
-    'cy_gb.iso88591':                       'cy_GB.ISO8859-1',
-    'cy_gb.iso885914':                      'cy_GB.ISO8859-14',
-    'cy_gb.iso885915':                      'cy_GB.ISO8859-15',
-    'cy_gb at euro':                           'cy_GB.ISO8859-15',
     'cz':                                   'cs_CZ.ISO8859-2',
     'cz_cz':                                'cs_CZ.ISO8859-2',
     'czech':                                'cs_CZ.ISO8859-2',
     'da':                                   'da_DK.ISO8859-1',
-    'da.iso885915':                         'da_DK.ISO8859-15',
     'da_dk':                                'da_DK.ISO8859-1',
-    'da_dk.88591':                          'da_DK.ISO8859-1',
-    'da_dk.885915':                         'da_DK.ISO8859-15',
-    'da_dk.iso88591':                       'da_DK.ISO8859-1',
-    'da_dk.iso885915':                      'da_DK.ISO8859-15',
-    'da_dk at euro':                           'da_DK.ISO8859-15',
     'danish':                               'da_DK.ISO8859-1',
-    'danish.iso88591':                      'da_DK.ISO8859-1',
     'dansk':                                'da_DK.ISO8859-1',
     'de':                                   'de_DE.ISO8859-1',
-    'de.iso885915':                         'de_DE.ISO8859-15',
     'de_at':                                'de_AT.ISO8859-1',
-    'de_at.iso88591':                       'de_AT.ISO8859-1',
-    'de_at.iso885915':                      'de_AT.ISO8859-15',
-    'de_at.iso885915 at euro':                 'de_AT.ISO8859-15',
-    'de_at.utf8 at euro':                      'de_AT.UTF-8',
-    'de_at at euro':                           'de_AT.ISO8859-15',
     'de_be':                                'de_BE.ISO8859-1',
-    'de_be.iso88591':                       'de_BE.ISO8859-1',
-    'de_be.iso885915':                      'de_BE.ISO8859-15',
-    'de_be.iso885915 at euro':                 'de_BE.ISO8859-15',
-    'de_be.utf8 at euro':                      'de_BE.UTF-8',
-    'de_be at euro':                           'de_BE.ISO8859-15',
     'de_ch':                                'de_CH.ISO8859-1',
-    'de_ch.iso88591':                       'de_CH.ISO8859-1',
-    'de_ch.iso885915':                      'de_CH.ISO8859-15',
-    'de_ch at euro':                           'de_CH.ISO8859-15',
     'de_de':                                'de_DE.ISO8859-1',
-    'de_de.88591':                          'de_DE.ISO8859-1',
-    'de_de.885915':                         'de_DE.ISO8859-15',
-    'de_de.885915 at euro':                    'de_DE.ISO8859-15',
-    'de_de.iso88591':                       'de_DE.ISO8859-1',
-    'de_de.iso885915':                      'de_DE.ISO8859-15',
-    'de_de.iso885915 at euro':                 'de_DE.ISO8859-15',
-    'de_de.utf8 at euro':                      'de_DE.UTF-8',
-    'de_de at euro':                           'de_DE.ISO8859-15',
     'de_lu':                                'de_LU.ISO8859-1',
-    'de_lu.iso88591':                       'de_LU.ISO8859-1',
-    'de_lu.iso885915':                      'de_LU.ISO8859-15',
-    'de_lu.iso885915 at euro':                 'de_LU.ISO8859-15',
-    'de_lu.utf8 at euro':                      'de_LU.UTF-8',
-    'de_lu at euro':                           'de_LU.ISO8859-15',
     'deutsch':                              'de_DE.ISO8859-1',
     'dutch':                                'nl_NL.ISO8859-1',
     'dutch.iso88591':                       'nl_BE.ISO8859-1',
     'ee':                                   'ee_EE.ISO8859-4',
     'ee_ee':                                'ee_EE.ISO8859-4',
-    'ee_ee.iso88594':                       'ee_EE.ISO8859-4',
     'eesti':                                'et_EE.ISO8859-1',
     'el':                                   'el_GR.ISO8859-7',
     'el_gr':                                'el_GR.ISO8859-7',
-    'el_gr.iso88597':                       'el_GR.ISO8859-7',
     'el_gr at euro':                           'el_GR.ISO8859-15',
     'en':                                   'en_US.ISO8859-1',
-    'en.iso88591':                          'en_US.ISO8859-1',
     'en_au':                                'en_AU.ISO8859-1',
-    'en_au.iso88591':                       'en_AU.ISO8859-1',
     'en_be':                                'en_BE.ISO8859-1',
-    'en_be at euro':                           'en_BE.ISO8859-15',
     'en_bw':                                'en_BW.ISO8859-1',
-    'en_bw.iso88591':                       'en_BW.ISO8859-1',
     'en_ca':                                'en_CA.ISO8859-1',
-    'en_ca.iso88591':                       'en_CA.ISO8859-1',
     'en_gb':                                'en_GB.ISO8859-1',
-    'en_gb.88591':                          'en_GB.ISO8859-1',
-    'en_gb.iso88591':                       'en_GB.ISO8859-1',
-    'en_gb.iso885915':                      'en_GB.ISO8859-15',
-    'en_gb at euro':                           'en_GB.ISO8859-15',
     'en_hk':                                'en_HK.ISO8859-1',
-    'en_hk.iso88591':                       'en_HK.ISO8859-1',
     'en_ie':                                'en_IE.ISO8859-1',
-    'en_ie.iso88591':                       'en_IE.ISO8859-1',
-    'en_ie.iso885915':                      'en_IE.ISO8859-15',
-    'en_ie.iso885915 at euro':                 'en_IE.ISO8859-15',
-    'en_ie.utf8 at euro':                      'en_IE.UTF-8',
-    'en_ie at euro':                           'en_IE.ISO8859-15',
     'en_in':                                'en_IN.ISO8859-1',
     'en_nz':                                'en_NZ.ISO8859-1',
-    'en_nz.iso88591':                       'en_NZ.ISO8859-1',
     'en_ph':                                'en_PH.ISO8859-1',
-    'en_ph.iso88591':                       'en_PH.ISO8859-1',
     'en_sg':                                'en_SG.ISO8859-1',
-    'en_sg.iso88591':                       'en_SG.ISO8859-1',
     'en_uk':                                'en_GB.ISO8859-1',
     'en_us':                                'en_US.ISO8859-1',
-    'en_us.88591':                          'en_US.ISO8859-1',
-    'en_us.885915':                         'en_US.ISO8859-15',
-    'en_us.iso88591':                       'en_US.ISO8859-1',
-    'en_us.iso885915':                      'en_US.ISO8859-15',
-    'en_us.iso885915 at euro':                 'en_US.ISO8859-15',
-    'en_us at euro':                           'en_US.ISO8859-15',
     'en_us at euro@euro':                      'en_US.ISO8859-15',
     'en_za':                                'en_ZA.ISO8859-1',
-    'en_za.88591':                          'en_ZA.ISO8859-1',
-    'en_za.iso88591':                       'en_ZA.ISO8859-1',
-    'en_za.iso885915':                      'en_ZA.ISO8859-15',
-    'en_za at euro':                           'en_ZA.ISO8859-15',
     'en_zw':                                'en_ZW.ISO8859-1',
-    'en_zw.iso88591':                       'en_ZW.ISO8859-1',
     'eng_gb':                               'en_GB.ISO8859-1',
-    'eng_gb.8859':                          'en_GB.ISO8859-1',
     'english':                              'en_EN.ISO8859-1',
-    'english.iso88591':                     'en_EN.ISO8859-1',
     'english_uk':                           'en_GB.ISO8859-1',
-    'english_uk.8859':                      'en_GB.ISO8859-1',
     'english_united-states':                'en_US.ISO8859-1',
     'english_united-states.437':            'C',
     'english_us':                           'en_US.ISO8859-1',
-    'english_us.8859':                      'en_US.ISO8859-1',
-    'english_us.ascii':                     'en_US.ISO8859-1',
     'eo':                                   'eo_XX.ISO8859-3',
     'eo_eo':                                'eo_EO.ISO8859-3',
-    'eo_eo.iso88593':                       'eo_EO.ISO8859-3',
     'eo_xx':                                'eo_XX.ISO8859-3',
-    'eo_xx.iso88593':                       'eo_XX.ISO8859-3',
     'es':                                   'es_ES.ISO8859-1',
     'es_ar':                                'es_AR.ISO8859-1',
-    'es_ar.iso88591':                       'es_AR.ISO8859-1',
     'es_bo':                                'es_BO.ISO8859-1',
-    'es_bo.iso88591':                       'es_BO.ISO8859-1',
     'es_cl':                                'es_CL.ISO8859-1',
-    'es_cl.iso88591':                       'es_CL.ISO8859-1',
     'es_co':                                'es_CO.ISO8859-1',
-    'es_co.iso88591':                       'es_CO.ISO8859-1',
     'es_cr':                                'es_CR.ISO8859-1',
-    'es_cr.iso88591':                       'es_CR.ISO8859-1',
     'es_do':                                'es_DO.ISO8859-1',
-    'es_do.iso88591':                       'es_DO.ISO8859-1',
     'es_ec':                                'es_EC.ISO8859-1',
-    'es_ec.iso88591':                       'es_EC.ISO8859-1',
     'es_es':                                'es_ES.ISO8859-1',
-    'es_es.88591':                          'es_ES.ISO8859-1',
-    'es_es.iso88591':                       'es_ES.ISO8859-1',
-    'es_es.iso885915':                      'es_ES.ISO8859-15',
-    'es_es.iso885915 at euro':                 'es_ES.ISO8859-15',
-    'es_es.utf8 at euro':                      'es_ES.UTF-8',
-    'es_es at euro':                           'es_ES.ISO8859-15',
     'es_gt':                                'es_GT.ISO8859-1',
-    'es_gt.iso88591':                       'es_GT.ISO8859-1',
     'es_hn':                                'es_HN.ISO8859-1',
-    'es_hn.iso88591':                       'es_HN.ISO8859-1',
     'es_mx':                                'es_MX.ISO8859-1',
-    'es_mx.iso88591':                       'es_MX.ISO8859-1',
     'es_ni':                                'es_NI.ISO8859-1',
-    'es_ni.iso88591':                       'es_NI.ISO8859-1',
     'es_pa':                                'es_PA.ISO8859-1',
-    'es_pa.iso88591':                       'es_PA.ISO8859-1',
-    'es_pa.iso885915':                      'es_PA.ISO8859-15',
-    'es_pa at euro':                           'es_PA.ISO8859-15',
     'es_pe':                                'es_PE.ISO8859-1',
-    'es_pe.iso88591':                       'es_PE.ISO8859-1',
-    'es_pe.iso885915':                      'es_PE.ISO8859-15',
-    'es_pe at euro':                           'es_PE.ISO8859-15',
     'es_pr':                                'es_PR.ISO8859-1',
-    'es_pr.iso88591':                       'es_PR.ISO8859-1',
     'es_py':                                'es_PY.ISO8859-1',
-    'es_py.iso88591':                       'es_PY.ISO8859-1',
-    'es_py.iso885915':                      'es_PY.ISO8859-15',
-    'es_py at euro':                           'es_PY.ISO8859-15',
     'es_sv':                                'es_SV.ISO8859-1',
-    'es_sv.iso88591':                       'es_SV.ISO8859-1',
-    'es_sv.iso885915':                      'es_SV.ISO8859-15',
-    'es_sv at euro':                           'es_SV.ISO8859-15',
     'es_us':                                'es_US.ISO8859-1',
-    'es_us.iso88591':                       'es_US.ISO8859-1',
     'es_uy':                                'es_UY.ISO8859-1',
-    'es_uy.iso88591':                       'es_UY.ISO8859-1',
-    'es_uy.iso885915':                      'es_UY.ISO8859-15',
-    'es_uy at euro':                           'es_UY.ISO8859-15',
     'es_ve':                                'es_VE.ISO8859-1',
-    'es_ve.iso88591':                       'es_VE.ISO8859-1',
-    'es_ve.iso885915':                      'es_VE.ISO8859-15',
-    'es_ve at euro':                           'es_VE.ISO8859-15',
     'estonian':                             'et_EE.ISO8859-1',
     'et':                                   'et_EE.ISO8859-15',
     'et_ee':                                'et_EE.ISO8859-15',
-    'et_ee.iso88591':                       'et_EE.ISO8859-1',
-    'et_ee.iso885913':                      'et_EE.ISO8859-13',
-    'et_ee.iso885915':                      'et_EE.ISO8859-15',
-    'et_ee.iso88594':                       'et_EE.ISO8859-4',
-    'et_ee at euro':                           'et_EE.ISO8859-15',
     'eu':                                   'eu_ES.ISO8859-1',
     'eu_es':                                'eu_ES.ISO8859-1',
-    'eu_es.iso88591':                       'eu_ES.ISO8859-1',
-    'eu_es.iso885915':                      'eu_ES.ISO8859-15',
-    'eu_es.iso885915 at euro':                 'eu_ES.ISO8859-15',
-    'eu_es.utf8 at euro':                      'eu_ES.UTF-8',
-    'eu_es at euro':                           'eu_ES.ISO8859-15',
     'fa':                                   'fa_IR.UTF-8',
     'fa_ir':                                'fa_IR.UTF-8',
     'fa_ir.isiri3342':                      'fa_IR.ISIRI-3342',
     'fi':                                   'fi_FI.ISO8859-15',
-    'fi.iso885915':                         'fi_FI.ISO8859-15',
     'fi_fi':                                'fi_FI.ISO8859-15',
-    'fi_fi.88591':                          'fi_FI.ISO8859-1',
-    'fi_fi.iso88591':                       'fi_FI.ISO8859-1',
-    'fi_fi.iso885915':                      'fi_FI.ISO8859-15',
-    'fi_fi.iso885915 at euro':                 'fi_FI.ISO8859-15',
-    'fi_fi.utf8 at euro':                      'fi_FI.UTF-8',
-    'fi_fi at euro':                           'fi_FI.ISO8859-15',
     'finnish':                              'fi_FI.ISO8859-1',
-    'finnish.iso88591':                     'fi_FI.ISO8859-1',
     'fo':                                   'fo_FO.ISO8859-1',
     'fo_fo':                                'fo_FO.ISO8859-1',
-    'fo_fo.iso88591':                       'fo_FO.ISO8859-1',
-    'fo_fo.iso885915':                      'fo_FO.ISO8859-15',
-    'fo_fo at euro':                           'fo_FO.ISO8859-15',
     'fr':                                   'fr_FR.ISO8859-1',
-    'fr.iso885915':                         'fr_FR.ISO8859-15',
     'fr_be':                                'fr_BE.ISO8859-1',
-    'fr_be.88591':                          'fr_BE.ISO8859-1',
-    'fr_be.iso88591':                       'fr_BE.ISO8859-1',
-    'fr_be.iso885915':                      'fr_BE.ISO8859-15',
-    'fr_be.iso885915 at euro':                 'fr_BE.ISO8859-15',
-    'fr_be.utf8 at euro':                      'fr_BE.UTF-8',
-    'fr_be at euro':                           'fr_BE.ISO8859-15',
     'fr_ca':                                'fr_CA.ISO8859-1',
-    'fr_ca.88591':                          'fr_CA.ISO8859-1',
-    'fr_ca.iso88591':                       'fr_CA.ISO8859-1',
-    'fr_ca.iso885915':                      'fr_CA.ISO8859-15',
-    'fr_ca at euro':                           'fr_CA.ISO8859-15',
     'fr_ch':                                'fr_CH.ISO8859-1',
-    'fr_ch.88591':                          'fr_CH.ISO8859-1',
-    'fr_ch.iso88591':                       'fr_CH.ISO8859-1',
-    'fr_ch.iso885915':                      'fr_CH.ISO8859-15',
-    'fr_ch at euro':                           'fr_CH.ISO8859-15',
     'fr_fr':                                'fr_FR.ISO8859-1',
-    'fr_fr.88591':                          'fr_FR.ISO8859-1',
-    'fr_fr.iso88591':                       'fr_FR.ISO8859-1',
-    'fr_fr.iso885915':                      'fr_FR.ISO8859-15',
-    'fr_fr.iso885915 at euro':                 'fr_FR.ISO8859-15',
-    'fr_fr.utf8 at euro':                      'fr_FR.UTF-8',
-    'fr_fr at euro':                           'fr_FR.ISO8859-15',
     'fr_lu':                                'fr_LU.ISO8859-1',
-    'fr_lu.88591':                          'fr_LU.ISO8859-1',
-    'fr_lu.iso88591':                       'fr_LU.ISO8859-1',
-    'fr_lu.iso885915':                      'fr_LU.ISO8859-15',
-    'fr_lu.iso885915 at euro':                 'fr_LU.ISO8859-15',
-    'fr_lu.utf8 at euro':                      'fr_LU.UTF-8',
-    'fr_lu at euro':                           'fr_LU.ISO8859-15',
     'fran\xe7ais':                          'fr_FR.ISO8859-1',
     'fre_fr':                               'fr_FR.ISO8859-1',
-    'fre_fr.8859':                          'fr_FR.ISO8859-1',
     'french':                               'fr_FR.ISO8859-1',
     'french.iso88591':                      'fr_CH.ISO8859-1',
     'french_france':                        'fr_FR.ISO8859-1',
-    'french_france.8859':                   'fr_FR.ISO8859-1',
     'ga':                                   'ga_IE.ISO8859-1',
     'ga_ie':                                'ga_IE.ISO8859-1',
-    'ga_ie.iso88591':                       'ga_IE.ISO8859-1',
-    'ga_ie.iso885914':                      'ga_IE.ISO8859-14',
-    'ga_ie.iso885915':                      'ga_IE.ISO8859-15',
-    'ga_ie.iso885915 at euro':                 'ga_IE.ISO8859-15',
-    'ga_ie.utf8 at euro':                      'ga_IE.UTF-8',
-    'ga_ie at euro':                           'ga_IE.ISO8859-15',
     'galego':                               'gl_ES.ISO8859-1',
     'galician':                             'gl_ES.ISO8859-1',
     'gd':                                   'gd_GB.ISO8859-1',
     'gd_gb':                                'gd_GB.ISO8859-1',
-    'gd_gb.iso88591':                       'gd_GB.ISO8859-1',
-    'gd_gb.iso885914':                      'gd_GB.ISO8859-14',
-    'gd_gb.iso885915':                      'gd_GB.ISO8859-15',
-    'gd_gb at euro':                           'gd_GB.ISO8859-15',
     'ger_de':                               'de_DE.ISO8859-1',
-    'ger_de.8859':                          'de_DE.ISO8859-1',
     'german':                               'de_DE.ISO8859-1',
     'german.iso88591':                      'de_CH.ISO8859-1',
     'german_germany':                       'de_DE.ISO8859-1',
-    'german_germany.8859':                  'de_DE.ISO8859-1',
     'gl':                                   'gl_ES.ISO8859-1',
     'gl_es':                                'gl_ES.ISO8859-1',
-    'gl_es.iso88591':                       'gl_ES.ISO8859-1',
-    'gl_es.iso885915':                      'gl_ES.ISO8859-15',
-    'gl_es.iso885915 at euro':                 'gl_ES.ISO8859-15',
-    'gl_es.utf8 at euro':                      'gl_ES.UTF-8',
-    'gl_es at euro':                           'gl_ES.ISO8859-15',
     'greek':                                'el_GR.ISO8859-7',
-    'greek.iso88597':                       'el_GR.ISO8859-7',
     'gu_in':                                'gu_IN.UTF-8',
     'gv':                                   'gv_GB.ISO8859-1',
     'gv_gb':                                'gv_GB.ISO8859-1',
-    'gv_gb.iso88591':                       'gv_GB.ISO8859-1',
-    'gv_gb.iso885914':                      'gv_GB.ISO8859-14',
-    'gv_gb.iso885915':                      'gv_GB.ISO8859-15',
-    'gv_gb at euro':                           'gv_GB.ISO8859-15',
     'he':                                   'he_IL.ISO8859-8',
     'he_il':                                'he_IL.ISO8859-8',
-    'he_il.cp1255':                         'he_IL.CP1255',
-    'he_il.iso88598':                       'he_IL.ISO8859-8',
-    'he_il.microsoftcp1255':                'he_IL.CP1255',
     'hebrew':                               'he_IL.ISO8859-8',
-    'hebrew.iso88598':                      'he_IL.ISO8859-8',
     'hi':                                   'hi_IN.ISCII-DEV',
     'hi_in':                                'hi_IN.ISCII-DEV',
     'hi_in.isciidev':                       'hi_IN.ISCII-DEV',
@@ -1223,23 +1009,17 @@
     'hne_in':                               'hne_IN.UTF-8',
     'hr':                                   'hr_HR.ISO8859-2',
     'hr_hr':                                'hr_HR.ISO8859-2',
-    'hr_hr.iso88592':                       'hr_HR.ISO8859-2',
     'hrvatski':                             'hr_HR.ISO8859-2',
     'hu':                                   'hu_HU.ISO8859-2',
     'hu_hu':                                'hu_HU.ISO8859-2',
-    'hu_hu.iso88592':                       'hu_HU.ISO8859-2',
     'hungarian':                            'hu_HU.ISO8859-2',
     'icelandic':                            'is_IS.ISO8859-1',
-    'icelandic.iso88591':                   'is_IS.ISO8859-1',
     'id':                                   'id_ID.ISO8859-1',
     'id_id':                                'id_ID.ISO8859-1',
     'in':                                   'id_ID.ISO8859-1',
     'in_id':                                'id_ID.ISO8859-1',
     'is':                                   'is_IS.ISO8859-1',
     'is_is':                                'is_IS.ISO8859-1',
-    'is_is.iso88591':                       'is_IS.ISO8859-1',
-    'is_is.iso885915':                      'is_IS.ISO8859-15',
-    'is_is at euro':                           'is_IS.ISO8859-15',
     'iso-8859-1':                           'en_US.ISO8859-1',
     'iso-8859-15':                          'en_US.ISO8859-15',
     'iso8859-1':                            'en_US.ISO8859-1',
@@ -1247,46 +1027,23 @@
     'iso_8859_1':                           'en_US.ISO8859-1',
     'iso_8859_15':                          'en_US.ISO8859-15',
     'it':                                   'it_IT.ISO8859-1',
-    'it.iso885915':                         'it_IT.ISO8859-15',
     'it_ch':                                'it_CH.ISO8859-1',
-    'it_ch.iso88591':                       'it_CH.ISO8859-1',
-    'it_ch.iso885915':                      'it_CH.ISO8859-15',
-    'it_ch at euro':                           'it_CH.ISO8859-15',
     'it_it':                                'it_IT.ISO8859-1',
-    'it_it.88591':                          'it_IT.ISO8859-1',
-    'it_it.iso88591':                       'it_IT.ISO8859-1',
-    'it_it.iso885915':                      'it_IT.ISO8859-15',
-    'it_it.iso885915 at euro':                 'it_IT.ISO8859-15',
-    'it_it.utf8 at euro':                      'it_IT.UTF-8',
-    'it_it at euro':                           'it_IT.ISO8859-15',
     'italian':                              'it_IT.ISO8859-1',
-    'italian.iso88591':                     'it_IT.ISO8859-1',
     'iu':                                   'iu_CA.NUNACOM-8',
     'iu_ca':                                'iu_CA.NUNACOM-8',
     'iu_ca.nunacom8':                       'iu_CA.NUNACOM-8',
     'iw':                                   'he_IL.ISO8859-8',
     'iw_il':                                'he_IL.ISO8859-8',
-    'iw_il.iso88598':                       'he_IL.ISO8859-8',
     'ja':                                   'ja_JP.eucJP',
-    'ja.jis':                               'ja_JP.JIS7',
-    'ja.sjis':                              'ja_JP.SJIS',
     'ja_jp':                                'ja_JP.eucJP',
-    'ja_jp.ajec':                           'ja_JP.eucJP',
     'ja_jp.euc':                            'ja_JP.eucJP',
-    'ja_jp.eucjp':                          'ja_JP.eucJP',
-    'ja_jp.iso-2022-jp':                    'ja_JP.JIS7',
-    'ja_jp.iso2022jp':                      'ja_JP.JIS7',
-    'ja_jp.jis':                            'ja_JP.JIS7',
-    'ja_jp.jis7':                           'ja_JP.JIS7',
     'ja_jp.mscode':                         'ja_JP.SJIS',
     'ja_jp.pck':                            'ja_JP.SJIS',
-    'ja_jp.sjis':                           'ja_JP.SJIS',
-    'ja_jp.ujis':                           'ja_JP.eucJP',
     'japan':                                'ja_JP.eucJP',
     'japanese':                             'ja_JP.eucJP',
     'japanese-euc':                         'ja_JP.eucJP',
     'japanese.euc':                         'ja_JP.eucJP',
-    'japanese.sjis':                        'ja_JP.SJIS',
     'jp_jp':                                'ja_JP.eucJP',
     'ka':                                   'ka_GE.GEORGIAN-ACADEMY',
     'ka_ge':                                'ka_GE.GEORGIAN-ACADEMY',
@@ -1295,27 +1052,18 @@
     'ka_ge.georgianrs':                     'ka_GE.GEORGIAN-ACADEMY',
     'kl':                                   'kl_GL.ISO8859-1',
     'kl_gl':                                'kl_GL.ISO8859-1',
-    'kl_gl.iso88591':                       'kl_GL.ISO8859-1',
-    'kl_gl.iso885915':                      'kl_GL.ISO8859-15',
-    'kl_gl at euro':                           'kl_GL.ISO8859-15',
     'km_kh':                                'km_KH.UTF-8',
     'kn':                                   'kn_IN.UTF-8',
     'kn_in':                                'kn_IN.UTF-8',
     'ko':                                   'ko_KR.eucKR',
     'ko_kr':                                'ko_KR.eucKR',
     'ko_kr.euc':                            'ko_KR.eucKR',
-    'ko_kr.euckr':                          'ko_KR.eucKR',
     'korean':                               'ko_KR.eucKR',
     'korean.euc':                           'ko_KR.eucKR',
     'ks':                                   'ks_IN.UTF-8',
     'ks_in':                                'ks_IN.UTF-8',
-    'ks_in at devanagari':                     'ks_IN.UTF-8 at devanagari',
     'kw':                                   'kw_GB.ISO8859-1',
     'kw_gb':                                'kw_GB.ISO8859-1',
-    'kw_gb.iso88591':                       'kw_GB.ISO8859-1',
-    'kw_gb.iso885914':                      'kw_GB.ISO8859-14',
-    'kw_gb.iso885915':                      'kw_GB.ISO8859-15',
-    'kw_gb at euro':                           'kw_GB.ISO8859-15',
     'ky':                                   'ky_KG.UTF-8',
     'ky_kg':                                'ky_KG.UTF-8',
     'lithuanian':                           'lt_LT.ISO8859-13',
@@ -1326,157 +1074,78 @@
     'lo_la.mulelao1':                       'lo_LA.MULELAO-1',
     'lt':                                   'lt_LT.ISO8859-13',
     'lt_lt':                                'lt_LT.ISO8859-13',
-    'lt_lt.iso885913':                      'lt_LT.ISO8859-13',
-    'lt_lt.iso88594':                       'lt_LT.ISO8859-4',
     'lv':                                   'lv_LV.ISO8859-13',
     'lv_lv':                                'lv_LV.ISO8859-13',
-    'lv_lv.iso885913':                      'lv_LV.ISO8859-13',
-    'lv_lv.iso88594':                       'lv_LV.ISO8859-4',
     'mai':                                  'mai_IN.UTF-8',
     'mai_in':                               'mai_IN.UTF-8',
     'mi':                                   'mi_NZ.ISO8859-1',
     'mi_nz':                                'mi_NZ.ISO8859-1',
-    'mi_nz.iso88591':                       'mi_NZ.ISO8859-1',
     'mk':                                   'mk_MK.ISO8859-5',
     'mk_mk':                                'mk_MK.ISO8859-5',
-    'mk_mk.cp1251':                         'mk_MK.CP1251',
-    'mk_mk.iso88595':                       'mk_MK.ISO8859-5',
-    'mk_mk.microsoftcp1251':                'mk_MK.CP1251',
     'ml':                                   'ml_IN.UTF-8',
     'ml_in':                                'ml_IN.UTF-8',
     'mr':                                   'mr_IN.UTF-8',
     'mr_in':                                'mr_IN.UTF-8',
     'ms':                                   'ms_MY.ISO8859-1',
     'ms_my':                                'ms_MY.ISO8859-1',
-    'ms_my.iso88591':                       'ms_MY.ISO8859-1',
     'mt':                                   'mt_MT.ISO8859-3',
     'mt_mt':                                'mt_MT.ISO8859-3',
-    'mt_mt.iso88593':                       'mt_MT.ISO8859-3',
     'nb':                                   'nb_NO.ISO8859-1',
     'nb_no':                                'nb_NO.ISO8859-1',
-    'nb_no.88591':                          'nb_NO.ISO8859-1',
-    'nb_no.iso88591':                       'nb_NO.ISO8859-1',
-    'nb_no.iso885915':                      'nb_NO.ISO8859-15',
-    'nb_no at euro':                           'nb_NO.ISO8859-15',
     'ne_np':                                'ne_NP.UTF-8',
     'nl':                                   'nl_NL.ISO8859-1',
-    'nl.iso885915':                         'nl_NL.ISO8859-15',
     'nl_be':                                'nl_BE.ISO8859-1',
-    'nl_be.88591':                          'nl_BE.ISO8859-1',
-    'nl_be.iso88591':                       'nl_BE.ISO8859-1',
-    'nl_be.iso885915':                      'nl_BE.ISO8859-15',
-    'nl_be.iso885915 at euro':                 'nl_BE.ISO8859-15',
-    'nl_be.utf8 at euro':                      'nl_BE.UTF-8',
-    'nl_be at euro':                           'nl_BE.ISO8859-15',
     'nl_nl':                                'nl_NL.ISO8859-1',
-    'nl_nl.88591':                          'nl_NL.ISO8859-1',
-    'nl_nl.iso88591':                       'nl_NL.ISO8859-1',
-    'nl_nl.iso885915':                      'nl_NL.ISO8859-15',
-    'nl_nl.iso885915 at euro':                 'nl_NL.ISO8859-15',
-    'nl_nl.utf8 at euro':                      'nl_NL.UTF-8',
-    'nl_nl at euro':                           'nl_NL.ISO8859-15',
     'nn':                                   'nn_NO.ISO8859-1',
     'nn_no':                                'nn_NO.ISO8859-1',
-    'nn_no.88591':                          'nn_NO.ISO8859-1',
-    'nn_no.iso88591':                       'nn_NO.ISO8859-1',
-    'nn_no.iso885915':                      'nn_NO.ISO8859-15',
-    'nn_no at euro':                           'nn_NO.ISO8859-15',
     'no':                                   'no_NO.ISO8859-1',
     'no at nynorsk':                           'ny_NO.ISO8859-1',
     'no_no':                                'no_NO.ISO8859-1',
-    'no_no.88591':                          'no_NO.ISO8859-1',
-    'no_no.iso88591':                       'no_NO.ISO8859-1',
-    'no_no.iso885915':                      'no_NO.ISO8859-15',
     'no_no.iso88591 at bokmal':                'no_NO.ISO8859-1',
     'no_no.iso88591 at nynorsk':               'no_NO.ISO8859-1',
-    'no_no at euro':                           'no_NO.ISO8859-15',
     'norwegian':                            'no_NO.ISO8859-1',
-    'norwegian.iso88591':                   'no_NO.ISO8859-1',
     'nr':                                   'nr_ZA.ISO8859-1',
     'nr_za':                                'nr_ZA.ISO8859-1',
-    'nr_za.iso88591':                       'nr_ZA.ISO8859-1',
     'nso':                                  'nso_ZA.ISO8859-15',
     'nso_za':                               'nso_ZA.ISO8859-15',
-    'nso_za.iso885915':                     'nso_ZA.ISO8859-15',
     'ny':                                   'ny_NO.ISO8859-1',
     'ny_no':                                'ny_NO.ISO8859-1',
-    'ny_no.88591':                          'ny_NO.ISO8859-1',
-    'ny_no.iso88591':                       'ny_NO.ISO8859-1',
-    'ny_no.iso885915':                      'ny_NO.ISO8859-15',
-    'ny_no at euro':                           'ny_NO.ISO8859-15',
     'nynorsk':                              'nn_NO.ISO8859-1',
     'oc':                                   'oc_FR.ISO8859-1',
     'oc_fr':                                'oc_FR.ISO8859-1',
-    'oc_fr.iso88591':                       'oc_FR.ISO8859-1',
-    'oc_fr.iso885915':                      'oc_FR.ISO8859-15',
-    'oc_fr at euro':                           'oc_FR.ISO8859-15',
     'or':                                   'or_IN.UTF-8',
     'or_in':                                'or_IN.UTF-8',
     'pa':                                   'pa_IN.UTF-8',
     'pa_in':                                'pa_IN.UTF-8',
     'pd':                                   'pd_US.ISO8859-1',
     'pd_de':                                'pd_DE.ISO8859-1',
-    'pd_de.iso88591':                       'pd_DE.ISO8859-1',
-    'pd_de.iso885915':                      'pd_DE.ISO8859-15',
-    'pd_de at euro':                           'pd_DE.ISO8859-15',
     'pd_us':                                'pd_US.ISO8859-1',
-    'pd_us.iso88591':                       'pd_US.ISO8859-1',
-    'pd_us.iso885915':                      'pd_US.ISO8859-15',
-    'pd_us at euro':                           'pd_US.ISO8859-15',
     'ph':                                   'ph_PH.ISO8859-1',
     'ph_ph':                                'ph_PH.ISO8859-1',
-    'ph_ph.iso88591':                       'ph_PH.ISO8859-1',
     'pl':                                   'pl_PL.ISO8859-2',
     'pl_pl':                                'pl_PL.ISO8859-2',
-    'pl_pl.iso88592':                       'pl_PL.ISO8859-2',
     'polish':                               'pl_PL.ISO8859-2',
     'portuguese':                           'pt_PT.ISO8859-1',
-    'portuguese.iso88591':                  'pt_PT.ISO8859-1',
     'portuguese_brazil':                    'pt_BR.ISO8859-1',
-    'portuguese_brazil.8859':               'pt_BR.ISO8859-1',
     'posix':                                'C',
     'posix-utf2':                           'C',
     'pp':                                   'pp_AN.ISO8859-1',
     'pp_an':                                'pp_AN.ISO8859-1',
-    'pp_an.iso88591':                       'pp_AN.ISO8859-1',
     'pt':                                   'pt_PT.ISO8859-1',
-    'pt.iso885915':                         'pt_PT.ISO8859-15',
     'pt_br':                                'pt_BR.ISO8859-1',
-    'pt_br.88591':                          'pt_BR.ISO8859-1',
-    'pt_br.iso88591':                       'pt_BR.ISO8859-1',
-    'pt_br.iso885915':                      'pt_BR.ISO8859-15',
-    'pt_br at euro':                           'pt_BR.ISO8859-15',
     'pt_pt':                                'pt_PT.ISO8859-1',
-    'pt_pt.88591':                          'pt_PT.ISO8859-1',
-    'pt_pt.iso88591':                       'pt_PT.ISO8859-1',
-    'pt_pt.iso885915':                      'pt_PT.ISO8859-15',
-    'pt_pt.iso885915 at euro':                 'pt_PT.ISO8859-15',
-    'pt_pt.utf8 at euro':                      'pt_PT.UTF-8',
-    'pt_pt at euro':                           'pt_PT.ISO8859-15',
     'ro':                                   'ro_RO.ISO8859-2',
     'ro_ro':                                'ro_RO.ISO8859-2',
-    'ro_ro.iso88592':                       'ro_RO.ISO8859-2',
     'romanian':                             'ro_RO.ISO8859-2',
     'ru':                                   'ru_RU.UTF-8',
-    'ru.koi8r':                             'ru_RU.KOI8-R',
     'ru_ru':                                'ru_RU.UTF-8',
-    'ru_ru.cp1251':                         'ru_RU.CP1251',
-    'ru_ru.iso88595':                       'ru_RU.ISO8859-5',
-    'ru_ru.koi8r':                          'ru_RU.KOI8-R',
-    'ru_ru.microsoftcp1251':                'ru_RU.CP1251',
     'ru_ua':                                'ru_UA.KOI8-U',
-    'ru_ua.cp1251':                         'ru_UA.CP1251',
-    'ru_ua.koi8u':                          'ru_UA.KOI8-U',
-    'ru_ua.microsoftcp1251':                'ru_UA.CP1251',
     'rumanian':                             'ro_RO.ISO8859-2',
     'russian':                              'ru_RU.ISO8859-5',
     'rw':                                   'rw_RW.ISO8859-1',
     'rw_rw':                                'rw_RW.ISO8859-1',
-    'rw_rw.iso88591':                       'rw_RW.ISO8859-1',
     'sd':                                   'sd_IN.UTF-8',
-    'sd at devanagari':                        'sd_IN.UTF-8 at devanagari',
     'sd_in':                                'sd_IN.UTF-8',
-    'sd_in at devanagari':                     'sd_IN.UTF-8 at devanagari',
     'se_no':                                'se_NO.UTF-8',
     'serbocroatian':                        'sr_RS.UTF-8 at latin',
     'sh':                                   'sr_RS.UTF-8 at latin',
@@ -1490,37 +1159,26 @@
     'sinhala':                              'si_LK.UTF-8',
     'sk':                                   'sk_SK.ISO8859-2',
     'sk_sk':                                'sk_SK.ISO8859-2',
-    'sk_sk.iso88592':                       'sk_SK.ISO8859-2',
     'sl':                                   'sl_SI.ISO8859-2',
     'sl_cs':                                'sl_CS.ISO8859-2',
     'sl_si':                                'sl_SI.ISO8859-2',
-    'sl_si.iso88592':                       'sl_SI.ISO8859-2',
     'slovak':                               'sk_SK.ISO8859-2',
     'slovene':                              'sl_SI.ISO8859-2',
     'slovenian':                            'sl_SI.ISO8859-2',
     'sp':                                   'sr_CS.ISO8859-5',
     'sp_yu':                                'sr_CS.ISO8859-5',
     'spanish':                              'es_ES.ISO8859-1',
-    'spanish.iso88591':                     'es_ES.ISO8859-1',
     'spanish_spain':                        'es_ES.ISO8859-1',
-    'spanish_spain.8859':                   'es_ES.ISO8859-1',
     'sq':                                   'sq_AL.ISO8859-2',
     'sq_al':                                'sq_AL.ISO8859-2',
-    'sq_al.iso88592':                       'sq_AL.ISO8859-2',
     'sr':                                   'sr_RS.UTF-8',
     'sr at cyrillic':                          'sr_RS.UTF-8',
-    'sr at latin':                             'sr_RS.UTF-8 at latin',
     'sr at latn':                              'sr_CS.UTF-8 at latin',
     'sr_cs':                                'sr_CS.UTF-8',
-    'sr_cs.iso88592':                       'sr_CS.ISO8859-2',
     'sr_cs.iso88592 at latn':                  'sr_CS.ISO8859-2',
-    'sr_cs.iso88595':                       'sr_CS.ISO8859-5',
-    'sr_cs.utf8 at latn':                      'sr_CS.UTF-8 at latin',
     'sr_cs at latn':                           'sr_CS.UTF-8 at latin',
     'sr_me':                                'sr_ME.UTF-8',
     'sr_rs':                                'sr_RS.UTF-8',
-    'sr_rs.utf8 at latn':                      'sr_RS.UTF-8 at latin',
-    'sr_rs at latin':                          'sr_RS.UTF-8 at latin',
     'sr_rs at latn':                           'sr_RS.UTF-8 at latin',
     'sr_sp':                                'sr_CS.ISO8859-2',
     'sr_yu':                                'sr_RS.UTF-8 at latin',
@@ -1529,29 +1187,15 @@
     'sr_yu.iso88595':                       'sr_CS.ISO8859-5',
     'sr_yu.iso88595 at cyrillic':              'sr_CS.ISO8859-5',
     'sr_yu.microsoftcp1251 at cyrillic':       'sr_CS.CP1251',
-    'sr_yu.utf8 at cyrillic':                  'sr_RS.UTF-8',
     'sr_yu at cyrillic':                       'sr_RS.UTF-8',
     'ss':                                   'ss_ZA.ISO8859-1',
     'ss_za':                                'ss_ZA.ISO8859-1',
-    'ss_za.iso88591':                       'ss_ZA.ISO8859-1',
     'st':                                   'st_ZA.ISO8859-1',
     'st_za':                                'st_ZA.ISO8859-1',
-    'st_za.iso88591':                       'st_ZA.ISO8859-1',
     'sv':                                   'sv_SE.ISO8859-1',
-    'sv.iso885915':                         'sv_SE.ISO8859-15',
     'sv_fi':                                'sv_FI.ISO8859-1',
-    'sv_fi.iso88591':                       'sv_FI.ISO8859-1',
-    'sv_fi.iso885915':                      'sv_FI.ISO8859-15',
-    'sv_fi.iso885915 at euro':                 'sv_FI.ISO8859-15',
-    'sv_fi.utf8 at euro':                      'sv_FI.UTF-8',
-    'sv_fi at euro':                           'sv_FI.ISO8859-15',
     'sv_se':                                'sv_SE.ISO8859-1',
-    'sv_se.88591':                          'sv_SE.ISO8859-1',
-    'sv_se.iso88591':                       'sv_SE.ISO8859-1',
-    'sv_se.iso885915':                      'sv_SE.ISO8859-15',
-    'sv_se at euro':                           'sv_SE.ISO8859-15',
     'swedish':                              'sv_SE.ISO8859-1',
-    'swedish.iso88591':                     'sv_SE.ISO8859-1',
     'ta':                                   'ta_IN.TSCII-0',
     'ta_in':                                'ta_IN.TSCII-0',
     'ta_in.tscii':                          'ta_IN.TSCII-0',
@@ -1559,49 +1203,33 @@
     'te':                                   'te_IN.UTF-8',
     'tg':                                   'tg_TJ.KOI8-C',
     'tg_tj':                                'tg_TJ.KOI8-C',
-    'tg_tj.koi8c':                          'tg_TJ.KOI8-C',
     'th':                                   'th_TH.ISO8859-11',
     'th_th':                                'th_TH.ISO8859-11',
-    'th_th.iso885911':                      'th_TH.ISO8859-11',
     'th_th.tactis':                         'th_TH.TIS620',
     'th_th.tis620':                         'th_TH.TIS620',
     'thai':                                 'th_TH.ISO8859-11',
     'tl':                                   'tl_PH.ISO8859-1',
     'tl_ph':                                'tl_PH.ISO8859-1',
-    'tl_ph.iso88591':                       'tl_PH.ISO8859-1',
     'tn':                                   'tn_ZA.ISO8859-15',
     'tn_za':                                'tn_ZA.ISO8859-15',
-    'tn_za.iso885915':                      'tn_ZA.ISO8859-15',
     'tr':                                   'tr_TR.ISO8859-9',
     'tr_tr':                                'tr_TR.ISO8859-9',
-    'tr_tr.iso88599':                       'tr_TR.ISO8859-9',
     'ts':                                   'ts_ZA.ISO8859-1',
     'ts_za':                                'ts_ZA.ISO8859-1',
-    'ts_za.iso88591':                       'ts_ZA.ISO8859-1',
     'tt':                                   'tt_RU.TATAR-CYR',
     'tt_ru':                                'tt_RU.TATAR-CYR',
-    'tt_ru.koi8c':                          'tt_RU.KOI8-C',
     'tt_ru.tatarcyr':                       'tt_RU.TATAR-CYR',
     'turkish':                              'tr_TR.ISO8859-9',
-    'turkish.iso88599':                     'tr_TR.ISO8859-9',
     'uk':                                   'uk_UA.KOI8-U',
     'uk_ua':                                'uk_UA.KOI8-U',
-    'uk_ua.cp1251':                         'uk_UA.CP1251',
-    'uk_ua.iso88595':                       'uk_UA.ISO8859-5',
-    'uk_ua.koi8u':                          'uk_UA.KOI8-U',
-    'uk_ua.microsoftcp1251':                'uk_UA.CP1251',
     'univ':                                 'en_US.utf',
     'universal':                            'en_US.utf',
     'universal.utf8 at ucs4':                  'en_US.UTF-8',
     'ur':                                   'ur_PK.CP1256',
     'ur_in':                                'ur_IN.UTF-8',
     'ur_pk':                                'ur_PK.CP1256',
-    'ur_pk.cp1256':                         'ur_PK.CP1256',
-    'ur_pk.microsoftcp1256':                'ur_PK.CP1256',
     'uz':                                   'uz_UZ.UTF-8',
     'uz_uz':                                'uz_UZ.UTF-8',
-    'uz_uz.iso88591':                       'uz_UZ.ISO8859-1',
-    'uz_uz.utf8 at cyrillic':                  'uz_UZ.UTF-8',
     'uz_uz at cyrillic':                       'uz_UZ.UTF-8',
     've':                                   've_ZA.UTF-8',
     've_za':                                've_ZA.UTF-8',
@@ -1613,35 +1241,21 @@
     'vi_vn.viscii111':                      'vi_VN.VISCII',
     'wa':                                   'wa_BE.ISO8859-1',
     'wa_be':                                'wa_BE.ISO8859-1',
-    'wa_be.iso88591':                       'wa_BE.ISO8859-1',
-    'wa_be.iso885915':                      'wa_BE.ISO8859-15',
-    'wa_be.iso885915 at euro':                 'wa_BE.ISO8859-15',
-    'wa_be at euro':                           'wa_BE.ISO8859-15',
     'xh':                                   'xh_ZA.ISO8859-1',
     'xh_za':                                'xh_ZA.ISO8859-1',
-    'xh_za.iso88591':                       'xh_ZA.ISO8859-1',
     'yi':                                   'yi_US.CP1255',
     'yi_us':                                'yi_US.CP1255',
-    'yi_us.cp1255':                         'yi_US.CP1255',
-    'yi_us.microsoftcp1255':                'yi_US.CP1255',
     'zh':                                   'zh_CN.eucCN',
     'zh_cn':                                'zh_CN.gb2312',
     'zh_cn.big5':                           'zh_TW.big5',
     'zh_cn.euc':                            'zh_CN.eucCN',
-    'zh_cn.gb18030':                        'zh_CN.gb18030',
-    'zh_cn.gb2312':                         'zh_CN.gb2312',
-    'zh_cn.gbk':                            'zh_CN.gbk',
     'zh_hk':                                'zh_HK.big5hkscs',
-    'zh_hk.big5':                           'zh_HK.big5',
     'zh_hk.big5hk':                         'zh_HK.big5hkscs',
-    'zh_hk.big5hkscs':                      'zh_HK.big5hkscs',
     'zh_tw':                                'zh_TW.big5',
-    'zh_tw.big5':                           'zh_TW.big5',
     'zh_tw.euc':                            'zh_TW.eucTW',
     'zh_tw.euctw':                          'zh_TW.eucTW',
     'zu':                                   'zu_ZA.ISO8859-1',
     'zu_za':                                'zu_ZA.ISO8859-1',
-    'zu_za.iso88591':                       'zu_ZA.ISO8859-1',
 }
 
 #
diff -r fff3f28733b4 Lib/test/test_locale.py
--- a/Lib/test/test_locale.py	Thu Dec 26 21:21:52 2013 +0200
+++ b/Lib/test/test_locale.py	Thu Dec 26 23:40:17 2013 +0200
@@ -384,6 +384,7 @@
     def test_english(self):
         self.check('en', 'en_US.ISO8859-1')
         self.check('EN', 'en_US.ISO8859-1')
+        self.check('en.iso88591', 'en_US.ISO8859-1')
         self.check('en_US', 'en_US.ISO8859-1')
         self.check('en_us', 'en_US.ISO8859-1')
         self.check('en_GB', 'en_GB.ISO8859-1')
@@ -392,7 +393,10 @@
         self.check('en_US:UTF-8', 'en_US.UTF-8')
         self.check('en_US.ISO8859-1', 'en_US.ISO8859-1')
         self.check('en_US.US-ASCII', 'en_US.ISO8859-1')
+        self.check('en_US.88591', 'en_US.ISO8859-1')
+        self.check('en_US.885915', 'en_US.ISO8859-15')
         self.check('english', 'en_EN.ISO8859-1')
+        self.check('english_uk.ascii', 'en_GB.ISO8859-1')
 
     def test_hyphenated_encoding(self):
         self.check('az_AZ.iso88599e', 'az_AZ.ISO8859-9E')
@@ -412,10 +416,12 @@
     def test_euro_modifier(self):
         self.check('de_DE at euro', 'de_DE.ISO8859-15')
         self.check('en_US.ISO8859-15 at euro', 'en_US.ISO8859-15')
+        self.check('de_DE.utf8 at euro', 'de_DE.UTF-8')
 
     def test_latin_modifier(self):
         self.check('be_BY.UTF-8 at latin', 'be_BY.UTF-8 at latin')
         self.check('sr_RS.UTF-8 at latin', 'sr_RS.UTF-8 at latin')
+        self.check('sr_RS.UTF-8 at latn', 'sr_RS.UTF-8 at latin')
 
     def test_valencia_modifier(self):
         self.check('ca_ES.UTF-8 at valencia', 'ca_ES.UTF-8 at valencia')
@@ -436,6 +442,39 @@
         self.check('sd_IN', 'sd_IN.UTF-8')
         self.check('sd', 'sd_IN.UTF-8')
 
+    def test_euc_encoding(self):
+        self.check('ja_jp.euc', 'ja_JP.eucJP')
+        self.check('ja_jp.eucjp', 'ja_JP.eucJP')
+        self.check('ko_kr.euc', 'ko_KR.eucKR')
+        self.check('ko_kr.euckr', 'ko_KR.eucKR')
+        self.check('zh_cn.euc', 'zh_CN.eucCN')
+        self.check('zh_tw.euc', 'zh_TW.eucTW')
+        self.check('zh_tw.euctw', 'zh_TW.eucTW')
+
+    def test_japanese(self):
+        self.check('ja', 'ja_JP.eucJP')
+        self.check('ja.jis', 'ja_JP.JIS7')
+        self.check('ja.sjis', 'ja_JP.SJIS')
+        self.check('ja_jp', 'ja_JP.eucJP')
+        self.check('ja_jp.ajec', 'ja_JP.eucJP')
+        self.check('ja_jp.euc', 'ja_JP.eucJP')
+        self.check('ja_jp.eucjp', 'ja_JP.eucJP')
+        self.check('ja_jp.iso-2022-jp', 'ja_JP.JIS7')
+        self.check('ja_jp.iso2022jp', 'ja_JP.JIS7')
+        self.check('ja_jp.jis', 'ja_JP.JIS7')
+        self.check('ja_jp.jis7', 'ja_JP.JIS7')
+        self.check('ja_jp.mscode', 'ja_JP.SJIS')
+        self.check('ja_jp.pck', 'ja_JP.SJIS')
+        self.check('ja_jp.sjis', 'ja_JP.SJIS')
+        self.check('ja_jp.ujis', 'ja_JP.eucJP')
+        self.check('ja_jp.utf8', 'ja_JP.UTF-8')
+        self.check('japan', 'ja_JP.eucJP')
+        self.check('japanese', 'ja_JP.eucJP')
+        self.check('japanese-euc', 'ja_JP.eucJP')
+        self.check('japanese.euc', 'ja_JP.eucJP')
+        self.check('japanese.sjis', 'ja_JP.SJIS')
+        self.check('jp_jp', 'ja_JP.eucJP')
+
 
 class TestMiscellaneous(unittest.TestCase):
     def test_getpreferredencoding(self):
diff -r fff3f28733b4 Tools/i18n/makelocalealias.py
--- a/Tools/i18n/makelocalealias.py	Thu Dec 26 21:21:52 2013 +0200
+++ b/Tools/i18n/makelocalealias.py	Thu Dec 26 23:40:17 2013 +0200
@@ -65,9 +65,22 @@
                   (k, olddata[k], data[k]))
         # Additions are not mentioned
 
+def optimize(data):
+    locale_alias = locale.locale_alias
+    locale.locale_alias = data.copy()
+    newdata = {}
+    for k, v in list(locale.locale_alias.items()):
+        del locale.locale_alias[k]
+        if locale.normalize(k) != v:
+            newdata[k] = v
+            locale.locale_alias[k] = v
+    locale.locale_alias = locale_alias
+    return newdata
+
 if __name__ == '__main__':
     data = locale.locale_alias.copy()
     data.update(parse(LOCALE_ALIAS))
+    data = optimize(data)
     print_differences(data, locale.locale_alias)
     print()
     print('locale_alias = {')

From report at bugs.python.org  Thu Dec 26 23:19:51 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Dec 2013 22:19:51 +0000
Subject: [issue20046] Optimize locale aliases table
In-Reply-To: <52BCA3F1.10806@egenix.com>
Message-ID: <106779183.O53krBhlYm@raxxla>


Serhiy Storchaka added the comment:

> I probably wasn't clear: I meant some tests that show that the
> alias definitions (on the left) from the X11 file are actually mapped to the
> correct alias locales (on the right).

This is how the optimization function works. It updates alias table with the 
X11 file, and then removes the alias entities one by one and checks that the 
alias definition are mapped to to correct alias locales.

Here is a patch which adds a self-check in the makelocalealias.py script.

----------
Added file: http://bugs.python.org/file33274/locale_optimize_aliases_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20046>
_______________________________________
-------------- next part --------------
diff -r fff3f28733b4 Lib/locale.py
--- a/Lib/locale.py	Thu Dec 26 21:21:52 2013 +0200
+++ b/Lib/locale.py	Fri Dec 27 00:18:30 2013 +0200
@@ -344,14 +344,32 @@
     # Convert the encoding to a C lib compatible encoding string
     norm_encoding = encodings.normalize_encoding(encoding)
     #print('norm encoding: %r' % norm_encoding)
-    norm_encoding = encodings.aliases.aliases.get(norm_encoding,
+    norm_encoding = encodings.aliases.aliases.get(norm_encoding.lower(),
                                                   norm_encoding)
     #print('aliased encoding: %r' % norm_encoding)
-    encoding = locale_encoding_alias.get(norm_encoding,
-                                         norm_encoding)
+    encoding = norm_encoding
+    norm_encoding = norm_encoding.lower()
+    if norm_encoding in locale_encoding_alias:
+        encoding = locale_encoding_alias[norm_encoding]
+    else:
+        norm_encoding = norm_encoding.replace('_', '')
+        norm_encoding = norm_encoding.replace('-', '')
+        if norm_encoding in locale_encoding_alias:
+            encoding = locale_encoding_alias[norm_encoding]
     #print('found encoding %r' % encoding)
     return langname + '.' + encoding
 
+def _append_modifier(code, modifier):
+    if modifier == 'euro':
+        if '.' not in code:
+            return code + '.ISO8859-15'
+        _, _, encoding = code.partition('.')
+        if encoding in ('ISO8859-15', 'UTF-8'):
+            return code
+        if encoding == 'ISO8859-1':
+            return _replace_encoding(code, 'ISO8859-15')
+    return code + '@' + modifier
+
 def normalize(localename):
 
     """ Returns a normalized locale code for the given locale
@@ -403,7 +421,7 @@
         if code is not None:
             #print('lookup without modifier succeeded')
             if '@' not in code:
-                return code + '@' + modifier
+                return _append_modifier(code, modifier)
             if code.split('@', 1)[1].lower() == modifier:
                 return code
         #print('second lookup failed')
@@ -427,7 +445,8 @@
             if code is not None:
                 #print('lookup without modifier and encoding succeeded')
                 if '@' not in code:
-                    return _replace_encoding(code, encoding) + '@' + modifier
+                    code = _replace_encoding(code, encoding)
+                    return _append_modifier(code, modifier)
                 code, defmod = code.split('@', 1)
                 if defmod.lower() == modifier:
                     return _replace_encoding(code, encoding) + '@' + defmod
@@ -643,6 +662,14 @@
     'jis':                          'JIS7',
     'jis7':                         'JIS7',
     'ajec':                         'eucJP',
+    'koi8c':                        'KOI8-C',
+    'microsoftcp1251':              'CP1251',
+    'microsoftcp1255':              'CP1255',
+    'microsoftcp1256':              'CP1256',
+    '88591':                        'ISO8859-1',
+    '88592':                        'ISO8859-2',
+    '88595':                        'ISO8859-5',
+    '885915':                       'ISO8859-15',
 
     # Mappings from Python codec names to C lib encoding names
     'ascii':                        'ISO8859-1',
@@ -670,10 +697,18 @@
     'utf_8':                        'UTF-8',
     'koi8_r':                       'KOI8-R',
     'koi8_u':                       'KOI8-U',
+    'cp1251':                       'CP1251',
+    'cp1255':                       'CP1255',
+    'cp1256':                       'CP1256',
+
     # XXX This list is still incomplete. If you know more
     # mappings, please file a bug report. Thanks.
 }
 
+for k, v in sorted(locale_encoding_alias.items()):
+    k = k.replace('_', '')
+    locale_encoding_alias.setdefault(k, v)
+
 #
 # The locale_alias table maps lowercase alias names to C locale names
 # (case-sensitive). Encodings are always separated from the locale
@@ -786,55 +821,33 @@
 locale_alias = {
     'a3':                                   'az_AZ.KOI8-C',
     'a3_az':                                'az_AZ.KOI8-C',
-    'a3_az.koi8c':                          'az_AZ.KOI8-C',
     'a3_az.koic':                           'az_AZ.KOI8-C',
     'af':                                   'af_ZA.ISO8859-1',
     'af_za':                                'af_ZA.ISO8859-1',
-    'af_za.iso88591':                       'af_ZA.ISO8859-1',
     'am':                                   'am_ET.UTF-8',
     'am_et':                                'am_ET.UTF-8',
     'american':                             'en_US.ISO8859-1',
-    'american.iso88591':                    'en_US.ISO8859-1',
     'ar':                                   'ar_AA.ISO8859-6',
     'ar_aa':                                'ar_AA.ISO8859-6',
-    'ar_aa.iso88596':                       'ar_AA.ISO8859-6',
     'ar_ae':                                'ar_AE.ISO8859-6',
-    'ar_ae.iso88596':                       'ar_AE.ISO8859-6',
     'ar_bh':                                'ar_BH.ISO8859-6',
-    'ar_bh.iso88596':                       'ar_BH.ISO8859-6',
     'ar_dz':                                'ar_DZ.ISO8859-6',
-    'ar_dz.iso88596':                       'ar_DZ.ISO8859-6',
     'ar_eg':                                'ar_EG.ISO8859-6',
-    'ar_eg.iso88596':                       'ar_EG.ISO8859-6',
     'ar_in':                                'ar_IN.UTF-8',
     'ar_iq':                                'ar_IQ.ISO8859-6',
-    'ar_iq.iso88596':                       'ar_IQ.ISO8859-6',
     'ar_jo':                                'ar_JO.ISO8859-6',
-    'ar_jo.iso88596':                       'ar_JO.ISO8859-6',
     'ar_kw':                                'ar_KW.ISO8859-6',
-    'ar_kw.iso88596':                       'ar_KW.ISO8859-6',
     'ar_lb':                                'ar_LB.ISO8859-6',
-    'ar_lb.iso88596':                       'ar_LB.ISO8859-6',
     'ar_ly':                                'ar_LY.ISO8859-6',
-    'ar_ly.iso88596':                       'ar_LY.ISO8859-6',
     'ar_ma':                                'ar_MA.ISO8859-6',
-    'ar_ma.iso88596':                       'ar_MA.ISO8859-6',
     'ar_om':                                'ar_OM.ISO8859-6',
-    'ar_om.iso88596':                       'ar_OM.ISO8859-6',
     'ar_qa':                                'ar_QA.ISO8859-6',
-    'ar_qa.iso88596':                       'ar_QA.ISO8859-6',
     'ar_sa':                                'ar_SA.ISO8859-6',
-    'ar_sa.iso88596':                       'ar_SA.ISO8859-6',
     'ar_sd':                                'ar_SD.ISO8859-6',
-    'ar_sd.iso88596':                       'ar_SD.ISO8859-6',
     'ar_sy':                                'ar_SY.ISO8859-6',
-    'ar_sy.iso88596':                       'ar_SY.ISO8859-6',
     'ar_tn':                                'ar_TN.ISO8859-6',
-    'ar_tn.iso88596':                       'ar_TN.ISO8859-6',
     'ar_ye':                                'ar_YE.ISO8859-6',
-    'ar_ye.iso88596':                       'ar_YE.ISO8859-6',
     'arabic':                               'ar_AA.ISO8859-6',
-    'arabic.iso88596':                      'ar_AA.ISO8859-6',
     'as':                                   'as_IN.UTF-8',
     'as_in':                                'as_IN.UTF-8',
     'az':                                   'az_AZ.ISO8859-9E',
@@ -843,35 +856,20 @@
     'be':                                   'be_BY.CP1251',
     'be at latin':                             'be_BY.UTF-8 at latin',
     'be_by':                                'be_BY.CP1251',
-    'be_by.cp1251':                         'be_BY.CP1251',
-    'be_by.microsoftcp1251':                'be_BY.CP1251',
-    'be_by.utf8 at latin':                     'be_BY.UTF-8 at latin',
     'be_by at latin':                          'be_BY.UTF-8 at latin',
     'bg':                                   'bg_BG.CP1251',
     'bg_bg':                                'bg_BG.CP1251',
-    'bg_bg.cp1251':                         'bg_BG.CP1251',
-    'bg_bg.iso88595':                       'bg_BG.ISO8859-5',
-    'bg_bg.koi8r':                          'bg_BG.KOI8-R',
-    'bg_bg.microsoftcp1251':                'bg_BG.CP1251',
     'bn_in':                                'bn_IN.UTF-8',
     'bo_in':                                'bo_IN.UTF-8',
     'bokmal':                               'nb_NO.ISO8859-1',
     'bokm\xe5l':                            'nb_NO.ISO8859-1',
     'br':                                   'br_FR.ISO8859-1',
     'br_fr':                                'br_FR.ISO8859-1',
-    'br_fr.iso88591':                       'br_FR.ISO8859-1',
-    'br_fr.iso885914':                      'br_FR.ISO8859-14',
-    'br_fr.iso885915':                      'br_FR.ISO8859-15',
-    'br_fr.iso885915 at euro':                 'br_FR.ISO8859-15',
-    'br_fr.utf8 at euro':                      'br_FR.UTF-8',
-    'br_fr at euro':                           'br_FR.ISO8859-15',
     'bs':                                   'bs_BA.ISO8859-2',
     'bs_ba':                                'bs_BA.ISO8859-2',
-    'bs_ba.iso88592':                       'bs_BA.ISO8859-2',
     'bulgarian':                            'bg_BG.CP1251',
     'c':                                    'C',
     'c-french':                             'fr_CA.ISO8859-1',
-    'c-french.iso88591':                    'fr_CA.ISO8859-1',
     'c.ascii':                              'C',
     'c.en':                                 'C',
     'c.iso88591':                           'en_US.ISO8859-1',
@@ -879,343 +877,131 @@
     'c_c.c':                                'C',
     'ca':                                   'ca_ES.ISO8859-1',
     'ca_ad':                                'ca_AD.ISO8859-1',
-    'ca_ad.iso88591':                       'ca_AD.ISO8859-1',
-    'ca_ad.iso885915':                      'ca_AD.ISO8859-15',
-    'ca_ad.iso885915 at euro':                 'ca_AD.ISO8859-15',
-    'ca_ad.utf8 at euro':                      'ca_AD.UTF-8',
-    'ca_ad at euro':                           'ca_AD.ISO8859-15',
     'ca_es':                                'ca_ES.ISO8859-1',
-    'ca_es.iso88591':                       'ca_ES.ISO8859-1',
-    'ca_es.iso885915':                      'ca_ES.ISO8859-15',
-    'ca_es.iso885915 at euro':                 'ca_ES.ISO8859-15',
-    'ca_es.utf8 at euro':                      'ca_ES.UTF-8',
-    'ca_es at euro':                           'ca_ES.ISO8859-15',
     'ca_fr':                                'ca_FR.ISO8859-1',
-    'ca_fr.iso88591':                       'ca_FR.ISO8859-1',
-    'ca_fr.iso885915':                      'ca_FR.ISO8859-15',
-    'ca_fr.iso885915 at euro':                 'ca_FR.ISO8859-15',
-    'ca_fr.utf8 at euro':                      'ca_FR.UTF-8',
-    'ca_fr at euro':                           'ca_FR.ISO8859-15',
     'ca_it':                                'ca_IT.ISO8859-1',
-    'ca_it.iso88591':                       'ca_IT.ISO8859-1',
-    'ca_it.iso885915':                      'ca_IT.ISO8859-15',
-    'ca_it.iso885915 at euro':                 'ca_IT.ISO8859-15',
-    'ca_it.utf8 at euro':                      'ca_IT.UTF-8',
-    'ca_it at euro':                           'ca_IT.ISO8859-15',
     'catalan':                              'ca_ES.ISO8859-1',
     'cextend':                              'en_US.ISO8859-1',
-    'cextend.en':                           'en_US.ISO8859-1',
     'chinese-s':                            'zh_CN.eucCN',
     'chinese-t':                            'zh_TW.eucTW',
     'croatian':                             'hr_HR.ISO8859-2',
     'cs':                                   'cs_CZ.ISO8859-2',
     'cs_cs':                                'cs_CZ.ISO8859-2',
-    'cs_cs.iso88592':                       'cs_CZ.ISO8859-2',
     'cs_cz':                                'cs_CZ.ISO8859-2',
-    'cs_cz.iso88592':                       'cs_CZ.ISO8859-2',
     'cy':                                   'cy_GB.ISO8859-1',
     'cy_gb':                                'cy_GB.ISO8859-1',
-    'cy_gb.iso88591':                       'cy_GB.ISO8859-1',
-    'cy_gb.iso885914':                      'cy_GB.ISO8859-14',
-    'cy_gb.iso885915':                      'cy_GB.ISO8859-15',
-    'cy_gb at euro':                           'cy_GB.ISO8859-15',
     'cz':                                   'cs_CZ.ISO8859-2',
     'cz_cz':                                'cs_CZ.ISO8859-2',
     'czech':                                'cs_CZ.ISO8859-2',
     'da':                                   'da_DK.ISO8859-1',
-    'da.iso885915':                         'da_DK.ISO8859-15',
     'da_dk':                                'da_DK.ISO8859-1',
-    'da_dk.88591':                          'da_DK.ISO8859-1',
-    'da_dk.885915':                         'da_DK.ISO8859-15',
-    'da_dk.iso88591':                       'da_DK.ISO8859-1',
-    'da_dk.iso885915':                      'da_DK.ISO8859-15',
-    'da_dk at euro':                           'da_DK.ISO8859-15',
     'danish':                               'da_DK.ISO8859-1',
-    'danish.iso88591':                      'da_DK.ISO8859-1',
     'dansk':                                'da_DK.ISO8859-1',
     'de':                                   'de_DE.ISO8859-1',
-    'de.iso885915':                         'de_DE.ISO8859-15',
     'de_at':                                'de_AT.ISO8859-1',
-    'de_at.iso88591':                       'de_AT.ISO8859-1',
-    'de_at.iso885915':                      'de_AT.ISO8859-15',
-    'de_at.iso885915 at euro':                 'de_AT.ISO8859-15',
-    'de_at.utf8 at euro':                      'de_AT.UTF-8',
-    'de_at at euro':                           'de_AT.ISO8859-15',
     'de_be':                                'de_BE.ISO8859-1',
-    'de_be.iso88591':                       'de_BE.ISO8859-1',
-    'de_be.iso885915':                      'de_BE.ISO8859-15',
-    'de_be.iso885915 at euro':                 'de_BE.ISO8859-15',
-    'de_be.utf8 at euro':                      'de_BE.UTF-8',
-    'de_be at euro':                           'de_BE.ISO8859-15',
     'de_ch':                                'de_CH.ISO8859-1',
-    'de_ch.iso88591':                       'de_CH.ISO8859-1',
-    'de_ch.iso885915':                      'de_CH.ISO8859-15',
-    'de_ch at euro':                           'de_CH.ISO8859-15',
     'de_de':                                'de_DE.ISO8859-1',
-    'de_de.88591':                          'de_DE.ISO8859-1',
-    'de_de.885915':                         'de_DE.ISO8859-15',
-    'de_de.885915 at euro':                    'de_DE.ISO8859-15',
-    'de_de.iso88591':                       'de_DE.ISO8859-1',
-    'de_de.iso885915':                      'de_DE.ISO8859-15',
-    'de_de.iso885915 at euro':                 'de_DE.ISO8859-15',
-    'de_de.utf8 at euro':                      'de_DE.UTF-8',
-    'de_de at euro':                           'de_DE.ISO8859-15',
     'de_lu':                                'de_LU.ISO8859-1',
-    'de_lu.iso88591':                       'de_LU.ISO8859-1',
-    'de_lu.iso885915':                      'de_LU.ISO8859-15',
-    'de_lu.iso885915 at euro':                 'de_LU.ISO8859-15',
-    'de_lu.utf8 at euro':                      'de_LU.UTF-8',
-    'de_lu at euro':                           'de_LU.ISO8859-15',
     'deutsch':                              'de_DE.ISO8859-1',
     'dutch':                                'nl_NL.ISO8859-1',
     'dutch.iso88591':                       'nl_BE.ISO8859-1',
     'ee':                                   'ee_EE.ISO8859-4',
     'ee_ee':                                'ee_EE.ISO8859-4',
-    'ee_ee.iso88594':                       'ee_EE.ISO8859-4',
     'eesti':                                'et_EE.ISO8859-1',
     'el':                                   'el_GR.ISO8859-7',
     'el_gr':                                'el_GR.ISO8859-7',
-    'el_gr.iso88597':                       'el_GR.ISO8859-7',
     'el_gr at euro':                           'el_GR.ISO8859-15',
     'en':                                   'en_US.ISO8859-1',
-    'en.iso88591':                          'en_US.ISO8859-1',
     'en_au':                                'en_AU.ISO8859-1',
-    'en_au.iso88591':                       'en_AU.ISO8859-1',
     'en_be':                                'en_BE.ISO8859-1',
-    'en_be at euro':                           'en_BE.ISO8859-15',
     'en_bw':                                'en_BW.ISO8859-1',
-    'en_bw.iso88591':                       'en_BW.ISO8859-1',
     'en_ca':                                'en_CA.ISO8859-1',
-    'en_ca.iso88591':                       'en_CA.ISO8859-1',
     'en_gb':                                'en_GB.ISO8859-1',
-    'en_gb.88591':                          'en_GB.ISO8859-1',
-    'en_gb.iso88591':                       'en_GB.ISO8859-1',
-    'en_gb.iso885915':                      'en_GB.ISO8859-15',
-    'en_gb at euro':                           'en_GB.ISO8859-15',
     'en_hk':                                'en_HK.ISO8859-1',
-    'en_hk.iso88591':                       'en_HK.ISO8859-1',
     'en_ie':                                'en_IE.ISO8859-1',
-    'en_ie.iso88591':                       'en_IE.ISO8859-1',
-    'en_ie.iso885915':                      'en_IE.ISO8859-15',
-    'en_ie.iso885915 at euro':                 'en_IE.ISO8859-15',
-    'en_ie.utf8 at euro':                      'en_IE.UTF-8',
-    'en_ie at euro':                           'en_IE.ISO8859-15',
     'en_in':                                'en_IN.ISO8859-1',
     'en_nz':                                'en_NZ.ISO8859-1',
-    'en_nz.iso88591':                       'en_NZ.ISO8859-1',
     'en_ph':                                'en_PH.ISO8859-1',
-    'en_ph.iso88591':                       'en_PH.ISO8859-1',
     'en_sg':                                'en_SG.ISO8859-1',
-    'en_sg.iso88591':                       'en_SG.ISO8859-1',
     'en_uk':                                'en_GB.ISO8859-1',
     'en_us':                                'en_US.ISO8859-1',
-    'en_us.88591':                          'en_US.ISO8859-1',
-    'en_us.885915':                         'en_US.ISO8859-15',
-    'en_us.iso88591':                       'en_US.ISO8859-1',
-    'en_us.iso885915':                      'en_US.ISO8859-15',
-    'en_us.iso885915 at euro':                 'en_US.ISO8859-15',
-    'en_us at euro':                           'en_US.ISO8859-15',
     'en_us at euro@euro':                      'en_US.ISO8859-15',
     'en_za':                                'en_ZA.ISO8859-1',
-    'en_za.88591':                          'en_ZA.ISO8859-1',
-    'en_za.iso88591':                       'en_ZA.ISO8859-1',
-    'en_za.iso885915':                      'en_ZA.ISO8859-15',
-    'en_za at euro':                           'en_ZA.ISO8859-15',
     'en_zw':                                'en_ZW.ISO8859-1',
-    'en_zw.iso88591':                       'en_ZW.ISO8859-1',
     'eng_gb':                               'en_GB.ISO8859-1',
-    'eng_gb.8859':                          'en_GB.ISO8859-1',
     'english':                              'en_EN.ISO8859-1',
-    'english.iso88591':                     'en_EN.ISO8859-1',
     'english_uk':                           'en_GB.ISO8859-1',
-    'english_uk.8859':                      'en_GB.ISO8859-1',
     'english_united-states':                'en_US.ISO8859-1',
     'english_united-states.437':            'C',
     'english_us':                           'en_US.ISO8859-1',
-    'english_us.8859':                      'en_US.ISO8859-1',
-    'english_us.ascii':                     'en_US.ISO8859-1',
     'eo':                                   'eo_XX.ISO8859-3',
     'eo_eo':                                'eo_EO.ISO8859-3',
-    'eo_eo.iso88593':                       'eo_EO.ISO8859-3',
     'eo_xx':                                'eo_XX.ISO8859-3',
-    'eo_xx.iso88593':                       'eo_XX.ISO8859-3',
     'es':                                   'es_ES.ISO8859-1',
     'es_ar':                                'es_AR.ISO8859-1',
-    'es_ar.iso88591':                       'es_AR.ISO8859-1',
     'es_bo':                                'es_BO.ISO8859-1',
-    'es_bo.iso88591':                       'es_BO.ISO8859-1',
     'es_cl':                                'es_CL.ISO8859-1',
-    'es_cl.iso88591':                       'es_CL.ISO8859-1',
     'es_co':                                'es_CO.ISO8859-1',
-    'es_co.iso88591':                       'es_CO.ISO8859-1',
     'es_cr':                                'es_CR.ISO8859-1',
-    'es_cr.iso88591':                       'es_CR.ISO8859-1',
     'es_do':                                'es_DO.ISO8859-1',
-    'es_do.iso88591':                       'es_DO.ISO8859-1',
     'es_ec':                                'es_EC.ISO8859-1',
-    'es_ec.iso88591':                       'es_EC.ISO8859-1',
     'es_es':                                'es_ES.ISO8859-1',
-    'es_es.88591':                          'es_ES.ISO8859-1',
-    'es_es.iso88591':                       'es_ES.ISO8859-1',
-    'es_es.iso885915':                      'es_ES.ISO8859-15',
-    'es_es.iso885915 at euro':                 'es_ES.ISO8859-15',
-    'es_es.utf8 at euro':                      'es_ES.UTF-8',
-    'es_es at euro':                           'es_ES.ISO8859-15',
     'es_gt':                                'es_GT.ISO8859-1',
-    'es_gt.iso88591':                       'es_GT.ISO8859-1',
     'es_hn':                                'es_HN.ISO8859-1',
-    'es_hn.iso88591':                       'es_HN.ISO8859-1',
     'es_mx':                                'es_MX.ISO8859-1',
-    'es_mx.iso88591':                       'es_MX.ISO8859-1',
     'es_ni':                                'es_NI.ISO8859-1',
-    'es_ni.iso88591':                       'es_NI.ISO8859-1',
     'es_pa':                                'es_PA.ISO8859-1',
-    'es_pa.iso88591':                       'es_PA.ISO8859-1',
-    'es_pa.iso885915':                      'es_PA.ISO8859-15',
-    'es_pa at euro':                           'es_PA.ISO8859-15',
     'es_pe':                                'es_PE.ISO8859-1',
-    'es_pe.iso88591':                       'es_PE.ISO8859-1',
-    'es_pe.iso885915':                      'es_PE.ISO8859-15',
-    'es_pe at euro':                           'es_PE.ISO8859-15',
     'es_pr':                                'es_PR.ISO8859-1',
-    'es_pr.iso88591':                       'es_PR.ISO8859-1',
     'es_py':                                'es_PY.ISO8859-1',
-    'es_py.iso88591':                       'es_PY.ISO8859-1',
-    'es_py.iso885915':                      'es_PY.ISO8859-15',
-    'es_py at euro':                           'es_PY.ISO8859-15',
     'es_sv':                                'es_SV.ISO8859-1',
-    'es_sv.iso88591':                       'es_SV.ISO8859-1',
-    'es_sv.iso885915':                      'es_SV.ISO8859-15',
-    'es_sv at euro':                           'es_SV.ISO8859-15',
     'es_us':                                'es_US.ISO8859-1',
-    'es_us.iso88591':                       'es_US.ISO8859-1',
     'es_uy':                                'es_UY.ISO8859-1',
-    'es_uy.iso88591':                       'es_UY.ISO8859-1',
-    'es_uy.iso885915':                      'es_UY.ISO8859-15',
-    'es_uy at euro':                           'es_UY.ISO8859-15',
     'es_ve':                                'es_VE.ISO8859-1',
-    'es_ve.iso88591':                       'es_VE.ISO8859-1',
-    'es_ve.iso885915':                      'es_VE.ISO8859-15',
-    'es_ve at euro':                           'es_VE.ISO8859-15',
     'estonian':                             'et_EE.ISO8859-1',
     'et':                                   'et_EE.ISO8859-15',
     'et_ee':                                'et_EE.ISO8859-15',
-    'et_ee.iso88591':                       'et_EE.ISO8859-1',
-    'et_ee.iso885913':                      'et_EE.ISO8859-13',
-    'et_ee.iso885915':                      'et_EE.ISO8859-15',
-    'et_ee.iso88594':                       'et_EE.ISO8859-4',
-    'et_ee at euro':                           'et_EE.ISO8859-15',
     'eu':                                   'eu_ES.ISO8859-1',
     'eu_es':                                'eu_ES.ISO8859-1',
-    'eu_es.iso88591':                       'eu_ES.ISO8859-1',
-    'eu_es.iso885915':                      'eu_ES.ISO8859-15',
-    'eu_es.iso885915 at euro':                 'eu_ES.ISO8859-15',
-    'eu_es.utf8 at euro':                      'eu_ES.UTF-8',
-    'eu_es at euro':                           'eu_ES.ISO8859-15',
     'fa':                                   'fa_IR.UTF-8',
     'fa_ir':                                'fa_IR.UTF-8',
     'fa_ir.isiri3342':                      'fa_IR.ISIRI-3342',
     'fi':                                   'fi_FI.ISO8859-15',
-    'fi.iso885915':                         'fi_FI.ISO8859-15',
     'fi_fi':                                'fi_FI.ISO8859-15',
-    'fi_fi.88591':                          'fi_FI.ISO8859-1',
-    'fi_fi.iso88591':                       'fi_FI.ISO8859-1',
-    'fi_fi.iso885915':                      'fi_FI.ISO8859-15',
-    'fi_fi.iso885915 at euro':                 'fi_FI.ISO8859-15',
-    'fi_fi.utf8 at euro':                      'fi_FI.UTF-8',
-    'fi_fi at euro':                           'fi_FI.ISO8859-15',
     'finnish':                              'fi_FI.ISO8859-1',
-    'finnish.iso88591':                     'fi_FI.ISO8859-1',
     'fo':                                   'fo_FO.ISO8859-1',
     'fo_fo':                                'fo_FO.ISO8859-1',
-    'fo_fo.iso88591':                       'fo_FO.ISO8859-1',
-    'fo_fo.iso885915':                      'fo_FO.ISO8859-15',
-    'fo_fo at euro':                           'fo_FO.ISO8859-15',
     'fr':                                   'fr_FR.ISO8859-1',
-    'fr.iso885915':                         'fr_FR.ISO8859-15',
     'fr_be':                                'fr_BE.ISO8859-1',
-    'fr_be.88591':                          'fr_BE.ISO8859-1',
-    'fr_be.iso88591':                       'fr_BE.ISO8859-1',
-    'fr_be.iso885915':                      'fr_BE.ISO8859-15',
-    'fr_be.iso885915 at euro':                 'fr_BE.ISO8859-15',
-    'fr_be.utf8 at euro':                      'fr_BE.UTF-8',
-    'fr_be at euro':                           'fr_BE.ISO8859-15',
     'fr_ca':                                'fr_CA.ISO8859-1',
-    'fr_ca.88591':                          'fr_CA.ISO8859-1',
-    'fr_ca.iso88591':                       'fr_CA.ISO8859-1',
-    'fr_ca.iso885915':                      'fr_CA.ISO8859-15',
-    'fr_ca at euro':                           'fr_CA.ISO8859-15',
     'fr_ch':                                'fr_CH.ISO8859-1',
-    'fr_ch.88591':                          'fr_CH.ISO8859-1',
-    'fr_ch.iso88591':                       'fr_CH.ISO8859-1',
-    'fr_ch.iso885915':                      'fr_CH.ISO8859-15',
-    'fr_ch at euro':                           'fr_CH.ISO8859-15',
     'fr_fr':                                'fr_FR.ISO8859-1',
-    'fr_fr.88591':                          'fr_FR.ISO8859-1',
-    'fr_fr.iso88591':                       'fr_FR.ISO8859-1',
-    'fr_fr.iso885915':                      'fr_FR.ISO8859-15',
-    'fr_fr.iso885915 at euro':                 'fr_FR.ISO8859-15',
-    'fr_fr.utf8 at euro':                      'fr_FR.UTF-8',
-    'fr_fr at euro':                           'fr_FR.ISO8859-15',
     'fr_lu':                                'fr_LU.ISO8859-1',
-    'fr_lu.88591':                          'fr_LU.ISO8859-1',
-    'fr_lu.iso88591':                       'fr_LU.ISO8859-1',
-    'fr_lu.iso885915':                      'fr_LU.ISO8859-15',
-    'fr_lu.iso885915 at euro':                 'fr_LU.ISO8859-15',
-    'fr_lu.utf8 at euro':                      'fr_LU.UTF-8',
-    'fr_lu at euro':                           'fr_LU.ISO8859-15',
     'fran\xe7ais':                          'fr_FR.ISO8859-1',
     'fre_fr':                               'fr_FR.ISO8859-1',
-    'fre_fr.8859':                          'fr_FR.ISO8859-1',
     'french':                               'fr_FR.ISO8859-1',
     'french.iso88591':                      'fr_CH.ISO8859-1',
     'french_france':                        'fr_FR.ISO8859-1',
-    'french_france.8859':                   'fr_FR.ISO8859-1',
     'ga':                                   'ga_IE.ISO8859-1',
     'ga_ie':                                'ga_IE.ISO8859-1',
-    'ga_ie.iso88591':                       'ga_IE.ISO8859-1',
-    'ga_ie.iso885914':                      'ga_IE.ISO8859-14',
-    'ga_ie.iso885915':                      'ga_IE.ISO8859-15',
-    'ga_ie.iso885915 at euro':                 'ga_IE.ISO8859-15',
-    'ga_ie.utf8 at euro':                      'ga_IE.UTF-8',
-    'ga_ie at euro':                           'ga_IE.ISO8859-15',
     'galego':                               'gl_ES.ISO8859-1',
     'galician':                             'gl_ES.ISO8859-1',
     'gd':                                   'gd_GB.ISO8859-1',
     'gd_gb':                                'gd_GB.ISO8859-1',
-    'gd_gb.iso88591':                       'gd_GB.ISO8859-1',
-    'gd_gb.iso885914':                      'gd_GB.ISO8859-14',
-    'gd_gb.iso885915':                      'gd_GB.ISO8859-15',
-    'gd_gb at euro':                           'gd_GB.ISO8859-15',
     'ger_de':                               'de_DE.ISO8859-1',
-    'ger_de.8859':                          'de_DE.ISO8859-1',
     'german':                               'de_DE.ISO8859-1',
     'german.iso88591':                      'de_CH.ISO8859-1',
     'german_germany':                       'de_DE.ISO8859-1',
-    'german_germany.8859':                  'de_DE.ISO8859-1',
     'gl':                                   'gl_ES.ISO8859-1',
     'gl_es':                                'gl_ES.ISO8859-1',
-    'gl_es.iso88591':                       'gl_ES.ISO8859-1',
-    'gl_es.iso885915':                      'gl_ES.ISO8859-15',
-    'gl_es.iso885915 at euro':                 'gl_ES.ISO8859-15',
-    'gl_es.utf8 at euro':                      'gl_ES.UTF-8',
-    'gl_es at euro':                           'gl_ES.ISO8859-15',
     'greek':                                'el_GR.ISO8859-7',
-    'greek.iso88597':                       'el_GR.ISO8859-7',
     'gu_in':                                'gu_IN.UTF-8',
     'gv':                                   'gv_GB.ISO8859-1',
     'gv_gb':                                'gv_GB.ISO8859-1',
-    'gv_gb.iso88591':                       'gv_GB.ISO8859-1',
-    'gv_gb.iso885914':                      'gv_GB.ISO8859-14',
-    'gv_gb.iso885915':                      'gv_GB.ISO8859-15',
-    'gv_gb at euro':                           'gv_GB.ISO8859-15',
     'he':                                   'he_IL.ISO8859-8',
     'he_il':                                'he_IL.ISO8859-8',
-    'he_il.cp1255':                         'he_IL.CP1255',
-    'he_il.iso88598':                       'he_IL.ISO8859-8',
-    'he_il.microsoftcp1255':                'he_IL.CP1255',
     'hebrew':                               'he_IL.ISO8859-8',
-    'hebrew.iso88598':                      'he_IL.ISO8859-8',
     'hi':                                   'hi_IN.ISCII-DEV',
     'hi_in':                                'hi_IN.ISCII-DEV',
     'hi_in.isciidev':                       'hi_IN.ISCII-DEV',
@@ -1223,23 +1009,17 @@
     'hne_in':                               'hne_IN.UTF-8',
     'hr':                                   'hr_HR.ISO8859-2',
     'hr_hr':                                'hr_HR.ISO8859-2',
-    'hr_hr.iso88592':                       'hr_HR.ISO8859-2',
     'hrvatski':                             'hr_HR.ISO8859-2',
     'hu':                                   'hu_HU.ISO8859-2',
     'hu_hu':                                'hu_HU.ISO8859-2',
-    'hu_hu.iso88592':                       'hu_HU.ISO8859-2',
     'hungarian':                            'hu_HU.ISO8859-2',
     'icelandic':                            'is_IS.ISO8859-1',
-    'icelandic.iso88591':                   'is_IS.ISO8859-1',
     'id':                                   'id_ID.ISO8859-1',
     'id_id':                                'id_ID.ISO8859-1',
     'in':                                   'id_ID.ISO8859-1',
     'in_id':                                'id_ID.ISO8859-1',
     'is':                                   'is_IS.ISO8859-1',
     'is_is':                                'is_IS.ISO8859-1',
-    'is_is.iso88591':                       'is_IS.ISO8859-1',
-    'is_is.iso885915':                      'is_IS.ISO8859-15',
-    'is_is at euro':                           'is_IS.ISO8859-15',
     'iso-8859-1':                           'en_US.ISO8859-1',
     'iso-8859-15':                          'en_US.ISO8859-15',
     'iso8859-1':                            'en_US.ISO8859-1',
@@ -1247,46 +1027,23 @@
     'iso_8859_1':                           'en_US.ISO8859-1',
     'iso_8859_15':                          'en_US.ISO8859-15',
     'it':                                   'it_IT.ISO8859-1',
-    'it.iso885915':                         'it_IT.ISO8859-15',
     'it_ch':                                'it_CH.ISO8859-1',
-    'it_ch.iso88591':                       'it_CH.ISO8859-1',
-    'it_ch.iso885915':                      'it_CH.ISO8859-15',
-    'it_ch at euro':                           'it_CH.ISO8859-15',
     'it_it':                                'it_IT.ISO8859-1',
-    'it_it.88591':                          'it_IT.ISO8859-1',
-    'it_it.iso88591':                       'it_IT.ISO8859-1',
-    'it_it.iso885915':                      'it_IT.ISO8859-15',
-    'it_it.iso885915 at euro':                 'it_IT.ISO8859-15',
-    'it_it.utf8 at euro':                      'it_IT.UTF-8',
-    'it_it at euro':                           'it_IT.ISO8859-15',
     'italian':                              'it_IT.ISO8859-1',
-    'italian.iso88591':                     'it_IT.ISO8859-1',
     'iu':                                   'iu_CA.NUNACOM-8',
     'iu_ca':                                'iu_CA.NUNACOM-8',
     'iu_ca.nunacom8':                       'iu_CA.NUNACOM-8',
     'iw':                                   'he_IL.ISO8859-8',
     'iw_il':                                'he_IL.ISO8859-8',
-    'iw_il.iso88598':                       'he_IL.ISO8859-8',
     'ja':                                   'ja_JP.eucJP',
-    'ja.jis':                               'ja_JP.JIS7',
-    'ja.sjis':                              'ja_JP.SJIS',
     'ja_jp':                                'ja_JP.eucJP',
-    'ja_jp.ajec':                           'ja_JP.eucJP',
     'ja_jp.euc':                            'ja_JP.eucJP',
-    'ja_jp.eucjp':                          'ja_JP.eucJP',
-    'ja_jp.iso-2022-jp':                    'ja_JP.JIS7',
-    'ja_jp.iso2022jp':                      'ja_JP.JIS7',
-    'ja_jp.jis':                            'ja_JP.JIS7',
-    'ja_jp.jis7':                           'ja_JP.JIS7',
     'ja_jp.mscode':                         'ja_JP.SJIS',
     'ja_jp.pck':                            'ja_JP.SJIS',
-    'ja_jp.sjis':                           'ja_JP.SJIS',
-    'ja_jp.ujis':                           'ja_JP.eucJP',
     'japan':                                'ja_JP.eucJP',
     'japanese':                             'ja_JP.eucJP',
     'japanese-euc':                         'ja_JP.eucJP',
     'japanese.euc':                         'ja_JP.eucJP',
-    'japanese.sjis':                        'ja_JP.SJIS',
     'jp_jp':                                'ja_JP.eucJP',
     'ka':                                   'ka_GE.GEORGIAN-ACADEMY',
     'ka_ge':                                'ka_GE.GEORGIAN-ACADEMY',
@@ -1295,27 +1052,18 @@
     'ka_ge.georgianrs':                     'ka_GE.GEORGIAN-ACADEMY',
     'kl':                                   'kl_GL.ISO8859-1',
     'kl_gl':                                'kl_GL.ISO8859-1',
-    'kl_gl.iso88591':                       'kl_GL.ISO8859-1',
-    'kl_gl.iso885915':                      'kl_GL.ISO8859-15',
-    'kl_gl at euro':                           'kl_GL.ISO8859-15',
     'km_kh':                                'km_KH.UTF-8',
     'kn':                                   'kn_IN.UTF-8',
     'kn_in':                                'kn_IN.UTF-8',
     'ko':                                   'ko_KR.eucKR',
     'ko_kr':                                'ko_KR.eucKR',
     'ko_kr.euc':                            'ko_KR.eucKR',
-    'ko_kr.euckr':                          'ko_KR.eucKR',
     'korean':                               'ko_KR.eucKR',
     'korean.euc':                           'ko_KR.eucKR',
     'ks':                                   'ks_IN.UTF-8',
     'ks_in':                                'ks_IN.UTF-8',
-    'ks_in at devanagari':                     'ks_IN.UTF-8 at devanagari',
     'kw':                                   'kw_GB.ISO8859-1',
     'kw_gb':                                'kw_GB.ISO8859-1',
-    'kw_gb.iso88591':                       'kw_GB.ISO8859-1',
-    'kw_gb.iso885914':                      'kw_GB.ISO8859-14',
-    'kw_gb.iso885915':                      'kw_GB.ISO8859-15',
-    'kw_gb at euro':                           'kw_GB.ISO8859-15',
     'ky':                                   'ky_KG.UTF-8',
     'ky_kg':                                'ky_KG.UTF-8',
     'lithuanian':                           'lt_LT.ISO8859-13',
@@ -1326,157 +1074,78 @@
     'lo_la.mulelao1':                       'lo_LA.MULELAO-1',
     'lt':                                   'lt_LT.ISO8859-13',
     'lt_lt':                                'lt_LT.ISO8859-13',
-    'lt_lt.iso885913':                      'lt_LT.ISO8859-13',
-    'lt_lt.iso88594':                       'lt_LT.ISO8859-4',
     'lv':                                   'lv_LV.ISO8859-13',
     'lv_lv':                                'lv_LV.ISO8859-13',
-    'lv_lv.iso885913':                      'lv_LV.ISO8859-13',
-    'lv_lv.iso88594':                       'lv_LV.ISO8859-4',
     'mai':                                  'mai_IN.UTF-8',
     'mai_in':                               'mai_IN.UTF-8',
     'mi':                                   'mi_NZ.ISO8859-1',
     'mi_nz':                                'mi_NZ.ISO8859-1',
-    'mi_nz.iso88591':                       'mi_NZ.ISO8859-1',
     'mk':                                   'mk_MK.ISO8859-5',
     'mk_mk':                                'mk_MK.ISO8859-5',
-    'mk_mk.cp1251':                         'mk_MK.CP1251',
-    'mk_mk.iso88595':                       'mk_MK.ISO8859-5',
-    'mk_mk.microsoftcp1251':                'mk_MK.CP1251',
     'ml':                                   'ml_IN.UTF-8',
     'ml_in':                                'ml_IN.UTF-8',
     'mr':                                   'mr_IN.UTF-8',
     'mr_in':                                'mr_IN.UTF-8',
     'ms':                                   'ms_MY.ISO8859-1',
     'ms_my':                                'ms_MY.ISO8859-1',
-    'ms_my.iso88591':                       'ms_MY.ISO8859-1',
     'mt':                                   'mt_MT.ISO8859-3',
     'mt_mt':                                'mt_MT.ISO8859-3',
-    'mt_mt.iso88593':                       'mt_MT.ISO8859-3',
     'nb':                                   'nb_NO.ISO8859-1',
     'nb_no':                                'nb_NO.ISO8859-1',
-    'nb_no.88591':                          'nb_NO.ISO8859-1',
-    'nb_no.iso88591':                       'nb_NO.ISO8859-1',
-    'nb_no.iso885915':                      'nb_NO.ISO8859-15',
-    'nb_no at euro':                           'nb_NO.ISO8859-15',
     'ne_np':                                'ne_NP.UTF-8',
     'nl':                                   'nl_NL.ISO8859-1',
-    'nl.iso885915':                         'nl_NL.ISO8859-15',
     'nl_be':                                'nl_BE.ISO8859-1',
-    'nl_be.88591':                          'nl_BE.ISO8859-1',
-    'nl_be.iso88591':                       'nl_BE.ISO8859-1',
-    'nl_be.iso885915':                      'nl_BE.ISO8859-15',
-    'nl_be.iso885915 at euro':                 'nl_BE.ISO8859-15',
-    'nl_be.utf8 at euro':                      'nl_BE.UTF-8',
-    'nl_be at euro':                           'nl_BE.ISO8859-15',
     'nl_nl':                                'nl_NL.ISO8859-1',
-    'nl_nl.88591':                          'nl_NL.ISO8859-1',
-    'nl_nl.iso88591':                       'nl_NL.ISO8859-1',
-    'nl_nl.iso885915':                      'nl_NL.ISO8859-15',
-    'nl_nl.iso885915 at euro':                 'nl_NL.ISO8859-15',
-    'nl_nl.utf8 at euro':                      'nl_NL.UTF-8',
-    'nl_nl at euro':                           'nl_NL.ISO8859-15',
     'nn':                                   'nn_NO.ISO8859-1',
     'nn_no':                                'nn_NO.ISO8859-1',
-    'nn_no.88591':                          'nn_NO.ISO8859-1',
-    'nn_no.iso88591':                       'nn_NO.ISO8859-1',
-    'nn_no.iso885915':                      'nn_NO.ISO8859-15',
-    'nn_no at euro':                           'nn_NO.ISO8859-15',
     'no':                                   'no_NO.ISO8859-1',
     'no at nynorsk':                           'ny_NO.ISO8859-1',
     'no_no':                                'no_NO.ISO8859-1',
-    'no_no.88591':                          'no_NO.ISO8859-1',
-    'no_no.iso88591':                       'no_NO.ISO8859-1',
-    'no_no.iso885915':                      'no_NO.ISO8859-15',
     'no_no.iso88591 at bokmal':                'no_NO.ISO8859-1',
     'no_no.iso88591 at nynorsk':               'no_NO.ISO8859-1',
-    'no_no at euro':                           'no_NO.ISO8859-15',
     'norwegian':                            'no_NO.ISO8859-1',
-    'norwegian.iso88591':                   'no_NO.ISO8859-1',
     'nr':                                   'nr_ZA.ISO8859-1',
     'nr_za':                                'nr_ZA.ISO8859-1',
-    'nr_za.iso88591':                       'nr_ZA.ISO8859-1',
     'nso':                                  'nso_ZA.ISO8859-15',
     'nso_za':                               'nso_ZA.ISO8859-15',
-    'nso_za.iso885915':                     'nso_ZA.ISO8859-15',
     'ny':                                   'ny_NO.ISO8859-1',
     'ny_no':                                'ny_NO.ISO8859-1',
-    'ny_no.88591':                          'ny_NO.ISO8859-1',
-    'ny_no.iso88591':                       'ny_NO.ISO8859-1',
-    'ny_no.iso885915':                      'ny_NO.ISO8859-15',
-    'ny_no at euro':                           'ny_NO.ISO8859-15',
     'nynorsk':                              'nn_NO.ISO8859-1',
     'oc':                                   'oc_FR.ISO8859-1',
     'oc_fr':                                'oc_FR.ISO8859-1',
-    'oc_fr.iso88591':                       'oc_FR.ISO8859-1',
-    'oc_fr.iso885915':                      'oc_FR.ISO8859-15',
-    'oc_fr at euro':                           'oc_FR.ISO8859-15',
     'or':                                   'or_IN.UTF-8',
     'or_in':                                'or_IN.UTF-8',
     'pa':                                   'pa_IN.UTF-8',
     'pa_in':                                'pa_IN.UTF-8',
     'pd':                                   'pd_US.ISO8859-1',
     'pd_de':                                'pd_DE.ISO8859-1',
-    'pd_de.iso88591':                       'pd_DE.ISO8859-1',
-    'pd_de.iso885915':                      'pd_DE.ISO8859-15',
-    'pd_de at euro':                           'pd_DE.ISO8859-15',
     'pd_us':                                'pd_US.ISO8859-1',
-    'pd_us.iso88591':                       'pd_US.ISO8859-1',
-    'pd_us.iso885915':                      'pd_US.ISO8859-15',
-    'pd_us at euro':                           'pd_US.ISO8859-15',
     'ph':                                   'ph_PH.ISO8859-1',
     'ph_ph':                                'ph_PH.ISO8859-1',
-    'ph_ph.iso88591':                       'ph_PH.ISO8859-1',
     'pl':                                   'pl_PL.ISO8859-2',
     'pl_pl':                                'pl_PL.ISO8859-2',
-    'pl_pl.iso88592':                       'pl_PL.ISO8859-2',
     'polish':                               'pl_PL.ISO8859-2',
     'portuguese':                           'pt_PT.ISO8859-1',
-    'portuguese.iso88591':                  'pt_PT.ISO8859-1',
     'portuguese_brazil':                    'pt_BR.ISO8859-1',
-    'portuguese_brazil.8859':               'pt_BR.ISO8859-1',
     'posix':                                'C',
     'posix-utf2':                           'C',
     'pp':                                   'pp_AN.ISO8859-1',
     'pp_an':                                'pp_AN.ISO8859-1',
-    'pp_an.iso88591':                       'pp_AN.ISO8859-1',
     'pt':                                   'pt_PT.ISO8859-1',
-    'pt.iso885915':                         'pt_PT.ISO8859-15',
     'pt_br':                                'pt_BR.ISO8859-1',
-    'pt_br.88591':                          'pt_BR.ISO8859-1',
-    'pt_br.iso88591':                       'pt_BR.ISO8859-1',
-    'pt_br.iso885915':                      'pt_BR.ISO8859-15',
-    'pt_br at euro':                           'pt_BR.ISO8859-15',
     'pt_pt':                                'pt_PT.ISO8859-1',
-    'pt_pt.88591':                          'pt_PT.ISO8859-1',
-    'pt_pt.iso88591':                       'pt_PT.ISO8859-1',
-    'pt_pt.iso885915':                      'pt_PT.ISO8859-15',
-    'pt_pt.iso885915 at euro':                 'pt_PT.ISO8859-15',
-    'pt_pt.utf8 at euro':                      'pt_PT.UTF-8',
-    'pt_pt at euro':                           'pt_PT.ISO8859-15',
     'ro':                                   'ro_RO.ISO8859-2',
     'ro_ro':                                'ro_RO.ISO8859-2',
-    'ro_ro.iso88592':                       'ro_RO.ISO8859-2',
     'romanian':                             'ro_RO.ISO8859-2',
     'ru':                                   'ru_RU.UTF-8',
-    'ru.koi8r':                             'ru_RU.KOI8-R',
     'ru_ru':                                'ru_RU.UTF-8',
-    'ru_ru.cp1251':                         'ru_RU.CP1251',
-    'ru_ru.iso88595':                       'ru_RU.ISO8859-5',
-    'ru_ru.koi8r':                          'ru_RU.KOI8-R',
-    'ru_ru.microsoftcp1251':                'ru_RU.CP1251',
     'ru_ua':                                'ru_UA.KOI8-U',
-    'ru_ua.cp1251':                         'ru_UA.CP1251',
-    'ru_ua.koi8u':                          'ru_UA.KOI8-U',
-    'ru_ua.microsoftcp1251':                'ru_UA.CP1251',
     'rumanian':                             'ro_RO.ISO8859-2',
     'russian':                              'ru_RU.ISO8859-5',
     'rw':                                   'rw_RW.ISO8859-1',
     'rw_rw':                                'rw_RW.ISO8859-1',
-    'rw_rw.iso88591':                       'rw_RW.ISO8859-1',
     'sd':                                   'sd_IN.UTF-8',
-    'sd at devanagari':                        'sd_IN.UTF-8 at devanagari',
     'sd_in':                                'sd_IN.UTF-8',
-    'sd_in at devanagari':                     'sd_IN.UTF-8 at devanagari',
     'se_no':                                'se_NO.UTF-8',
     'serbocroatian':                        'sr_RS.UTF-8 at latin',
     'sh':                                   'sr_RS.UTF-8 at latin',
@@ -1490,37 +1159,26 @@
     'sinhala':                              'si_LK.UTF-8',
     'sk':                                   'sk_SK.ISO8859-2',
     'sk_sk':                                'sk_SK.ISO8859-2',
-    'sk_sk.iso88592':                       'sk_SK.ISO8859-2',
     'sl':                                   'sl_SI.ISO8859-2',
     'sl_cs':                                'sl_CS.ISO8859-2',
     'sl_si':                                'sl_SI.ISO8859-2',
-    'sl_si.iso88592':                       'sl_SI.ISO8859-2',
     'slovak':                               'sk_SK.ISO8859-2',
     'slovene':                              'sl_SI.ISO8859-2',
     'slovenian':                            'sl_SI.ISO8859-2',
     'sp':                                   'sr_CS.ISO8859-5',
     'sp_yu':                                'sr_CS.ISO8859-5',
     'spanish':                              'es_ES.ISO8859-1',
-    'spanish.iso88591':                     'es_ES.ISO8859-1',
     'spanish_spain':                        'es_ES.ISO8859-1',
-    'spanish_spain.8859':                   'es_ES.ISO8859-1',
     'sq':                                   'sq_AL.ISO8859-2',
     'sq_al':                                'sq_AL.ISO8859-2',
-    'sq_al.iso88592':                       'sq_AL.ISO8859-2',
     'sr':                                   'sr_RS.UTF-8',
     'sr at cyrillic':                          'sr_RS.UTF-8',
-    'sr at latin':                             'sr_RS.UTF-8 at latin',
     'sr at latn':                              'sr_CS.UTF-8 at latin',
     'sr_cs':                                'sr_CS.UTF-8',
-    'sr_cs.iso88592':                       'sr_CS.ISO8859-2',
     'sr_cs.iso88592 at latn':                  'sr_CS.ISO8859-2',
-    'sr_cs.iso88595':                       'sr_CS.ISO8859-5',
-    'sr_cs.utf8 at latn':                      'sr_CS.UTF-8 at latin',
     'sr_cs at latn':                           'sr_CS.UTF-8 at latin',
     'sr_me':                                'sr_ME.UTF-8',
     'sr_rs':                                'sr_RS.UTF-8',
-    'sr_rs.utf8 at latn':                      'sr_RS.UTF-8 at latin',
-    'sr_rs at latin':                          'sr_RS.UTF-8 at latin',
     'sr_rs at latn':                           'sr_RS.UTF-8 at latin',
     'sr_sp':                                'sr_CS.ISO8859-2',
     'sr_yu':                                'sr_RS.UTF-8 at latin',
@@ -1529,29 +1187,15 @@
     'sr_yu.iso88595':                       'sr_CS.ISO8859-5',
     'sr_yu.iso88595 at cyrillic':              'sr_CS.ISO8859-5',
     'sr_yu.microsoftcp1251 at cyrillic':       'sr_CS.CP1251',
-    'sr_yu.utf8 at cyrillic':                  'sr_RS.UTF-8',
     'sr_yu at cyrillic':                       'sr_RS.UTF-8',
     'ss':                                   'ss_ZA.ISO8859-1',
     'ss_za':                                'ss_ZA.ISO8859-1',
-    'ss_za.iso88591':                       'ss_ZA.ISO8859-1',
     'st':                                   'st_ZA.ISO8859-1',
     'st_za':                                'st_ZA.ISO8859-1',
-    'st_za.iso88591':                       'st_ZA.ISO8859-1',
     'sv':                                   'sv_SE.ISO8859-1',
-    'sv.iso885915':                         'sv_SE.ISO8859-15',
     'sv_fi':                                'sv_FI.ISO8859-1',
-    'sv_fi.iso88591':                       'sv_FI.ISO8859-1',
-    'sv_fi.iso885915':                      'sv_FI.ISO8859-15',
-    'sv_fi.iso885915 at euro':                 'sv_FI.ISO8859-15',
-    'sv_fi.utf8 at euro':                      'sv_FI.UTF-8',
-    'sv_fi at euro':                           'sv_FI.ISO8859-15',
     'sv_se':                                'sv_SE.ISO8859-1',
-    'sv_se.88591':                          'sv_SE.ISO8859-1',
-    'sv_se.iso88591':                       'sv_SE.ISO8859-1',
-    'sv_se.iso885915':                      'sv_SE.ISO8859-15',
-    'sv_se at euro':                           'sv_SE.ISO8859-15',
     'swedish':                              'sv_SE.ISO8859-1',
-    'swedish.iso88591':                     'sv_SE.ISO8859-1',
     'ta':                                   'ta_IN.TSCII-0',
     'ta_in':                                'ta_IN.TSCII-0',
     'ta_in.tscii':                          'ta_IN.TSCII-0',
@@ -1559,49 +1203,33 @@
     'te':                                   'te_IN.UTF-8',
     'tg':                                   'tg_TJ.KOI8-C',
     'tg_tj':                                'tg_TJ.KOI8-C',
-    'tg_tj.koi8c':                          'tg_TJ.KOI8-C',
     'th':                                   'th_TH.ISO8859-11',
     'th_th':                                'th_TH.ISO8859-11',
-    'th_th.iso885911':                      'th_TH.ISO8859-11',
     'th_th.tactis':                         'th_TH.TIS620',
     'th_th.tis620':                         'th_TH.TIS620',
     'thai':                                 'th_TH.ISO8859-11',
     'tl':                                   'tl_PH.ISO8859-1',
     'tl_ph':                                'tl_PH.ISO8859-1',
-    'tl_ph.iso88591':                       'tl_PH.ISO8859-1',
     'tn':                                   'tn_ZA.ISO8859-15',
     'tn_za':                                'tn_ZA.ISO8859-15',
-    'tn_za.iso885915':                      'tn_ZA.ISO8859-15',
     'tr':                                   'tr_TR.ISO8859-9',
     'tr_tr':                                'tr_TR.ISO8859-9',
-    'tr_tr.iso88599':                       'tr_TR.ISO8859-9',
     'ts':                                   'ts_ZA.ISO8859-1',
     'ts_za':                                'ts_ZA.ISO8859-1',
-    'ts_za.iso88591':                       'ts_ZA.ISO8859-1',
     'tt':                                   'tt_RU.TATAR-CYR',
     'tt_ru':                                'tt_RU.TATAR-CYR',
-    'tt_ru.koi8c':                          'tt_RU.KOI8-C',
     'tt_ru.tatarcyr':                       'tt_RU.TATAR-CYR',
     'turkish':                              'tr_TR.ISO8859-9',
-    'turkish.iso88599':                     'tr_TR.ISO8859-9',
     'uk':                                   'uk_UA.KOI8-U',
     'uk_ua':                                'uk_UA.KOI8-U',
-    'uk_ua.cp1251':                         'uk_UA.CP1251',
-    'uk_ua.iso88595':                       'uk_UA.ISO8859-5',
-    'uk_ua.koi8u':                          'uk_UA.KOI8-U',
-    'uk_ua.microsoftcp1251':                'uk_UA.CP1251',
     'univ':                                 'en_US.utf',
     'universal':                            'en_US.utf',
     'universal.utf8 at ucs4':                  'en_US.UTF-8',
     'ur':                                   'ur_PK.CP1256',
     'ur_in':                                'ur_IN.UTF-8',
     'ur_pk':                                'ur_PK.CP1256',
-    'ur_pk.cp1256':                         'ur_PK.CP1256',
-    'ur_pk.microsoftcp1256':                'ur_PK.CP1256',
     'uz':                                   'uz_UZ.UTF-8',
     'uz_uz':                                'uz_UZ.UTF-8',
-    'uz_uz.iso88591':                       'uz_UZ.ISO8859-1',
-    'uz_uz.utf8 at cyrillic':                  'uz_UZ.UTF-8',
     'uz_uz at cyrillic':                       'uz_UZ.UTF-8',
     've':                                   've_ZA.UTF-8',
     've_za':                                've_ZA.UTF-8',
@@ -1613,35 +1241,21 @@
     'vi_vn.viscii111':                      'vi_VN.VISCII',
     'wa':                                   'wa_BE.ISO8859-1',
     'wa_be':                                'wa_BE.ISO8859-1',
-    'wa_be.iso88591':                       'wa_BE.ISO8859-1',
-    'wa_be.iso885915':                      'wa_BE.ISO8859-15',
-    'wa_be.iso885915 at euro':                 'wa_BE.ISO8859-15',
-    'wa_be at euro':                           'wa_BE.ISO8859-15',
     'xh':                                   'xh_ZA.ISO8859-1',
     'xh_za':                                'xh_ZA.ISO8859-1',
-    'xh_za.iso88591':                       'xh_ZA.ISO8859-1',
     'yi':                                   'yi_US.CP1255',
     'yi_us':                                'yi_US.CP1255',
-    'yi_us.cp1255':                         'yi_US.CP1255',
-    'yi_us.microsoftcp1255':                'yi_US.CP1255',
     'zh':                                   'zh_CN.eucCN',
     'zh_cn':                                'zh_CN.gb2312',
     'zh_cn.big5':                           'zh_TW.big5',
     'zh_cn.euc':                            'zh_CN.eucCN',
-    'zh_cn.gb18030':                        'zh_CN.gb18030',
-    'zh_cn.gb2312':                         'zh_CN.gb2312',
-    'zh_cn.gbk':                            'zh_CN.gbk',
     'zh_hk':                                'zh_HK.big5hkscs',
-    'zh_hk.big5':                           'zh_HK.big5',
     'zh_hk.big5hk':                         'zh_HK.big5hkscs',
-    'zh_hk.big5hkscs':                      'zh_HK.big5hkscs',
     'zh_tw':                                'zh_TW.big5',
-    'zh_tw.big5':                           'zh_TW.big5',
     'zh_tw.euc':                            'zh_TW.eucTW',
     'zh_tw.euctw':                          'zh_TW.eucTW',
     'zu':                                   'zu_ZA.ISO8859-1',
     'zu_za':                                'zu_ZA.ISO8859-1',
-    'zu_za.iso88591':                       'zu_ZA.ISO8859-1',
 }
 
 #
diff -r fff3f28733b4 Lib/test/test_locale.py
--- a/Lib/test/test_locale.py	Thu Dec 26 21:21:52 2013 +0200
+++ b/Lib/test/test_locale.py	Fri Dec 27 00:18:30 2013 +0200
@@ -384,6 +384,7 @@
     def test_english(self):
         self.check('en', 'en_US.ISO8859-1')
         self.check('EN', 'en_US.ISO8859-1')
+        self.check('en.iso88591', 'en_US.ISO8859-1')
         self.check('en_US', 'en_US.ISO8859-1')
         self.check('en_us', 'en_US.ISO8859-1')
         self.check('en_GB', 'en_GB.ISO8859-1')
@@ -392,7 +393,10 @@
         self.check('en_US:UTF-8', 'en_US.UTF-8')
         self.check('en_US.ISO8859-1', 'en_US.ISO8859-1')
         self.check('en_US.US-ASCII', 'en_US.ISO8859-1')
+        self.check('en_US.88591', 'en_US.ISO8859-1')
+        self.check('en_US.885915', 'en_US.ISO8859-15')
         self.check('english', 'en_EN.ISO8859-1')
+        self.check('english_uk.ascii', 'en_GB.ISO8859-1')
 
     def test_hyphenated_encoding(self):
         self.check('az_AZ.iso88599e', 'az_AZ.ISO8859-9E')
@@ -412,10 +416,12 @@
     def test_euro_modifier(self):
         self.check('de_DE at euro', 'de_DE.ISO8859-15')
         self.check('en_US.ISO8859-15 at euro', 'en_US.ISO8859-15')
+        self.check('de_DE.utf8 at euro', 'de_DE.UTF-8')
 
     def test_latin_modifier(self):
         self.check('be_BY.UTF-8 at latin', 'be_BY.UTF-8 at latin')
         self.check('sr_RS.UTF-8 at latin', 'sr_RS.UTF-8 at latin')
+        self.check('sr_RS.UTF-8 at latn', 'sr_RS.UTF-8 at latin')
 
     def test_valencia_modifier(self):
         self.check('ca_ES.UTF-8 at valencia', 'ca_ES.UTF-8 at valencia')
@@ -436,6 +442,39 @@
         self.check('sd_IN', 'sd_IN.UTF-8')
         self.check('sd', 'sd_IN.UTF-8')
 
+    def test_euc_encoding(self):
+        self.check('ja_jp.euc', 'ja_JP.eucJP')
+        self.check('ja_jp.eucjp', 'ja_JP.eucJP')
+        self.check('ko_kr.euc', 'ko_KR.eucKR')
+        self.check('ko_kr.euckr', 'ko_KR.eucKR')
+        self.check('zh_cn.euc', 'zh_CN.eucCN')
+        self.check('zh_tw.euc', 'zh_TW.eucTW')
+        self.check('zh_tw.euctw', 'zh_TW.eucTW')
+
+    def test_japanese(self):
+        self.check('ja', 'ja_JP.eucJP')
+        self.check('ja.jis', 'ja_JP.JIS7')
+        self.check('ja.sjis', 'ja_JP.SJIS')
+        self.check('ja_jp', 'ja_JP.eucJP')
+        self.check('ja_jp.ajec', 'ja_JP.eucJP')
+        self.check('ja_jp.euc', 'ja_JP.eucJP')
+        self.check('ja_jp.eucjp', 'ja_JP.eucJP')
+        self.check('ja_jp.iso-2022-jp', 'ja_JP.JIS7')
+        self.check('ja_jp.iso2022jp', 'ja_JP.JIS7')
+        self.check('ja_jp.jis', 'ja_JP.JIS7')
+        self.check('ja_jp.jis7', 'ja_JP.JIS7')
+        self.check('ja_jp.mscode', 'ja_JP.SJIS')
+        self.check('ja_jp.pck', 'ja_JP.SJIS')
+        self.check('ja_jp.sjis', 'ja_JP.SJIS')
+        self.check('ja_jp.ujis', 'ja_JP.eucJP')
+        self.check('ja_jp.utf8', 'ja_JP.UTF-8')
+        self.check('japan', 'ja_JP.eucJP')
+        self.check('japanese', 'ja_JP.eucJP')
+        self.check('japanese-euc', 'ja_JP.eucJP')
+        self.check('japanese.euc', 'ja_JP.eucJP')
+        self.check('japanese.sjis', 'ja_JP.SJIS')
+        self.check('jp_jp', 'ja_JP.eucJP')
+
 
 class TestMiscellaneous(unittest.TestCase):
     def test_getpreferredencoding(self):
diff -r fff3f28733b4 Tools/i18n/makelocalealias.py
--- a/Tools/i18n/makelocalealias.py	Thu Dec 26 21:21:52 2013 +0200
+++ b/Tools/i18n/makelocalealias.py	Fri Dec 27 00:18:30 2013 +0200
@@ -7,6 +7,7 @@
 
 """
 import locale
+import sys
 
 # Location of the alias file
 LOCALE_ALIAS = '/usr/share/X11/locale/locale.alias'
@@ -65,9 +66,35 @@
                   (k, olddata[k], data[k]))
         # Additions are not mentioned
 
+def optimize(data):
+    locale_alias = locale.locale_alias
+    locale.locale_alias = data.copy()
+    for k, v in data.items():
+        del locale.locale_alias[k]
+        if locale.normalize(k) != v:
+            locale.locale_alias[k] = v
+    newdata = locale.locale_alias
+    errors = check(data)
+    locale.locale_alias = locale_alias
+    if errors:
+        sys.exit(1)
+    return newdata
+
+def check(data):
+    # Check that all alias definitions from the X11 file
+    # are actually mapped to the correct alias locales.
+    errors = 0
+    for k, v in data.items():
+        if locale.normalize(k) != v:
+            print('ERROR: %a -> %a != %a' % (k, locale.normalize(k), v),
+                  file=sys.stderr)
+            errors += 1
+    return errors
+
 if __name__ == '__main__':
     data = locale.locale_alias.copy()
     data.update(parse(LOCALE_ALIAS))
+    data = optimize(data)
     print_differences(data, locale.locale_alias)
     print()
     print('locale_alias = {')

From report at bugs.python.org  Tue Dec 31 00:35:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Dec 2013 23:35:17 +0000
Subject: [issue20098] email policy needs a mangle_from setting
Message-ID: <1388446517.27.0.863185292033.issue20098@psf.upfronthosting.co.za>


New submission from R. David Murray:

I missed this.  It still defaults to True in Generator.  It should default to False in the new policies (but True in compat32).

----------
components: email
keywords: easy
messages: 207116
nosy: barry, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email policy needs a mangle_from setting
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20098>
_______________________________________

From report at bugs.python.org  Tue Dec 31 02:13:51 2013
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 31 Dec 2013 01:13:51 +0000
Subject: [issue19995] %c, %o, %x,
 %X accept non-integer values instead of raising an exception
In-Reply-To: <1387189744.09.0.921617360417.issue19995@psf.upfronthosting.co.za>
Message-ID: <1388452431.97.0.28162424768.issue19995@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I wouldn't call this a new feature--it's definitely a bug fix.  So the "feature freeze" rule does not automatically apply.  I definitely wouldn't permit this once we reach release candidates, but we aren't there yet.

I get the impression that it will break code, and it does seem kind of late.  So I'm not saying yes or no yet.  Let me think about it some more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19995>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:18:51 2013
From: report at bugs.python.org (Liam Marsh)
Date: Tue, 31 Dec 2013 15:18:51 +0000
Subject: [issue20099] a new idea
Message-ID: <1388503131.58.0.100306022546.issue20099@psf.upfronthosting.co.za>


New submission from Liam Marsh:

idea:
var():
input var name (str),
outputs var value
useful for(example in a chess program):

>>>count=1
>>>while count<=8:
...    var('a', count)='black queen'
...    count=count+1

----------
messages: 207118
nosy: Liam.Marsh
priority: normal
severity: normal
status: open
title: a new idea
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20099>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:30:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 31 Dec 2013 15:30:49 +0000
Subject: [issue20099] a new idea
In-Reply-To: <1388503131.58.0.100306022546.issue20099@psf.upfronthosting.co.za>
Message-ID: <1388503849.15.0.748748574819.issue20099@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

You should propose this to the python-ideas mailing list, but from your description is not clear to me what you want.
Can you try to explain it more in detail?
Are you asking for a new function that accepts the name of a variable as a string and prints its value?  Or for a function that creates dynamically a new "variable name"?

If you want to dynamically create variable names, it's better to just use a dictionary instead, e.g.:
d = {}
for count in range(1, 9):
    name = 'a' + str(count)
    d[name] = 'black queen'

----------
nosy: +ezio.melotti
status: open -> pending
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20099>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:42:59 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 31 Dec 2013 15:42:59 +0000
Subject: [issue20095] what is that result!?
In-Reply-To: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>
Message-ID: <1388504579.84.0.539266359597.issue20095@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> can you add an approximation of the result in the command?

I don't really understand what you're asking here.

If you're asking for the behaviour of multiplication to change so that it becomes more do-what-I-mean-ish, that's not going to happen.  You could try writing your own DWIM-style multiplication if that's what you want, but the basic multiplication operator should stay as it is now: a simple wrapper around the C multiplication, which on most machines has a simple, easily-stated and well-defined behaviour: return me the floating-point number that's closest to the exact mathematical result of the multiplication.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20095>
_______________________________________

From report at bugs.python.org  Tue Dec 31 16:58:14 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 Dec 2013 15:58:14 +0000
Subject: [issue20100] epoll docs are not clear with regards to CLOEXEC.
Message-ID: <1388505494.08.0.643576998185.issue20100@psf.upfronthosting.co.za>


New submission from R. David Murray:

http://docs.python.org/dev/library/select.html#select.epoll documents the EPOLL_CLOEXEC flag as something you can specify that makes the file descriptor be closed on exec.  But then it goes on to say that the file descriptor is non-inheritable.  So is the flag useless and should be removed from the docs, or is the documentation just unclear as to its purpose?  Or, conversely, do we need a way to say that the file descriptor should *not* be closed on exec?

----------
assignee: docs at python
components: Documentation
messages: 207121
nosy: docs at python, haypo, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: epoll docs are not clear with regards to CLOEXEC.
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20100>
_______________________________________

From report at bugs.python.org  Tue Dec 31 17:01:28 2013
From: report at bugs.python.org (Tim Peters)
Date: Tue, 31 Dec 2013 16:01:28 +0000
Subject: [issue20095] what is that result!?
In-Reply-To: <1388398702.19.0.462802956175.issue20095@psf.upfronthosting.co.za>
Message-ID: <1388505688.12.0.773642738732.issue20095@psf.upfronthosting.co.za>


Tim Peters added the comment:

@Liam, try using the "decimal" module instead.  That follows rules much like the ones people learn as kids.

>>> from decimal import Decimal as D
>>> D("0.1") * 3  # decimal results are computed exactly
Decimal('0.3')
>>> D("1.01") - D(".01")  # number of significant digits is preserved
Decimal('1.00')

Etc.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20095>
_______________________________________

From report at bugs.python.org  Tue Dec 31 17:03:11 2013
From: report at bugs.python.org (Liam Marsh)
Date: Tue, 31 Dec 2013 16:03:11 +0000
Subject: [issue20099] a new idea
In-Reply-To: <1388503131.58.0.100306022546.issue20099@psf.upfronthosting.co.za>
Message-ID: <1388505791.23.0.177519819067.issue20099@psf.upfronthosting.co.za>


Liam Marsh added the comment:

first, it was for the second idea, which can be replaced,
but maybe sameone needs it,
when you reed theese lines, this idea is sent.
meen while,
have a happy new year.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20099>
_______________________________________

From report at bugs.python.org  Tue Dec 31 17:20:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Dec 2013 16:20:00 +0000
Subject: [issue20100] epoll docs are not clear with regards to CLOEXEC.
In-Reply-To: <1388505494.08.0.643576998185.issue20100@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ1O1uUuXWEpZhxZuePBDuz-Cez-ZNPxKjGL-3nk_yU7w@mail.gmail.com>


STINNER Victor added the comment:

Use os.set_inheritable(epoll.fileno(), True) to make the file descriptor
inheritable. You should find this info easily if you follow the link on
"non inheritable" in epoll documentation.

EPOLL_CLOEXEC becomes useless in Python 3.4. It is used internally by
default if available. Removing it would break existing code, it would be
harder to write code for python 3.4 and 3.3.

Just update the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20100>
_______________________________________

From report at bugs.python.org  Tue Dec 31 22:42:32 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 Dec 2013 21:42:32 +0000
Subject: [issue20101] Determine correct behavior for time functions on Windows
Message-ID: <1388526152.52.0.960629914987.issue20101@psf.upfronthosting.co.za>


New submission from Zachary Ware:

For previous discussion, see issue19999.

To summarize, time on Windows is far from straight-forward, and currently for

"""
t1 = time.monotonic()
time.sleep(0.5)
t2 = time.monotonic()
dt = t2-t1
"""

dt may end up as very slightly smaller than 0.5 (0.4990000003017485 or so), 0.5, or somewhat larger than 0.5 (0.5150000001303852 or so); or 0.5 almost all of the time, depending on the machine in question.  So far, two very different Win7 machines of mine both produced the first result, and Tim Peters' Vista machine produced the second.  Both of mine report the resolution as 0.015600099999999999, Tim's reports 0.015625.

See also http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly and http://www.windowstimestamp.com/description for more related reading.

Due to the issue, test_monotonic regularly fails for me.  A simple workaround is to relax the lower bound of 0.5 <= dt <= 1.0 to 0.45; I intend to commit that workaround soon, but it won't close this issue.

In preparation for creating this issue I also checked the other time functions (time, clock, and perf_counter) for the same issue, and on my test machine all of them have it (although it is apparently intermittent for time (earlier I got straight failures, now it won't fail), and clock and perf_counter are implemented by the same underlying function).

Here is some output from my machine, formatted slightly for nicer presentation:

3.4.0b1 (default:fd846837492d+, Dec 30 2013, 11:01:01) [MSC v.1600 32 bit (Intel)]
Windows-7-6.1.7601-SP1
Running:
"""
import time
import sys
import platform
print(sys.version)
print(platform.platform())

with open(__file__) as file:
    print('Running:\n"""')
    print(file.read())
    print('"""')

clock_info = {}

for time_func in (time.monotonic, time.time, time.clock, time.perf_counter):
    name = time_func.__name__
    info = str(time.get_clock_info(name))
    print(name, info)
    if info in clock_info:
        print('Same clock as time.{}'.format(clock_info[info]))
        continue
    else:
        clock_info[info] = name
    good = 0
    values = {}
    count = 0
    try:
        while count < 25:
            # basic test copied from test_monotonic, extras bolted on
            t1 = time_func()
            time.sleep(0.5)
            t2 = time_func()
            dt = t2 - t1
            if values.get(dt):
                values[dt] += 1
            else:
                values[dt] = 1
            assert t2 > t1
            passed = 0.5 <= dt <= 1.0
            print('.' if passed else 'F', end='', flush=True)
            if passed:
                good += 1
            count += 1
    except KeyboardInterrupt:
        pass

    print()
    print('total:', count,
          'good:', good,
          'bad:', count - good)
    print(sorted(values.items()))
    print()

"""
monotonic namespace(adjustable=False, implementation='GetTickCount64()', monotonic=True, resolution=0.015600099999999999)
FF.FFFF.FFF.FF.FFF.FFFF.F
total: 25 good: 6 bad: 19
[(0.4989999998360872, 13), (0.4990000003017485, 6), (0.5, 5), (0.5150000001303852, 1)]

time namespace(adjustable=True, implementation='GetSystemTimeAsFileTime()', monotonic=False, resolution=0.015600099999999999)
.........................
total: 25 good: 25 bad: 0
[(0.5, 25)]

clock namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=2.851518034140655e-07)
.FFFFFFFFFFFFFFFFFF.FFFFF
total: 25 good: 2 bad: 23
[(0.49929681565278194, 1), (0.49941258728496685, 1), (0.4995377689266647,  1),
(0.4995543077312634,   1), (0.49955459288306736, 1), (0.4995597256155282,  1),
(0.4995602959191352,   1), (0.4995659989552035,  1), (0.4995679950178271,  1),
(0.49956970592864813,  1), (0.4995748386611094,  1), (0.499581967456195,   1),
(0.4995956547427589,   1), (0.49961304900276726, 1), (0.49961761143162153, 1),
(0.49961846688703204,  1), (0.49962445507490294, 1), (0.499629017503759,   1),
(0.4996355759952369,   1), (0.4996401384240914,  1), (0.49964042357589467, 1),
(0.4996486929781927,   1), (0.4996555366214759,  1), (0.5000139724383673,  1),
(0.5036356854935278,   1)]

perf_counter namespace(adjustable=False, implementation='QueryPerformanceCounter()', monotonic=True, resolution=2.851518034140655e-07)
Same clock as time.clock


And here's results from time.time earlier today (produced by an earlier version of the above script, same machine and interpreter):

time
FFFFFFFFFFFFFFFFFFFFFF.FF
total: 25 good: 1 bad: 24
[(0.49969983100891113, 7), (0.49970006942749023, 17), (0.5006990432739258, 1)]

----------
components: Extension Modules, Windows
messages: 207125
nosy: haypo, tim.peters, zach.ware
priority: normal
severity: normal
status: open
title: Determine correct behavior for time functions on Windows
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20101>
_______________________________________

From report at bugs.python.org  Tue Dec 31 23:03:12 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Dec 2013 22:03:12 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1388527392.9.0.204835693853.issue3982@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/issue3982>
_______________________________________

From report at bugs.python.org  Tue Dec 31 23:03:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Dec 2013 22:03:22 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1388527402.83.0.988242532888.issue3982@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Tue Dec 31 23:09:03 2013
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Dec 2013 22:09:03 +0000
Subject: [issue20096] Mention modernize and future in Python 2/3 porting HOWTO
In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>
Message-ID: <1388527743.38.0.24237005433.issue20096@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/issue20096>
_______________________________________

From report at bugs.python.org  Tue Dec 31 23:19:09 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 31 Dec 2013 22:19:09 +0000
Subject: [issue20065] Python-3.3.3/Modules/socketmodule.c:1660:14: error:
 'CAN_RAW' undeclared (first use in this function)
In-Reply-To: <1387961196.27.0.560814998744.issue20065@psf.upfronthosting.co.za>
Message-ID: <1388528349.3.0.390550501828.issue20065@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Revision e767318baccd introduced usage of CAN_RAW.

----------
keywords: +3.3regression
nosy: +Arfrever, neologix, pitrou
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20065>
_______________________________________