Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!lightspeed.eweka.nl!lightspeed.eweka.nl!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.004 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'explicitly': 0.05; 'context': 0.07; 'explicit': 0.07; 'finally:': 0.07; 'subject:help': 0.08; '"work': 0.09; 'cursor': 0.09; 'exception,': 0.09; 'manger': 0.09; 'throws': 0.09; 'try:': 0.09; 'wrong,': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; '(either': 0.16; '(longer': 0.16; 'clause,': 0.16; 'cleaner': 0.16; 'complexity,': 0.16; 'demonstrable': 0.16; 'handler,': 0.16; 'script,': 0.16; 'exception': 0.16; 'sat,': 0.16; 'wrote:': 0.18; 'commit': 0.19; 'aug': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'helpful': 0.24; 'cc:2**0': 0.24; '>': 0.26; 'header:In-Reply-To:1': 0.27; 'idea': 0.28; 'chris': 0.29; 'external': 0.29; 'am,': 0.29; 'generally': 0.29; 'thus': 0.29; 'especially': 0.30; 'message-id:@mail.gmail.com': 0.30; 'gives': 0.31; 'code': 0.31; 'exceptions': 0.31; 'implicit': 0.31; 'subject:some': 0.31; 'run': 0.32; 'received:209.85.212': 0.32; 'bugs': 0.33; 'fri,': 0.33; 'could': 0.34; 'received:209.85': 0.35; 'connection': 0.35; 'transaction': 0.35; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'received:209': 0.37; 'being': 0.38; 'issue': 0.38; 'pm,': 0.38; 'skip:u 10': 0.60; 'easy': 0.60; 'simple,': 0.60; 'free': 0.61; 'new': 0.61; "you're": 0.61; 'back': 0.62; "you'll": 0.62; 'such': 0.63; 'happen': 0.63; '8bit%:10': 0.64; 'more': 0.64; 'finally': 0.65; 'to:addr:gmail.com': 0.65; 'within': 0.65; 'close': 0.67; 'believe': 0.68; 'connection.': 0.74; ':).': 0.84; 'hanging': 0.84; 'opens': 0.91; 'connection,': 0.95 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=xeZFmW5SvTCOY4K/mCmjDUz6zzUxGRy8Yen1XPLUdBo=; b=NllJbsRo41FzIr9ku1lQJRHiZKxTlDGkNfE5cuzLd8R4gb1jbBcSEIqhFatI/l2fSh K1zmKxdErL88re+q4dx4WF5irTrPwR7xTaSiD3P3E/8qjcboAy7sNhDTSA5uXD5B2ChK QYtedPX7vAmaYmcIdUGjIwEiqwQWTPBeknOfMHkkkPTZKl69JYu+r6bq/yf3y3avCcog Am2gpcsgdqp3RIhclqNbM/of5pAafodyVeVKJJBQYY1Im6QuXnFPS3FJNJvofaj+MTa8 40vtA231J/Oeg9MagkxBLfjNfZX8DWcjW/DyMiVG9RP2KGn+6jCAOKvPX7+036ZFlb3B I3tQ== X-Gm-Message-State: ALoCoQl5qzHPyDyPMFlfW5E+xbzinMXKxmp4a+8ENH1eIbS/OQr39jyFq0iEhbqsq1nz5IJ4SHtR X-Received: by 10.180.38.39 with SMTP id d7mr7560363wik.24.1407544363512; Fri, 08 Aug 2014 17:32:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Chris Kaynor Date: Fri, 8 Aug 2014 17:32:23 -0700 Subject: Re: Newbie needing some help To: Chris Angelico Content-Type: multipart/alternative; boundary=e89a8f646fcfcb0acc0500277581 Cc: "python-list@python.org" X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 142 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1407546217 news.xs4all.nl 2880 [2001:888:2000:d::a6]:40239 X-Complaints-To: abuse@xs4all.nl X-Received-Bytes: 9929 X-Received-Body-CRC: 2504947915 Xref: csiph.com comp.lang.python:75920 --e89a8f646fcfcb0acc0500277581 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 8, 2014 at 5:13 PM, Chris Angelico wrote: > On Sat, Aug 9, 2014 at 9:55 AM, Chris Kaynor > wrote: > > try: > > action > > commit > > finally: > > rollback > > If commit/rollback automatically opens a new transaction, this would > just roll back an empty transaction - not a big deal. But yes, I do > see what you're looking at here. > > However, structures like this are necessary only if you're hanging > onto the database connection. Python gives you a well-defined > unhandled-exception handler, and it's easy to just let exceptions > happen - if something goes wrong, you won't commit, and you'll get a > helpful traceback on the console. My recommended model for Python > databasing is: > > Create database connection, get cursor > while "work to do": > do work > Commit > > Until such time as you have a demonstrable need for more complexity, > this model is safe, simple, and easy to work with. And less code > generally means less bugs :) > The main issue I can see with that idea is that the exception will keep a reference to the database connection (as with all locals), so unless you explicitly close it within a finally clause, the database connection could still be left hanging, and thus no rollback will occur. With just: openConnection while workToDo: doWork commit If at any time, doWork throws an exception, the connection could be left hanging, especially if the code is being run as an interactive script, and not as an application. I believe this is one case where explicit is better than implicit :) - its better to explicitly free the external resources, at the minimum, with something like: openConnection try: while worktoDo: doWork commit finally: closeConnection But, depending on the needs of the system (longer living connections, for example), that may need to have explicit rollback as well. As a rule of thumb, I have a context manger to deal with the specific needs (either just a "with transition" or a "with connection"). Keeps the code cleaner :). Chris --e89a8f646fcfcb0acc0500277581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Aug 8, 2014 at 5:13 PM, Chris Angelico <rosuav@gmail.com>= wrote:
On Sat, Aug 9, 2014 at 9:55 = AM, Chris Kaynor <ckaynor@zi= ndagigames.com> wrote:
> try:
> =C2=A0 =C2=A0 action
> =C2=A0 =C2=A0 commit
> finally:
> =C2=A0 =C2=A0 rollback

If commit/rollback automatically opens a new transaction, this would<= br> just roll back an empty transaction - not a big deal. But yes, I do
see what you're looking at here.

However, structures like this are necessary only if you're hanging
onto the database connection. Python gives you a well-defined
unhandled-exception handler, and it's easy to just let exceptions
happen - if something goes wrong, you won't commit, and you'll get = a
helpful traceback on the console. My recommended model for Python
databasing is:

Create database connection, get cursor
while "work to do":
=C2=A0 =C2=A0 do work
Commit

Until such time as you have a demonstrable need for more complexity,
this model is safe, simple, and easy to work with. And less code
generally means less bugs :)

The main i= ssue I can see with that idea is that the exception will keep a reference t= o the database connection (as with all locals), so unless you explicitly cl= ose it within a finally clause, the database connection could still be left= hanging, and thus no rollback will occur.

With just:

openConnection
while workToDo:
=C2=A0 =C2=A0 doWork
commit
=

If at any time, doWork throws an exception, the connect= ion could be left hanging, especially if the code is being run as an intera= ctive script, and not as an application.

I believe this is one case where explicit is better tha= n implicit :) - its better to explicitly free the external resources, at th= e minimum, with something like:

openConnection
try:
=C2=A0 =C2=A0 while worktoDo:
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 doWork
=C2=A0 =C2=A0 commit
finally:
=C2=A0 =C2=A0 closeConnection
=C2=A0
But, dependi= ng on the needs of the system (longer living connections, for example), tha= t may need to have explicit rollback as well.

As a rule of thumb, I have a context manger to deal wit= h the specific needs (either just a "with transition" or a "= with connection"). Keeps the code cleaner :).

Chris=C2=A0
--e89a8f646fcfcb0acc0500277581--