I'd bet you would stress your point Steven! But you don't need to persuade me,
I do already agree.
I just meant to say that, when the advantage is little, there's no need to
rewrite a working function.
And that with modern CPUs, if tests take so little time, that even some
redundant one is not
On Sat, 18 Dec 2010 19:59:45 -0800, Carl Banks wrote:
> On Dec 17, 12:23 am, Steven D'Aprano +comp.lang.pyt...@pearwood.info> wrote:
>> On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
>> > Even without the cleanup issue, sometimes you want to edit a function
>> > to affect all return values
On Dec 17, 12:23 am, Steven D'Aprano wrote:
> On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
> > Even without the cleanup issue, sometimes you want to edit a function to
> > affect all return values somehow. If you have a single exit point you
> > just make the change there; if you have mu
On Sat, 18 Dec 2010 12:29:31 +0100, Francesco wrote:
[...]
> I agree to your point, but I'm afraid you chose a wrong example (AFAIK,
> and that's not much). Sure, the second version of function(arg) is much
> more readable, but why do you think the first one would do "*lots* of
> unnecessary work
On 17/12/2010 0.51, Steven D'Aprano wrote:
Don't get me wrong... spaghetti code is*bad*. But there are other ways
of writing bad code too, and hanging around inside a function long after
you've finished is also bad:
def function(arg):
done = False
do_something()
if some_condition:
On Fri, 17 Dec 2010 17:26:08 +, Grant Edwards wrote:
> Give me code that's easy-to-read and doesn't work rather code that works
> and can't be read any day.
Well, in that case, you'll love my new operating system, written in 100%
pure Python:
[start code]
print("this is an operating system"
On Fri, 17 Dec 2010 10:53:45 -0500, Steve Holden wrote about for...else:
> This construct appears to be unpopular in actual use, and when it comes
> up in classes and seminars there is always interesting debate as people
> discuss potential uses and realise there are useful applications.
Yes, I f
On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote:
> (This is mostly a style question, and perhaps one that has already been
> discussed elsewhere. If so, a pointer to that discussion will be
> appreciated!)
>
> When I started learning Python, I wrote a lot of methods that looked
> like this
-Original Message-
You have outlined what happens when cond1 and cond2 both evaluate to
True -- what happens if, say, cond2 evaluates to False?
- I reply
And the light goes on! (And palm strikes forehead.) I was thinking
that the error we were processing was raised by
On 2010-12-16, Steven D'Aprano wrote:
> On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote:
>
>> (This is mostly a style question, and perhaps one that has already been
>> discussed elsewhere. If so, a pointer to that discussion will be
>> appreciated!)
>>
>> When I started learning Python, I
On 2010-12-16, Stefan Sonnenberg-Carstens
wrote:
> The advantage in latter case is fewer operations, because you can
> skip the assignments, and it is more readable.
>
> The "one entry, one exit" is an advice. Not a law.
> Your code is OK.
>
> As long as it works ;-)
Even that last bit isn't th
> I now remember this idiom as the "break else" construct: either the loop
> breaks, or the "else:" suite is executed.
A perfect description.
Malcolm
--
http://mail.python.org/mailman/listinfo/python-list
Tim Golden writes:
> On 17/12/2010 15:53, Steve Holden wrote:
>
> [... snip example of for-else ...]
>
>> This construct appears to be unpopular in actual use, and when it comes
>> up in classes and seminars there is always interesting debate as people
>> discuss potential uses and realise there
Steve Holden writes:
> I think the choice of keyword is probably not Guido's crowning
> language achievement,
I remember the behaviour by considering a typical application:
for thing in things:
if shinyp(thing):
break
else:
raise DullError, 'nothi
On 12/17/2010 11:13 AM, Tim Golden wrote:
> On 17/12/2010 15:53, Steve Holden wrote:
>
> [... snip example of for-else ...]
>
>> This construct appears to be unpopular in actual use, and when it comes
>> up in classes and seminars there is always interesting debate as people
>> discuss potential
Rob Richardson wrote:
My thanks for pointing out the existence of the else: suite in the for
statement. However, I remain confused. For reference, here's the
original code:
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
Jean-Michel Pichavant writes:
> What about,
>
> def myMethod():
>for condition, exitCode in [
>(cond1, 'error1'),
>(cond2, 'very bad error'),
>]:
>if not condition:
>break
>else:
> do_some_usefull_stuff() # executed only if the we never
On 17/12/2010 15:53, Steve Holden wrote:
[... snip example of for-else ...]
This construct appears to be unpopular in actual use, and when it comes
up in classes and seminars there is always interesting debate as people
discuss potential uses and realise there are useful applications.
I use t
My thanks for pointing out the existence of the else: suite in the for
statement. However, I remain confused. For reference, here's the
original code:
> def myMethod():
> for condition, exitCode in [
> (cond1, 'error1'),
> (cond2, 'very bad error'),
> ]:
>
On 12/17/2010 9:38 AM, Steven D'Aprano wrote:
> On Fri, 17 Dec 2010 09:09:49 -0500, Rob Richardson wrote:
>
>
>> First, just to clarify, I don't think the indentation I saw was what was
>> originally posted. The "else" must be indented to match the "if", and
>> the two statements under "else" ar
On Thu, Dec 16, 2010 at 6:51 PM, Steven D'Aprano
wrote:
...
> Functions always have one entry. The only way to have multiple entry
> points is if the language allows you to GOTO into the middle of a
> function, and Python sensibly does not allow this. The "one entry, one
> exit" rule comes from th
Rob Richardson wrote:
-Original Message-
What about,
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
]:
if not condition:
break
else:
do_some_usefull_stuff() # executed only if the
On Fri, 17 Dec 2010 09:09:49 -0500, Rob Richardson wrote:
> First, just to clarify, I don't think the indentation I saw was what was
> originally posted. The "else" must be indented to match the "if", and
> the two statements under "else" are in the else block. The return
> statement is indente
-Original Message-
What about,
def myMethod():
for condition, exitCode in [
(cond1, 'error1'),
(cond2, 'very bad error'),
]:
if not condition:
break
else:
do_some_usefull_stuff() # executed only if the we never hit the
break
John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self, arg1, arg2):
if s
On Thu, 16 Dec 2010 20:32:29 -0800, Carl Banks wrote:
> Even without the cleanup issue, sometimes you want to edit a function to
> affect all return values somehow. If you have a single exit point you
> just make the change there; if you have mulitple you have to hunt them
> down and change all o
On 12/16/2010 11:32 PM, Carl Banks wrote:
> On Dec 16, 2:56 pm, Ryan Kelly wrote:
>> On Thu, 2010-12-16 at 21:49 +, John Gordon wrote:
>>> (This is mostly a style question, and perhaps one that has already been
>>> discussed elsewhere. If so, a pointer to that discussion will be
>>> appreciat
On Dec 16, 2:56 pm, Ryan Kelly wrote:
> On Thu, 2010-12-16 at 21:49 +, John Gordon wrote:
> > (This is mostly a style question, and perhaps one that has already been
> > discussed elsewhere. If so, a pointer to that discussion will be
> > appreciated!)
>
> > When I started learning Python, I
"Steven D'Aprano" wrote in message
news:4d0aa5e7$0$29997$c3e8da3$54964...@news.astraweb.com...
It doesn't look like you were learning Python. It looks like you were
learning C with Python syntax :(
True, although in many cases one has to interface to legacy C code where it'd
be rather more co
John Gordon wrote:
> But lately I've been preferring this style:
>
> def myMethod(self, arg1, arg2):
>
> if some_bad_condition:
> return bad1
>
> elif some_other_bad_condition:
> return bad2
>
> elif yet_another_bad_condition:
> return bad3
>
> do_some_useful_st
On Thu, 16 Dec 2010 21:49:07 +, John Gordon wrote:
> (This is mostly a style question, and perhaps one that has already been
> discussed elsewhere. If so, a pointer to that discussion will be
> appreciated!)
>
> When I started learning Python, I wrote a lot of methods that looked
> like this
On Thu, Dec 16, 2010 at 3:41 PM, Stefan Sonnenberg-Carstens
wrote:
> return [x for x,y in
> ((bad1,some_bad_condition),(bad2,some_other_bad_condition),(bad3,yet_another_bad_condition),(good1,do_some_useful_stuff()
> or True)) if x][0]
This doesn't work. do_some_usefull_stuff() gets called during
On Thu, 2010-12-16 at 21:49 +, John Gordon wrote:
> (This is mostly a style question, and perhaps one that has already been
> discussed elsewhere. If so, a pointer to that discussion will be
> appreciated!)
>
> When I started learning Python, I wrote a lot of methods that looked like
> this:
Am 16.12.2010 22:49, schrieb John Gordon:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self
On 2010-12-16, John Gordon wrote:
> (This is mostly a style question, and perhaps one that has already been
> discussed elsewhere. If so, a pointer to that discussion will be
> appreciated!)
>
> When I started learning Python, I wrote a lot of methods that looked like
> this:
>
>
> def myMethod
On 2010-12-16, John Gordon wrote:
> I like this style more, mostly because it eliminates a lot of indentation.
>
> However I recall one of my college CS courses stating that "one entry,
> one exit" was a good way to write code, and this style has lots of exits.
So, take the good intentation from
John Gordon wrote:
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self, arg1, arg2):
if so
(This is mostly a style question, and perhaps one that has already been
discussed elsewhere. If so, a pointer to that discussion will be
appreciated!)
When I started learning Python, I wrote a lot of methods that looked like
this:
def myMethod(self, arg1, arg2):
if some_good_condition:
38 matches
Mail list logo
