RE: does python have useless destructors?

Discussion in 'Python' started by Delaney, Timothy C (Timothy), Jun 10, 2004.

  1. Michael Geary wrote:

    >>> try:
    >>> myfile = open("myfilepath", "w")
    >>> myfile.write(reallybigbuffer)
    >>> finally:
    >>> myfile.close()

    >>
    >> ... "feels" just right. This is how you do it when you
    >> want to be sure the file is closed, regardless of
    >> other considerations like garbage collection, etc.
    >>
    >> It is simple, clean, and most of all, very explicit.

    >
    > And it has a bug. :)
    >
    > What if "myfilepath" is not writable? The open() call raises an
    > exception, which jumps to the finally: block, where myfile.close()
    > fails because myfile is undefined.
    >
    > What would be the cleanest way to code this to handle that error
    > situation?


    myfile = open("myfilepath", "w")

    try:
    myfile.write(reallybigbuffer)
    finally:
    myfile.close()

    Tim Delaney
     
    Delaney, Timothy C (Timothy), Jun 10, 2004
    #1
    1. Advertising

  2. Delaney, Timothy C (Timothy)

    Tim Bradshaw Guest

    "Delaney, Timothy C (Timothy)" <> wrote in message news:<>...

    >
    > myfile = open("myfilepath", "w")
    >
    > try:
    > myfile.write(reallybigbuffer)
    > finally:
    > myfile.close()
    >


    I don't think this is save. Is it certain that there can be no
    problem between the open and the try? The expansion of Lisp macros
    which do this typically look like:

    myfile = None

    try:
    myfile = open(...)
    ...
    finally:
    if myfile
    myfile.close()
     
    Tim Bradshaw, Jun 11, 2004
    #2
    1. Advertising

  3. On Fri, 11 Jun 2004 08:44:39 -0700, Tim Bradshaw wrote:

    >> myfile = open("myfilepath", "w")
    >>
    >> try:
    >> myfile.write(reallybigbuffer)
    >> finally:
    >> myfile.close()

    >
    > I don't think this is save. Is it certain that there can be no
    > problem between the open and the try? The expansion of Lisp macros
    > which do this typically look like:
    >
    > myfile = None
    >
    > try:
    > myfile = open(...)


    What is the difference? If there are no asynchronous exceptions, both
    are safe (nothing can happen in-between). And if there are asynchronous
    exceptions, both are unsafe (the exception might come after open returned
    but before its result is stored).

    Glasgow Haskell has functions which temporarily block asynchronous
    exceptions for cases like this.

    --
    __("< Marcin Kowalczyk
    \__/
    ^^ http://qrnik.knm.org.pl/~qrczak/
     
    Marcin 'Qrczak' Kowalczyk, Jun 11, 2004
    #3
  4. Delaney, Timothy C (Timothy)

    Peter Hansen Guest

    Tim Bradshaw wrote:

    > "Delaney, Timothy C (Timothy)" <> wrote in message news:<>...
    >
    >
    >>myfile = open("myfilepath", "w")
    >>
    >>try:
    >> myfile.write(reallybigbuffer)
    >>finally:
    >> myfile.close()

    >
    > I don't think this is save. Is it certain that there can be no
    > problem between the open and the try?


    Yes, it's certain to be safe (barring multithreaded stuff
    rebinding 'myfile' in between, which is irrelevant to the
    discussion). Are you perhaps concerned that the open itself
    might fail? If so, it needs its own try/except block, as I
    noted elsewhere. The finally is only need *if* the open
    succeeds, but unless you insert code between open() and
    'try', it's safe.

    -Peter
     
    Peter Hansen, Jun 11, 2004
    #4
  5. Delaney, Timothy C (Timothy)

    Tim Bradshaw Guest

    Peter Hansen <> wrote in message news:<>...

    > Yes, it's certain to be safe (barring multithreaded stuff
    > rebinding 'myfile' in between, which is irrelevant to the
    > discussion). Are you perhaps concerned that the open itself
    > might fail? If so, it needs its own try/except block, as I
    > noted elsewhere. The finally is only need *if* the open
    > succeeds, but unless you insert code between open() and
    > 'try', it's safe.


    Yes, I think it is safe: I was thinking from the point of view of a
    Lisp macro implementor, where you have to deal with a lot of more
    general issues (for instance multiple bindings, which essentially
    insert code between the open() and the try, and user reassignments,
    which mean that the variable binding vanishes, which you need to cope
    with as well. Getting a *general* version of this correct (which is
    what I understood the original poster to be asking about) is hard to
    do, but that's not a problem for a language without macros.

    --tim
     
    Tim Bradshaw, Jun 14, 2004
    #5
    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. Michael P. Soulier

    does python have useless destructors?

    Michael P. Soulier, Jun 9, 2004, in forum: Python
    Replies:
    138
    Views:
    2,279
    Christos TZOTZIOY Georgiou
    Jun 22, 2004
  2. Robert Brewer

    RE: does python have useless destructors?

    Robert Brewer, Jun 10, 2004, in forum: Python
    Replies:
    1
    Views:
    562
    Duncan Booth
    Jun 10, 2004
  3. Tim Peters
    Replies:
    2
    Views:
    325
    Paul Rubin
    Jun 12, 2004
  4. Tim Peters
    Replies:
    7
    Views:
    3,601
    David Turner
    Jun 18, 2004
  5. Delaney, Timothy C (Timothy)

    RE: does python have useless destructors?

    Delaney, Timothy C (Timothy), Jun 15, 2004, in forum: Python
    Replies:
    2
    Views:
    423
    Ype Kingma
    Jun 15, 2004
Loading...

Share This Page