On Sun, 12 Sep 2010 12:08:26 +1200, Lawrence D'Oliveiro wrote:
>> And that is exactly the reason why the Samurai Principle says to not
>> return None when the function fails to do what it intended to do.
>
> How can the function “fail” when it returns what it is specified to
> return?
Are you t
On 9/11/10 7:08 PM, Lawrence D'Oliveiro wrote:
In message, Robert
Kern wrote:
On 9/10/10 5:17 PM, Lawrence D'Oliveiro wrote:
In message, Ian
Kelly wrote:
And returning None on failure is dangerous, because if the programmer
does not take care to handle that case, the program may attempt to
In message , Robert
Kern wrote:
> On 9/10/10 5:17 PM, Lawrence D'Oliveiro wrote:
>
>> In message, Ian
>> Kelly wrote:
>>
>>> And returning None on failure is dangerous, because if the programmer
>>> does not take care to handle that case, the program may attempt to
>>> regard it as actual data.
>
On Sat, 11 Sep 2010 10:17:21 +1200, Lawrence D'Oliveiro wrote:
> In message , Ian
> Kelly wrote:
>
>> And returning None on failure is dangerous, because if the programmer
>> does not take care to handle that case, the program may attempt to
>> regard it as actual data.
>
> But None *is* actual
On 9/10/10 5:17 PM, Lawrence D'Oliveiro wrote:
In message, Ian Kelly
wrote:
And returning None on failure is dangerous, because if the programmer
does not take care to handle that case, the program may attempt to
regard it as actual data.
But None *is* actual data.
And that is exactly the r
In message , Ian Kelly
wrote:
> And returning None on failure is dangerous, because if the programmer
> does not take care to handle that case, the program may attempt to
> regard it as actual data.
But None *is* actual data.
--
http://mail.python.org/mailman/listinfo/python-list
Grant Edwards writes:
> I find it much easier to screw things up using the
> "exceptional return value" method than the "exception raise" method.
That may be partly due to Python's not-so-good facilities for
implementing the "exceptional return value" method. To be fair, plenty
of other language
On 2010-09-08, Steven D'Aprano wrote:
> On Wed, 08 Sep 2010 14:44:12 +, Grant Edwards wrote:
>>
>>> If you don't trap them just right, they cause a stack trace,
>>
>> Not always. That is the effect of not trapping them at all. However,
>> you can trap them incorrectly -- which can result in
On Wed, 08 Sep 2010 14:44:12 +, Grant Edwards wrote:
> On 2010-09-08, Steven D'Aprano
> wrote:
>> On Tue, 07 Sep 2010 20:35:45 -0700, Phlip wrote:
>>
>>> Exceptions are very dangerous by themselves, because if you don't trap
>>> them just right they can cause side-effects.
>>
>> Huh?
>>
>> If
On 2010-09-08, Steven D'Aprano wrote:
> On Tue, 07 Sep 2010 20:35:45 -0700, Phlip wrote:
>
>> Exceptions are very dangerous by themselves, because if you don't trap
>> them just right they can cause side-effects.
>
> Huh?
>
> If you don't trap them just right, they cause a stack trace,
Not always
On Tue, 07 Sep 2010 20:38:14 -0700, Phlip wrote:
> On Sep 7, 5:51 pm, Terry Reedy wrote:
>> On 9/7/2010 2:53 PM, Phlip wrote:
>>
>> > They are for situations which the caller should care not to handle.
>>
>> Python is simply not designed that way. Exception raising and catching
>> is a common flo
On Tue, 07 Sep 2010 20:35:45 -0700, Phlip wrote:
> Exceptions are very dangerous by themselves, because if you don't trap
> them just right they can cause side-effects.
Huh?
If you don't trap them just right, the cause a stack trace, which is a
side-effect I suppose. But it's an *intended* side
On Tue, Sep 7, 2010 at 9:38 PM, Phlip wrote:
> Everyone gets defensive about the design flaws in their own language.
> But the django.db situation is not even a design flaw; just a
> misinterpretation of the Samurai Principle. int('yo') shall throw an
> exception, but a missing record could be the
On Tue, Sep 7, 2010 at 9:35 PM, Phlip wrote:
> Exceptions are very dangerous by themselves, because if you don't trap
> them just right they can cause side-effects.
And returning None on failure is dangerous, because if the programmer
does not take care to handle that case, the program may attemp
Phlip writes:
> On Sep 7, 4:38 pm, Benjamin Kaplan wrote:
>
> > When you're using a language, you should use the style that the
> > language emphasizes.
>
> You mean like this?
>
> uri = reverse('my_uri_name', kwargs=dict(pk=record.pk))
Do you think that style is emphasised by Python? What gi
On Sep 7, 4:38 pm, Benjamin Kaplan wrote:
> When you're using a language, you should use the style that the
> language emphasizes.
You mean like this?
uri = reverse('my_uri_name', kwargs=dict(pk=record.pk))
That 'kwargs' there is ... a lapse of judgement. It is exposing a
technical detail (t
On Sep 7, 5:51 pm, Terry Reedy wrote:
> On 9/7/2010 2:53 PM, Phlip wrote:
>
> > They are for situations which the caller should care not to handle.
>
> Python is simply not designed that way. Exception raising and catching
> is a common flow-control method in Python. If you cannot stand that,
> Py
On Sep 7, 6:23 pm, Lawrence D'Oliveiro wrote:
> Does catching the exception not defeat the “Samurai Principle”?
Read my comic:
http://c2.com/cgi/wiki?SamuraiPrinciple
Exceptions are very dangerous by themselves, because if you don't trap
them just right they can cause side-effects. They are
Lawrence D'Oliveiro wrote:
Does catching the exception not defeat the “Samurai Principle”?
Not if it lets you turn defeat into victory. Or
redefine victory so that it includes defeat.
Or something.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
In message
<74587da9-8861-4400-bbd7-1ea4f8182...@l38g2000pro.googlegroups.com>, Phlip
wrote:
> Pythonistas:
>
> The "Samurai Principle" says to return victorious, or not at all. This
> is why django.db wisely throws an exception, instead of simply
> returning None, if it encounters a "record not
On 9/7/2010 2:53 PM, Phlip wrote:
They are for situations which the caller should care not to handle.
Python is simply not designed that way. Exception raising and catching
is a common flow-control method in Python. If you cannot stand that,
Python is not for you.
--
Terry Jan Reedy
--
h
On Tue, Sep 7, 2010 at 6:20 PM, Phlip wrote:
> On Sep 7, 1:06 pm, Bruno Desthuilliers
> wrote:
>
>> try:
>> return Model.objects.get(pk=42)
>> except Model.DoesNotExist:
>> return sentinel
>
> Visual Basic Classic had a Collection Class, which worked essentially
> like a real language's Has
On Sep 7, 1:06 pm, Bruno Desthuilliers
wrote:
> try:
> return Model.objects.get(pk=42)
> except Model.DoesNotExist:
> return sentinel
Visual Basic Classic had a Collection Class, which worked essentially
like a real language's Hash, Map, or Dict.
Except - it had no operation to test membe
Phlip a écrit :
> On Sep 7, 10:36 am, Ian Kelly wrote:
>> On Tue, Sep 7, 2010 at 10:02 AM, Phlip wrote:
>>> Back to the topic, I tend to do this:
>>> for record in Model.objects.filter(pk=42):
>>> return record
>>> return sentinel
>> How is that any better than just catching the exception?
Phlip a écrit :
> On Sep 7, 10:12 am, Bruno Desthuilliers 42.desthuilli...@websiteburo.invalid> wrote:
>> Phlip a écrit :
>>
>>> Back to the topic, I tend to do this:
>>> for record in Model.objects.filter(pk=42):
>>> return record
>>> return sentinel
>> WTF alert here...
>
> I don't see
On 09/07/10 13:53, Phlip wrote:
On Sep 7, 11:36 am, Tim Chase wrote:
And no it's not "much clearer". Exceptions are for catastrophic errors
that the caller should care not to handle. A "record not found" is not
a catastrophe.
Exceptions are not limited to catastrophic errors, simply
exceptio
On Sep 7, 11:36 am, Tim Chase wrote:
> > And no it's not "much clearer". Exceptions are for catastrophic errors
> > that the caller should care not to handle. A "record not found" is not
> > a catastrophe.
>
> Exceptions are not limited to catastrophic errors, simply
> exceptional (not the common
On 09/07/10 12:52, Phlip wrote:
try:
return Model.objects.get(pk=42)
except Model.DoesNotExist:
return sentinel
The flow of control is much clearer this way.
It reminds me of Visual Basic.
And no it's not "much clearer". Exceptions are for catastrophic errors
that the caller should
On Tue, Sep 7, 2010 at 11:52 AM, Phlip wrote:
> And no it's not "much clearer".
It's clearer because it does exactly what it says it does, unlike your
approach that masquerades as a loop.
> Exceptions are for catastrophic errors
No, they're for flagging "exceptional" states. /Errors/ are for
c
On Sep 7, 10:36 am, Ian Kelly wrote:
> On Tue, Sep 7, 2010 at 10:02 AM, Phlip wrote:
> > Back to the topic, I tend to do this:
>
> > for record in Model.objects.filter(pk=42):
> > return record
>
> > return sentinel
>
> How is that any better than just catching the exception?
>
> try:
>
On Tue, Sep 7, 2010 at 10:02 AM, Phlip wrote:
> Back to the topic, I tend to do this:
>
> for record in Model.objects.filter(pk=42):
> return record
>
> return sentinel
How is that any better than just catching the exception?
try:
return Model.objects.get(pk=42)
except Model.DoesNotExi
On Sep 7, 10:12 am, Bruno Desthuilliers wrote:
> Phlip a écrit :
>
> > Back to the topic, I tend to do this:
>
> > for record in Model.objects.filter(pk=42):
> > return record
>
> > return sentinel
>
> WTF alert here...
I don't see how anyone could WTF that. Are you pretending to be a ne
Phlip a écrit :
Back to the topic, I tend to do this:
for record in Model.objects.filter(pk=42):
return record
return sentinel
WTF alert here...
Having lots of short methods helps, because return provides both
control-flow and a result value. But it abuses 'for' to mean 'if'. I
fee
Back to the topic, I tend to do this:
for record in Model.objects.filter(pk=42):
return record
return sentinel
Having lots of short methods helps, because return provides both
control-flow and a result value. But it abuses 'for' to mean 'if'. I
feel _rally_ guilty about that!
But I
On Tue, Sep 7, 2010 at 6:56 AM, Bruno Desthuilliers
wrote:
> Phlip a écrit :
>>>
>>> How does that compare to, say, the "Kamikaze Principle"? ;)
>>
>> Return victorious AND not at all!
>>
>> (All return values are packed up and thrown...;)
>
> ... and then it raises a SystemError !-)
general prot
Phlip a écrit :
How does that compare to, say, the "Kamikaze Principle"? ;)
Return victorious AND not at all!
(All return values are packed up and thrown...;)
... and then it raises a SystemError !-)
--
http://mail.python.org/mailman/listinfo/python-list
> How does that compare to, say, the "Kamikaze Principle"? ;)
Return victorious AND not at all!
(All return values are packed up and thrown...;)
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 2010-09-06 at 20:48 -0700, Phlip wrote:
> Pythonistas:
>
> The "Samurai Principle" says to return victorious, or not at all. This
> is why django.db wisely throws an exception, instead of simply
> returning None, if it encounters a "record not found".
How does that compare to, say, the "K
38 matches
Mail list logo
