simon-git: spigot (master): Simon Tatham

Sat Oct 14 21:16:12 BST 2017

TL;DR:
  0ec1dce Make testenv compatible with debug builds of Python (3).
  33ed957 pyspig.cpp: small class to arrange deferred Py_DECREF.
  ce830df Replace some explicit decrefs with PythonReferenceWrapper.
  85a1438 Add a precautionary incref/decref in PythonGlobalScope.
  b257fb6 Add a lot of new decrefs.
  2a520b0 Fix a mis-aimed decref in bigint_from_pylong.
  239c650 Remove a completely pointless bigint_to_pylong.
  599a8f3 pyspig: delete lots of copy and move constructors.

Repository:     https://git.tartarus.org/simon/spigot.git
On the web:     https://git.tartarus.org/?p=simon/spigot.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-10-14 21:16:12

commit 0ec1dce9252d56a4654713bbf39bdbd8d80c94e5
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=0ec1dce9252d56a4654713bbf39bdbd8d80c94e5;hp=4be99cff97acb0604240121eee084160eacda814
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 20:20:52 2017 +0100

    Make testenv compatible with debug builds of Python (3).

    If you run setup.py using python3.5-dbg instead of python3, then you
    get a subdir of the build directory with a name like
    'lib-stuff-3.5-pydebug' instead of 'lib-stuff-3.5'. So testenv should
    detect the debug-nature of the Python it's running under, and use that
    to adapt the glob it uses to find the right build subdir.

    That's done by checking sys.abiflags, which doesn't exist in Python 2,
    so we have to be a bit cautious about consulting it.

 python/testenv | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

commit 33ed957636e611edd8f33b27319780b0fc95d25d
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=33ed957636e611edd8f33b27319780b0fc95d25d;hp=0ec1dce9252d56a4654713bbf39bdbd8d80c94e5
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 21:04:35 2017 +0100

    pyspig.cpp: small class to arrange deferred Py_DECREF.

    With the usual C++ advantages of arranging to have things done at
    destructor time: if I set up one of these the moment I've been given
    an object I'll need to decref, then it will still get decreffed (err,
    'decced-ref'?) even if I take some early exit path like a break or a
    return or a throw.

    (However, we have to be a bit careful with the copy constructor - if
    you put one of these somewhere like a vector where the STL will copy
    it and delete the old one, it becomes quite important that each new
    copy does an incref corresponding to the decref that the old one's
    destruction will cause.)

    NFC, because I'm not actually using the new class yet.

 python/pyspig.cpp | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

commit ce830dfdba0eac2f334f153f029886bc93d48df3
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=ce830dfdba0eac2f334f153f029886bc93d48df3;hp=33ed957636e611edd8f33b27319780b0fc95d25d
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 21:04:39 2017 +0100

    Replace some explicit decrefs with PythonReferenceWrapper.

    Now we have that handy new wrapper class, it would be a shame not to
    use it.

 python/pyspig.cpp | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

commit 85a14384a014f0a6c8f275062e037e8b9d18a419
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=85a14384a014f0a6c8f275062e037e8b9d18a419;hp=ce830dfdba0eac2f334f153f029886bc93d48df3
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 18:52:10 2017 +0100

    Add a precautionary incref/decref in PythonGlobalScope.

    Unlike things like file access contexts which have the lifetime of a
    spigot object that was returned to the user, this class's lifetime is
    contained within one call to Spigot_parse. But there are calls back to
    the Python runtime inside that, so who knows, the object we wrapped up
    _might_ get decreffed for some reason I haven't foreseen. Add the
    usual inc/dec pair in the constructor and destructor to make sure that
    doesn't happen.

 python/pyspig.cpp | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

commit b257fb69ad52d61f78be157349a10fc57c556865
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=b257fb69ad52d61f78be157349a10fc57c556865;hp=85a14384a014f0a6c8f275062e037e8b9d18a419
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 18:54:18 2017 +0100

    Add a lot of new decrefs.

    According to the Python C API manual, objects returned from PyObject_*
    and PyMapping_* both come with a reference that the caller now owns.
    And bigint_from_pylong certainly does. So I've sprinkled in a few more
    reference wrappers in places where they previously weren't.

 python/pyspig.cpp | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

commit 2a520b07c4016a0bd1025abfadade6793e42adfe
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=2a520b07c4016a0bd1025abfadade6793e42adfe;hp=b257fb69ad52d61f78be157349a10fc57c556865
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 18:55:00 2017 +0100

    Fix a mis-aimed decref in bigint_from_pylong.

    When the input number is negative and we start by making it positive
    again, I had decreffed the value passed in by the caller as a side
    effect, which surely would have gone badly sooner or later. Now
    instead I arrange to decref the _new_ value I've constructed - using
    PythonReferenceWrapper to make that happen on function exit and not
    before.

 python/pyspig.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 239c650664f25aadf5034009ccb47482229dde9f
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=239c650664f25aadf5034009ccb47482229dde9f;hp=2a520b07c4016a0bd1025abfadade6793e42adfe
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 20:44:48 2017 +0100

    Remove a completely pointless bigint_to_pylong.

    If we're always passing in the number 0, there's no earthly purpose in
    converting that into a bigint, then into hex, then into a Python long
    object, when we can just go straight from 0 to a Python long object in
    the completely obvious way! I have _no_ idea how I managed to write
    the previous version without noticing.

 python/pyspig.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 599a8f39f01b14626e502d13dbf4d0a33f43ebe0
web diff https://git.tartarus.org/?p=simon/spigot.git;a=commitdiff;h=599a8f39f01b14626e502d13dbf4d0a33f43ebe0;hp=239c650664f25aadf5034009ccb47482229dde9f
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Oct 14 21:08:54 2017 +0100

    pyspig: delete lots of copy and move constructors.

    Developing PythonReferenceWrapper reminded me that if you have a C++
    class that holds a reference to a ref-counted Python object which is
    increffed in the constructor and decreffed in the destructor, then you
    had better be sure you don't ever call the default copy constructor on
    such an object.

    For PythonReferenceWrapper itself, I wrote a copy constructor. But
    there are lots of other objects in this module which follow the same
    pattern, and those had no defence except that I never _intended_ to
    copy them in the first place. So now I've used the C++11 feature of
    deleting the copy constructors, to ensure that that good intention is
    actually enforced.

 python/pyspig.cpp | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)