Re: Python's "only one way to do it" philosophy isn't good?

Discussion in 'Python' started by Jean-Paul Calderone, Jun 29, 2007.

  1. On Fri, 29 Jun 2007 09:56:14 -0400, Douglas Alan <> wrote:
    >"Chris Mellon" <> writes:
    >
    >> You're arguing against explicit resource management with the argument
    >> that you don't need to manage resources. Can you not see how
    >> ridiculously circular this is?

    >
    >No. It is insane to leave files unclosed in Java (unless you know for
    >sure that your program is not going to be opening many files) because
    >you don't even know that the garbage collector will ever even run, and
    >you could easily run out of file descriptors, and hog system
    >resources.
    >
    >On the other hand, in Python, you can be 100% sure that your files
    >will be closed in a timely manner without explicitly closing them, as
    >long as you are safe in making certain assumptions about how your code
    >will be used. Such assumptions are called "preconditions", which are
    >an understood notion in software engineering and by me when I write
    >software.


    You realize that Python has exceptions, right? Have you ever encountered
    a traceback object? Is one of your preconditions that no one will ever
    handle an exception raised by your code or by their own code when it is
    invoked by yours?

    Jean-Paul
     
    Jean-Paul Calderone, Jun 29, 2007
    #1
    1. Advertising

  2. Jean-Paul Calderone

    Douglas Alan Guest

    Jean-Paul Calderone <> writes:

    >>On the other hand, in Python, you can be 100% sure that your files
    >>will be closed in a timely manner without explicitly closing them, as
    >>long as you are safe in making certain assumptions about how your code
    >>will be used. Such assumptions are called "preconditions", which are
    >>an understood notion in software engineering and by me when I write
    >>software.


    > You realize that Python has exceptions, right?


    Yes, of course.

    > Have you ever encountered a traceback object?


    Yes, of course.

    > Is one of your preconditions that no one will ever handle an
    > exception raised by your code or by their own code when it is
    > invoked by yours?


    A precondition of much of my Python code is that callers won't
    squirrel away large numbers of tracebacks for long periods of time. I
    can live with that. Another precondition of much of my code is that
    the caller doesn't assume that it is thread-safe. Another
    precondition is that the caller doesn't assume that it is likely to
    meet real-time constraints. Another precondition is that the caller
    doesn't need my functions to promise not to generate any garbage that
    might call the GC to invoked.

    If I had to write all my code to work well without making *any*
    assumptions about what the needs of the caller might be, then my code
    would have to be much more complicated, and then I'd spend more effort
    making my code handle situations that it won't face for my purposes.
    Consequently, I'd have less time to make my software have the
    functionality that I actually require.

    Regarding, specifically, tracebacks holding onto references to open
    files -- have you considered that you may actually *want* to see the
    file in the state that it was in when the exception was raised for the
    purposes of debugging, rather than having it forcefully closed on you?

    |>oug
     
    Douglas Alan, Jun 29, 2007
    #2
    1. Advertising

  3. Jean-Paul Calderone

    Duncan Booth Guest

    Douglas Alan <> wrote:

    >> Is one of your preconditions that no one will ever handle an
    >> exception raised by your code or by their own code when it is
    >> invoked by yours?

    >
    > A precondition of much of my Python code is that callers won't
    > squirrel away large numbers of tracebacks for long periods of time. I
    > can live with that. Another precondition of much of my code is that
    > the caller doesn't assume that it is thread-safe. Another
    > precondition is that the caller doesn't assume that it is likely to
    > meet real-time constraints. Another precondition is that the caller
    > doesn't need my functions to promise not to generate any garbage that
    > might call the GC to invoked.


    None of that is relevant.

    Have you ever seen any code looking roughly like this?

    def mainloop():
    while somecondition:
    try:
    dosomestuff()
    except SomeExceptions:
    handletheexception()

    Now, imagine somewhere deep inside dosomestuff an exception is raised while
    you have a file open and the exception is handled in mainloop. If the loop
    then continues with a fresh call to dosomestuff the traceback object will
    continue to exist until the next exception is thrown or until mainloop
    returns.

    There is no 'squirrelling away' needed here. The point is that it is easy
    to write code which accidentally holds onto tracebacks. It is not
    reasonable to expect the caller to analyse all situations where the
    traceback object could continue to exist.
     
    Duncan Booth, Jun 29, 2007
    #3
  4. Jean-Paul Calderone

    Douglas Alan Guest

    Duncan Booth <> writes:

    >> A precondition of much of my Python code is that callers won't
    >> squirrel away large numbers of tracebacks for long periods of time. I
    >> can live with that. Another precondition of much of my code is that
    >> the caller doesn't assume that it is thread-safe. Another
    >> precondition is that the caller doesn't assume that it is likely to
    >> meet real-time constraints. Another precondition is that the caller
    >> doesn't need my functions to promise not to generate any garbage that
    >> might call the GC to invoked.


    > None of that is relevant.


    Of course it is. I said "large number of tracebacks" up there, and
    you promptly ignored that precondition in your subsequent
    counterexample.

    > Have you ever seen any code looking roughly like this?


    > def mainloop():
    > while somecondition:
    > try:
    > dosomestuff()
    > except SomeExceptions:
    > handletheexception()


    Of course.

    > Now, imagine somewhere deep inside dosomestuff an exception is
    > raised while you have a file open and the exception is handled in
    > mainloop. If the loop then continues with a fresh call to
    > dosomestuff the traceback object will continue to exist until the
    > next exception is thrown or until mainloop returns.


    It's typically okay in my software for a single (or a few) files to
    remain open for longer than I might expect. What it couldn't handle
    is running out of file descriptors, or the like. (Just like it
    couldn't handle running out of memory.) But that's not going to
    happen with your counterexample.

    If I were worried about a file or two remaining open too long, I'd
    clear the exception in the mainloop above, after handling it. Python
    lets you do that, doesn't it?

    |>oug
     
    Douglas Alan, Jun 29, 2007
    #4
    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. Tim Peters

    RE: Python's simplicity philosophy

    Tim Peters, Nov 15, 2003, in forum: Python
    Replies:
    1
    Views:
    313
    Andrew Dalke
    Nov 15, 2003
  2. WaterWalk
    Replies:
    236
    Views:
    3,308
    Douglas Alan
    Jul 9, 2007
  3. Steve Howell
    Replies:
    2
    Views:
    313
    Steven D'Aprano
    Jun 13, 2007
  4. Madhusudan.C.S
    Replies:
    406
    Views:
    5,159
    Michele Simionato
    Jan 28, 2009
  5. Nac Temha

    Python programming philosophy

    Nac Temha, Jan 5, 2013, in forum: Python
    Replies:
    2
    Views:
    136
    Sourabh Mhaisekar
    Jan 6, 2013
Loading...

Share This Page