[PEP] auto keyword for automatic objects support in Python

Discussion in 'Python' started by Manlio Perillo, Jun 18, 2004.

  1. Hi.
    This post follows "does python have useless destructors".
    I'm not an expert, so I hope what I will write is meaningfull and
    clear.


    Actually in Python there is no possibility to write code that follows
    C++ RAII pattern.
    Of course Python objects are not statics like in C++, but in C++ the
    auto_ptr class is used for enforcing this pattern for dynamical
    allocated objects, by using a 'destructive' pointer semantic.


    Now, here is a simple example of Python code:


    >>> afile = file('foo.txt', 'w')


    >>> def use_file(afile):

    .... afile.write('hello')

    >>> use_file(afile)


    >>> afile.write(' word')




    Internally (at least in CPython) when the function is called, a frame
    object is created, with a dictionary of all local variables.
    When the function terminates the frame is 'deleted' (where 'deleted'
    means: 'its reference count is decremented').
    The frame destructor then calls local variables destructors (again,
    local variables references counter are decremented).

    For our example this means that when use_file function exits, this
    equivalent Python code is execuded:

    >>> del afile



    Of course this not deletes afile, since there exists another reference
    to it.


    What I'm proposing is to add a new keyword 'auto'. Here its use:

    >>> afile = file('foo.txt', 'w')
    >>> auto afile


    >>> def use_file(afile):

    .... afile.write('hello')

    >>> use_file(afile)


    >>> afile.write(' word') # ==> error, file closed. See above




    Simply, auto objects behaves like C++ auto_ptr but with important
    differences and with the need of some support by the objects.

    This equivalent code is now executed when the function exits:


    >>> if hasattr(afile, '__deinit__'): afile.__deinit__() # see above
    >>> del afile




    With the use of auto there is the need(?) to think at object
    destruction as a two fase operation (like object creation with __new__
    and __init__).

    In fact __del__ method is called when the object is being
    deallocated/garbage collected (actually this is not 'deterministic').
    The RAII pattern requires simply that as an object goes 'out of scope'
    it should releases all the 'external resources' it has acquired.
    So there is the need of a second special method (call it __deinit__)
    that should be called for auto objects when they go 'out of scope'
    (in a 'deterministic' way).


    As an example, for a file object __deinit__ code is, of course, the
    same as in the __del__ code.


    More in detail:
    as __init__ creates the class invariant, __deinit__ should be
    'destroy' it; that is, it should be put the instance in a 'neutral'
    state: all external resource released.

    The difference between __deinit__ and __del__ is that after __del__ is
    called the object is supposed to be deallocated/garbage collected;
    after __deinit__ the object is still 'live' in a 'neutral' state.
    So I think it is better to have two distinct methods.



    Issues:
    Q) Should be Frame objects be auto?
    R) They should be auto if there are auto local variables in it.

    Q) What about compound objects, ad example:

    >>> class hold_file:

    .... def __init__(self, afile): self.file = afile

    R) self.file should be auto if an hold_file instance is auto.




    Regards Manlio Perillo
    Manlio Perillo, Jun 18, 2004
    #1
    1. Advertising

  2. On Fri, 18 Jun 2004 16:32:39 GMT, rumours say that Manlio Perillo
    <> might have written:

    [snip]

    >With the use of auto there is the need(?) to think at object
    >destruction as a two fase operation (like object creation with __new__
    >and __init__).
    >
    >In fact __del__ method is called when the object is being
    >deallocated/garbage collected (actually this is not 'deterministic').
    >The RAII pattern requires simply that as an object goes 'out of scope'
    >it should releases all the 'external resources' it has acquired.
    >So there is the need of a second special method (call it __deinit__)
    >that should be called for auto objects when they go 'out of scope'
    >(in a 'deterministic' way).


    [snip]

    I'm afraid your PEP's strongest adversary will be the "Explicit is
    better than implicit". You suggest complications to the language
    implementation that can be avoided just by user code.

    For example, you could have a class Deallocator (untested improvised
    code):

    class Deallocator:
    def __init__(self, *args):
    self.args = args
    def deallocate(self):
    for obj in self.args:
    obj.__deinit__()

    then in your function start:
    auto = Deallocator(obj1, obj2 ...)

    and in your function end:
    auto.deallocate()

    If your function has multiple exit points, wrap its code in a try ...
    finally sequence.


    These are some of the obvious counter-arguments for your PEP, and
    without looking I assume there have been already similar discussions in
    the past. Good luck :)
    --
    TZOTZIOY, I speak England very best,
    "I have a cunning plan, m'lord" --Sean Bean as Odysseus/Ulysses
    Christos TZOTZIOY Georgiou, Jun 22, 2004
    #2
    1. Advertising

  3. On Tue, 22 Jun 2004 12:16:05 +0300, Christos "TZOTZIOY" Georgiou
    <> wrote:

    >On Fri, 18 Jun 2004 16:32:39 GMT, rumours say that Manlio Perillo
    ><> might have written:
    >
    >[snip]
    >
    >
    >[snip]
    >
    >I'm afraid your PEP's strongest adversary will be the "Explicit is
    >better than implicit". You suggest complications to the language
    >implementation that can be avoided just by user code.
    >
    >For example, you could have a class Deallocator (untested improvised
    >code):
    >
    >class Deallocator:
    > def __init__(self, *args):
    > self.args = args
    > def deallocate(self):
    > for obj in self.args:
    > obj.__deinit__()
    >
    >then in your function start:
    > auto = Deallocator(obj1, obj2 ...)
    >
    >and in your function end:
    > auto.deallocate()
    >
    >If your function has multiple exit points, wrap its code in a try ...
    >finally sequence.
    >
    >


    The problem is that one have to use finally consistently.
    The C++ RAII pattern is more simple.


    Thanks and regards Manlio Perillo
    Manlio Perillo, Jun 23, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christoph Becker-Freyseng

    PEP for new modules (I read PEP 2)

    Christoph Becker-Freyseng, Jan 15, 2004, in forum: Python
    Replies:
    3
    Views:
    362
    Gerrit Holl
    Jan 16, 2004
  2. Replies:
    6
    Views:
    443
    Peter Otten
    May 10, 2007
  3. Hamilton, William

    RE: keyword checker - keyword.kwlist

    Hamilton, William, May 10, 2007, in forum: Python
    Replies:
    4
    Views:
    344
  4. Lie
    Replies:
    25
    Views:
    721
    Dafydd Hughes
    Dec 18, 2007
  5. linkswanted
    Replies:
    1
    Views:
    887
Loading...

Share This Page