Mailman 3 April 2013 - Python-Dev

Re: [Python-Dev] cpython (3.3): don't run frame if it has no stack (closes #17669)
by Antoine Pitrou April 11, 2013

April 11, 2013

On Wed, 10 Apr 2013 23:01:46 +0200 (CEST) benjamin.peterson <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/35cb75b9d653 > changeset: 83238:35cb75b9d653 > branch: 3.3 > parent: 83235:172f825d7fc9 > user: Benjamin Peterson <benjamin(a)python.org> > date: Wed Apr 10 17:00:56 2013 -0400 > summary: > don't run frame if it has no stack (closes #17669) Wouldn't it be better with a test? Regards Antoine. > > files: > Misc/NEWS | 2 ++ > Objects/genobject.c | 2 +- > 2 files changed, 3 insertions(+), 1 deletions(-) > > > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -12,6 +12,8 @@ > Core and Builtins > ----------------- > > +- Issue #17669: Fix crash involving finalization of generators using yield from. > + > - Issue #17619: Make input() check for Ctrl-C correctly on Windows. > > - Issue #17610: Don't rely on non-standard behavior of the C qsort() function. > diff --git a/Objects/genobject.c b/Objects/genobject.c > --- a/Objects/genobject.c > +++ b/Objects/genobject.c > @@ -178,7 +178,7 @@ > PyObject *yf = NULL; > PyFrameObject *f = gen->gi_frame; > > - if (f) { > + if (f && f->f_stacktop) { > PyObject *bytecode = f->f_code->co_code; > unsigned char *code = (unsigned char *)PyBytes_AS_STRING(bytecode); > >

4 4

How to fix the incorrect shared library extension on linux for 3.2 and newer?
by Matthias Klose April 10, 2013

April 10, 2013

This is http://bugs.python.org/issue16754, affecting Linux systems only, and only those which don't provide static libraries. PEP 3149 did change the SO macro to include the ABI tag, although the SO macro is used to search for shared system libraries too. E.g. searching for the jpeg library search for a file libjpeg.cpython3.3m.so, which is not found. If the static library libjpeg.a is found, it is taken, and linked as -ljpeg, which then links with the shared library. The patch in the issue now makes a distinction between EXT_SUFFIX and SHLIB_SUFFIX, and restores the value of SO to SHLIB_SUFFIX. Now this could break users of sysconfig.get_config_var('SO'), however I don't see a better way than to restore the original behaviour and advise people to use the new config variables. Matthias

6 5

Re: [Python-Dev] [Python-checkins] cpython (3.3): Process DEFAULT values in mock side_effect that returns iterator.
by Michael Foord April 9, 2013

April 9, 2013

On 7 April 2013 14:44, andrew.svetlov <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/18fd64f1de2d > changeset: 83179:18fd64f1de2d > branch: 3.3 > user: Andrew Svetlov <andrew.svetlov(a)gmail.com> > date: Sun Apr 07 16:42:24 2013 +0300 > summary: > Process DEFAULT values in mock side_effect that returns iterator. > > Patch by Michael Ford. > > files: > Lib/unittest/mock.py | 2 ++ > Lib/unittest/test/testmock/testmock.py | 4 ++++ > 2 files changed, 6 insertions(+), 0 deletions(-) > > > diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py > --- a/Lib/unittest/mock.py > +++ b/Lib/unittest/mock.py > @@ -904,6 +904,8 @@ > result = next(effect) > if _is_exception(result): > raise result > + if result is DEFAULT: > + result = self.return_value > return result > > ret_val = effect(*args, **kwargs) > diff --git a/Lib/unittest/test/testmock/testmock.py > b/Lib/unittest/test/testmock/testmock.py > --- a/Lib/unittest/test/testmock/testmock.py > +++ b/Lib/unittest/test/testmock/testmock.py > @@ -906,6 +906,10 @@ > self.assertRaises(StopIteration, mock) > self.assertIs(mock.side_effect, this_iter) > > + def test_side_effect_iterator_default(self): > + mock = Mock(return_value=2) > + mock.side_effect = iter([1, DEFAULT]) > + self.assertEqual([mock(), mock()], [1, 2]) > > def test_assert_has_calls_any_order(self): > mock = Mock() > > -- > Repository URL: http://hg.python.org/cpython > > This was committed without a NEWS entry. Michael > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins > > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

3 2

Accelerating extension module compilation [distutils]
by Alex Leach April 9, 2013

April 9, 2013

Hi, Apologies if this is the wrong place to ask, but thought this question would be relevant to Python core and extension module devs.. This the right place? I've been using distutils to compile C++ extensions / bindings written with Boost.Python, and have been implementing some (often frowned-upon) monkey-patching magic to speed up the compilation process. I was wondering if other Python devs would appreciate the benefit from a distutils-integrated patch of the same functionality, using less-frowned upon programming techniques. More specifically, I have felt it useful during development to incorporate the following functionality into a setupext.py file:- 1. Parallel compilation, by monkey-patching distutils.ccompiler.CCompiler.compile. (A basic solution was provided on StackOverflow[1].) 2. Create a "unity-build"[2]. 3. Only re-compile objects whose source-code / included files have changed. I'll happily share my code (hacks), but before getting too technical with the discussion, I was just wondering whether any of these would be considered useful enough / easy enough to implement without breaking backwards-compatibility, to incorporate into core distutils. Any thoughts? Thanks for your time. Kind regards, Alex [1] - http://stackoverflow.com/questions/11013851/speeding-up-build-process-with-… [2] - http://stackoverflow.com/questions/543697/include-all-cpp-files-into-a-sing… -- Using Opera's mail client: http://www.opera.com/mail/

1 0

Python accepted as a GSoC 2013 mentoring organization!
by Terri Oda April 8, 2013

April 8, 2013

Congratulations all; we've been accepted as a mentoring organization for Google Summer of Code 2013! Students can check out our ideas page here: http://wiki.python.org/moin/SummerOfCode/2013 If you're interested in mentoring with the PSF and aren't already on the 2013 mentors mailing list, please get in touch with me ASAP. Terri

1 0

Fwd: SourceForge Project Upgrade Notification
by Skip Montanaro April 8, 2013

April 8, 2013

Obviously SourceForge doesn't think the current release interval is short enough. (Emphasis mine.) :-) Skip ---------- Forwarded message ---------- From: SourceForge.net <noreply+project-upgrade(a)in.sf.net> Date: Mon, Apr 8, 2013 at 1:09 PM Subject: SourceForge Project Upgrade Notification To: noreply(a)in.sf.net Dear SourceForge Project Developer, We wanted to let you know that we've upgraded your project, Python, to the new SourceForge developer platform. The next time you log in, things will look a little different. *We've noticed that your project has been idle for a while. This would be a great time to come back and push out a * *new version.* Visit your project at http://sourceforge.net/projects/python/ The new platform, codenamed "Allura", is a rewrite and redesign of the Open Source development tool set. It provides tighter integration between the various tools to give you a better developer experience. Allura is a project in incubation at the Apache Software Foundation, where people from many different companies are collaborating to make it even better. You can see a quick overview of the platform at http://sourceforge.net/create/#feature-holder and you can see ongoing updates to the platform on our blog, at http://sourceforge.net/blog/tag/updates/ Please let us know if there's anything we can do to make your SourceForge experience better. There's lots of ways to get in touch. You can email us at communityteam(a)sourceforge.net, on IRC at #sourceforge on Freenode, on our Facebook page at http://facebook.com/SourceForgeNet, on our Google Plus community at https://plus.google.com/communities/108980648585760076156, or via Twitter at @sourceforge. -- SourceForge.net has sent this mailing to you as a registered user of the SourceForge.net site to convey important information regarding your SourceForge.net account or your use of SourceForge.net services. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support

1 0

Updates to PEP 1 (PEP process meta-PEP)
by Nick Coghlan April 7, 2013

April 7, 2013

I just pushed two modifications to PEP 1, both triggered by the in-progress packaging PEP updates (see diff at http://hg.python.org/peps/rev/0a8e456973ed). The first change is the one I raised at the language summit, allowing pronouncement on PEPs that don't immediately affect the language definition or the standard library to occur on a list other than python-dev. This is done by giving the "Discussions-To" header a bit more force. The other change is closely related, but wasn't specifically discussed at the language summit (I only noticed the need for it when making the edits for the change above). This second change was to adjust the wording to make the "Python-Version" header optional for Standards track PEPs that don't directly affect the language reference or standard library. In effect, the new rule is that a Standards track PEP with a specific Python-Version set still has to be discussed and accepted or rejected on python-dev. It's only non-version-specific interoperability standards (like the packaging PEPs) that are fair game for another list. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

[RELEASED] Python 3.2.4 and Python 3.3.1
by Georg Brandl April 6, 2013

April 6, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team, I am pleased to announce the final releases of Python 3.2.4 and 3.3.1. Python 3.2.4 is the final regular maintenance release for the Python 3.2 series, while Python 3.3.1 is the first maintenance release for the 3.3 series. Both releases include hundreds of bugfixes. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. These releases do not include any changes in Python XML code to address these issues. Interested parties should examine the defusedxml package on PyPI: https://pypi.python.org/pypi/defusedxml To download Python 3.2.4 or Python 3.3.1, visit: http://www.python.org/download/releases/3.2.4/ or http://www.python.org/download/releases/3.3.1/ respectively. As always, please report bugs to http://bugs.python.org/ Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and all contributors) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlFgiN8ACgkQN9GcIYhpnLAXxQCdHAd2lECpYfmYM4Wbd3I01es4 898AoKBDvHtgecD/PeVRKUrdQRSWGPJg =K8RQ -----END PGP SIGNATURE-----

1 0

Semantics of __int__(), __index__()
by Mark Shannon April 6, 2013

April 6, 2013

Hi all, I was looking into http://bugs.python.org/issue17576 and I found that the semantics of __int__() and __index__() are not precisely defined in the documentation and that the implementation (CPython 3.4a) has some odd behaviour. Defining two classes: class Int1(int): def __init__(self, val=0): print("new %s" % self.__class__) class Int2(Int1): def __int__(self): return self and two instances i1 = Int1() i2 = Int2() we get the following behaviour: >>> type(int(i1)) <class 'int'> I would have expected 'Int1' >>> type(int(i2)) new <class '__main__.Int2'> <class '__main__.Int2'> Why is a new Int2 being created? operator.index does similar things. So, 1. Should type(int(x)) be exactly int, or is any subclass OK? 2. Should type(index(x)) be exactly int, or is any subclass OK? 3. Should int(x) be defined as int_check(x.__int__())? 4. Should operator.index(x) be defined as index_check(x.__index__())? where: def int_check(x): if is_int(x): return x else: raise TypeError(...) def index_check(x): if is_index(x): return x else: raise TypeError(...) The definition of is_int(x) and is_index(x) follow from the answers to 1 and 2. I had previously assumed (and would expect) that the answers were: 1. Any subclass is OK 2. Ditto 3. Yes 4. Yes Which means that def is_int(x): return int in type(x).__mro__ is_index = is_int Cheers, Mark.

23 56

[RELEASE] Python 2.7.4
by Benjamin Peterson April 6, 2013

April 6, 2013

I'm thrilled to announce the release of Python 2.7.4. 2.7.4 is the latest maintenance release in the Python 2.7 series. It includes hundreds of bugfixes to the core language and standard library. Downloads are at http://python.org/download/releases/2.7.4/ As always, please report bugs to http://bugs.python.org/ Several regressions found in the release candidate have been fixed. Many thanks to those who tested the preview release. There has recently been a lot of discussion about XML-based denial of service attacks. Specifically, certain XML files can cause XML parsers, including ones in the Python stdlib, to consume gigabytes of RAM and swamp the CPU. 2.7.4 does not include any changes in Python XML code to address these issues. Interested parties should examine the defusedxml package on PyPI: https://pypi.python.org/pypi/defusedxml This is a production release. Best wishes, Benjamin Peterson 2.7 Release Manager (on behalf of all of Python 2.7's contributors)

1 0