[EMAIL PROTECTED] writes:
> > To my eyes, that's less readable than, and has no benefit over,
> > the following:
> >
> > def foo(thing):
> > if thing:
> > result = thing+1
> > else:
> > result = -1
> > return result
I chose this to more clearly
> To my eyes, that's less readable than, and has no benefit over, the
> following:
>
> def foo(thing):
> if thing:
> result = thing+1
> else:
> result = -1
> return result
I wouldn't discount:
def foo(thing):
result = -1
if thing:
Pete Forman <[EMAIL PROTECTED]> writes:
> Ben Finney <[EMAIL PROTECTED]> writes:
>
> > Why not ensure that there is one return point from the function,
> > so the reader doesn't have to remind themselves to look for hidden
> > return points?
>
> There will always be more potential return points in
Ben Finney <[EMAIL PROTECTED]> writes:
> Why not ensure that there is one return point from the function, so
> the reader doesn't have to remind themselves to look for hidden
> return points?
There will always be more potential return points in languages that
support exceptions.
--
Pete Forma
"Carl Banks" <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
> > "Carl Banks" <[EMAIL PROTECTED]> writes:
> > > def foo(thing):
> > > if thing:
> > > return thing+1
> > > else:
> > > return -1
> > > assert False
> >
> > To my eyes, that's less readable than, and has no
Steve Holden wrote:
> Carl Banks wrote:
> [...]
> > However, I have rare cases where I do choose to use the else (ususally
> > in the midst of a complicated piece of logic, where it's be more
> > distracting than concise). In that case, I'd do something like this:
> >
> > def foo(thing):
> >
Ben Finney wrote:
> "Carl Banks" <[EMAIL PROTECTED]> writes:
>
> > However, I have rare cases where I do choose to use the else
> > (ususally in the midst of a complicated piece of logic, where it's
> > be more distracting than concise). In that case, I'd do something
> > like this:
> >
> > def f
Tal Einat wrote:
> I meant to say that:
>
> (thing and [thing+1] or [-1])[0]
>
> is more readable (IMO) than:
>
> thing != -1 and (thing and thing+1 or -1) or 0
Neither is particularly readable, though I agree that the latter is
worse since it has to have the third option ("0") on the end. But I'
At Wednesday 30/8/2006 04:47, Tal Einat wrote:
I meant to say that:
(thing and [thing+1] or [-1])[0]
is more readable (IMO) than:
thing != -1 and (thing and thing+1 or -1) or 0
Interesting to find how different persons feel "readability" - for
me, the later is rather clear (but definitivel
Sybren Stuvel wrote:
> Tal Einat enlightened us with:
> > Actually, the common work-around for this is:
> >
> > (thing and [thing+1] or [-1])[0]
> >
> > This works since non-empty lists are always considered true in
> > conditional context. This is more generic, and IMO more readable.
>
> I think
"Carl Banks" <[EMAIL PROTECTED]> writes:
> However, I have rare cases where I do choose to use the else
> (ususally in the midst of a complicated piece of logic, where it's
> be more distracting than concise). In that case, I'd do something
> like this:
>
> def foo(thing):
> if thing:
>
Carl Banks wrote:
[...]
> However, I have rare cases where I do choose to use the else (ususally
> in the midst of a complicated piece of logic, where it's be more
> distracting than concise). In that case, I'd do something like this:
>
> def foo(thing):
> if thing:
> return thing+1
>
tobiah wrote:
> def foo(thing):
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing. The first is
> possibly clearer, while the secon
Bruno Desthuilliers wrote:
> Sam Pointon a écrit :
> > Bruno Desthuilliers wrote:
> >
> >>foo = lambda thing: thing and thing + 1 or -1
> >
> >
> > The and ... or trick is buggy (what if thing == -1?)
>
> Yes, true - Should be:
> foo2 = lambda t: t != -1 and (t and t+1 or -1) or 0
>
Actually, the
Sam Pointon a écrit :
> Bruno Desthuilliers wrote:
>
>>foo = lambda thing: thing and thing + 1 or -1
>
>
> The and ... or trick is buggy (what if thing == -1?)
Yes, true - Should be:
foo2 = lambda t: t != -1 and (t and t+1 or -1) or 0
> and bad style.
Lol. Well, so what about:
foo = lambda
tobiah wrote:
> def foo(thing):
>
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
>
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing. The first is
> possibly clearer, while the s
Bruno Desthuilliers wrote:
> foo = lambda thing: thing and thing + 1 or -1
The and ... or trick is buggy (what if thing == -1?) and bad style. If
you -do- want a conditional expression, 2.5 provides one:
thing + 1 if thing else -1
No subtle logical bugs, and a good deal more obvious.
On the top
tobiah a écrit :
> def foo(thing):
>
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
>
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing. The first is
> possibly clearer, while the second is more conci
On 8/28/06, tobiah <[EMAIL PROTECTED]> wrote:
> def foo(thing):
>
> if thing:
> return thing + 1
> else:
> return -1
>
> def foo(thing):
>
> if thing:
> return thing + 1
> return -1
>
> Obviously both do the same thing.
def foo(thing):
if thing:
return thing + 1
else:
return -1
def foo(thing):
if thing:
return thing + 1
return -1
Obviously both do the same thing. The first is
possibly clearer, while the second is more concise.
Co
20 matches
Mail list logo
