[omaha] with blocks and conditions

[Jeff Hinrichs]

case 3 - file or a string, use IO to convert string to a file like object,
then you can handle both in the same fashion (Python 3 only, Python 2 -
cStringIO is not context aware so you have to write a wrapper for it.

import io>>> with io.BytesIO(b"foo") as f:         f.read()


case 1 - Logging module, console, file, both or more.

case 2 - modify code to handle missing config or credentials is None.
Since you wrapped it and are handling __enter__/__exit__ I'd imagine this
is possible.

The point being, is the code can follow one of 2 code paths in all of these
cases.  If you can collapse the paths to a single one, readability goes up
and testing is easier (IMO).  In general the pattern

if foo:
  ...
  do_something()
else:
  do_something()

has a certain smell to it that I've grown to dislike and I prefer:

if foo:
  ...

do_something()

i.e.

if is_file:
  fobject = open(name, encoding)
else:
  fobject = io.BytesIO(buffer)

with fobject as f:
  do_something(f)

-Jeff

On Fri, Nov 14, 2014 at 11:46 PM, Aaron Keck <keckbug at gmail.com> wrote:

> As a little more context, here's a few of the use cases I came across.  I
> understand there are certainly other ways to structure these to avoid my
> problem, but it made me curious nonetheless.
>
> Case 1 - Some bit of code needs to run.  Normally, print the output to the
> console, but if a flag of some sort is set, write things to a file instead.
>
> Case 2 - I wrote (stole) some relatively handy code to impersonate another
> user on Windows, and I wrapped it with __enter__ and __exit__ blocks.  My
> code reads credentials from a configuration file, and if a credential
> exists for a particular run, I want to impersonate that user.  If there
> isn't any credentials configured, just keep running as the current user.
>
> Case 3 - Some bit of code does some processing.  Sometimes the input is a
> file, other times the input is simply text
>
>
> Now in many of these cases, I can resolve this by putting the logic in an
> input agnostic "do stuff" function, but typically the "do stuff" comprises
> the majority of the function I'm working with, and the with statement is
> purely intended to alter the environment that it's running in.
>
> On Fri, Nov 14, 2014 at 10:31 PM, Jeff Hinrichs <jeffh at delasco.com> wrote:
>
> > does do_stuff() do anything with the file?  or the file contents?  Seems
> > like things are switch-a-roo'd.
> > Maybe do_stuff() does too much?
> >
> > if condition_is true:
> >   file = blah
> > else:
> >   file = None
> >
> > do_stuff(file=file, ...)
> >
> > Even that seems ugly.   Can you flesh out a slightly more detailed
> >
> > -Jeff
> >
> > On Fri, Nov 14, 2014 at 3:29 PM, Aaron Keck <keckbug at gmail.com> wrote:
> >
> > > I've found myself trying to find a cleaner way of doing this:
> > >
> > > if *condition_is_true*:
> > >     with *file* as *fp:*
> > > *        do_stuff()*
> > > else:
> > > *    do_stuff()*
> > >
> > >
> > > Is there a reasonable way to wrap some code using *with* but only in
> > > certain circumstances? Most of the scenarios I've bumped up against
> have
> > > had some sort of alternate solution that works well, but I'm still
> > curious.
> > >
> > >
> > > -Aaron
> > > _______________________________________________
> > > Omaha Python Users Group mailing list
> > > Omaha at python.org
> > > https://mail.python.org/mailman/listinfo/omaha
> > > http://www.OmahaPython.org
> > >
> > _______________________________________________
> > Omaha Python Users Group mailing list
> > Omaha at python.org
> > https://mail.python.org/mailman/listinfo/omaha
> > http://www.OmahaPython.org
> >
> _______________________________________________
> Omaha Python Users Group mailing list
> Omaha at python.org
> https://mail.python.org/mailman/listinfo/omaha
> http://www.OmahaPython.org
>