Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > The Samurai Principle

Reply
Thread Tools

The Samurai Principle

 
 
Phlip
Guest
Posts: n/a
 
      09-08-2010
On Sep 7, 4:38*pm, Benjamin Kaplan <(E-Mail Removed)> 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 (the "keyword arguments") instead of naming the
variable after its intent. It should be 'params=', at least, to match
the URI standards.

I'm just sayin'...
 
Reply With Quote
 
 
 
 
Ian Kelly
Guest
Posts: n/a
 
      09-08-2010
On Tue, Sep 7, 2010 at 9:35 PM, Phlip <(E-Mail Removed)> 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 attempt to
regard it as actual data. This in turn results in hard-to-track bugs
elsewhere in the program, a fate much worse than an unhandled
exception. It's better to fail noisily than to fail silently.

> They are worse than GOTO.


This assertion is questionable at best. Exceptions are structured;
goto is unstructured, giving you much more rope to hang yourself with.
 
Reply With Quote
 
 
 
 
Ian Kelly
Guest
Posts: n/a
 
      09-08-2010
On Tue, Sep 7, 2010 at 9:38 PM, Phlip <(E-Mail Removed)> 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 result you were looking
> for, so it's not exceptional.


I consider it exceptional because it breaks the rule that
Model.objects.get(...) returns an instance of Model. If it can also
return None, then this needs to be checked for every time the method
is called, because None does not implement the Model interface and
will break if you try to use it like that. You're still doing
exception handling; you're just doing it with an if instead of a
try-except. I prefer to do exception handling in a block clearly
marked as an exception handler.

Out of curiosity, would you also regard the case where two matching
records are found instead of one as not exceptional? After all, it
could be the result you were looking for. What should QuerySet.get
return in that case, if it doesn't raise an exception?
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-08-2010
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-effect, since the
alternative would be a core dump (or worse, an incorrect program that
*doesn't* crash). This is a good thing!


--
Steven
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-08-2010
On Tue, 07 Sep 2010 20:38:14 -0700, Phlip wrote:

> On Sep 7, 5:51*pm, Terry Reedy <(E-Mail Removed)> 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,
>> Python is not for you.

>
> While I'm at it, I'm going to log into comp.lang.java.misc and explain
> to everyone why static typing is overkill, and implementation
> inheritance is good for you.
>
> 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 result you were looking
> for, so it's not exceptional.


I think you've misunderstood the meaning of "exception" if you think
that. It doesn't mean "error". Nor does it mean "rare". (Although, given
that exceptions in Python are expensive, one would hope they're not *too*
common.)

The unexceptional case of looking up a record is to find it. That, after
all, is the purpose of the lookup function -- to find the given record.
That's what it is designed to do, and anything else is considered
exceptional.

Whether the lookup function returns a special "not found" result, or
raises an exception, or sets some magic global error code somewhere, it's
still an exceptional case.


--
Steven
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      09-08-2010
On 2010-09-08, Steven D'Aprano <(E-Mail Removed)> 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. That is the effect of not trapping them at all.
However, you can trap them incorrectly -- which can result in
hard-to-track down problems.

The main example of this is a "bare except" clause that not only
catches and handles the "expected" exception but also catches (and
mishandles/ignores) an unexpected one.

> which is a side-effect I suppose. But it's an *intended* side-effect,
> since the alternative would be a core dump (or worse, an incorrect
> program that *doesn't* crash). This is a good thing!


--
Grant Edwards grant.b.edwards Yow! -- I have seen the
at FUN --
gmail.com
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-08-2010
On Wed, 08 Sep 2010 14:44:12 +0000, Grant Edwards wrote:

> On 2010-09-08, Steven D'Aprano <(E-Mail Removed)>
> 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. That is the effect of not trapping them at all. However,
> you can trap them incorrectly -- which can result in hard-to-track down
> problems.
>
> The main example of this is a "bare except" clause that not only catches
> and handles the "expected" exception but also catches (and
> mishandles/ignores) an unexpected one.


Ah, fair enough. That would be a false positive error -- catching too
much rather than too little.

Still, that's no better, or worse, than misinterpreting special error
codes that are returned by functions. The main error mode there is
catching too little -- people neglect to check the error code, and
therefore have buggy code:

p = some_string.find('#')
print some_string[]

And who hasn't done this more than once?

re.search(pattern, some_string).group()



--
Steven
 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      09-08-2010
On 2010-09-08, Steven D'Aprano <(E-Mail Removed)> wrote:
> On Wed, 08 Sep 2010 14:44:12 +0000, 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 hard-to-track down
>> problems.
>>
>> The main example of this is a "bare except" clause that not only catches
>> and handles the "expected" exception but also catches (and
>> mishandles/ignores) an unexpected one.

>
> Ah, fair enough. That would be a false positive error -- catching too
> much rather than too little.
>
> Still, that's no better, or worse, than misinterpreting special error
> codes that are returned by functions.


No, I didn't mean to imply that was the case. I agree with your
conclusion. I find it much easier to screw things up using the
"exceptional return value" method than the "exception raise" method.

--
Grant Edwards grant.b.edwards Yow! Psychoanalysis??
at I thought this was a nude
gmail.com rap session!!!
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      09-08-2010
Grant Edwards <(E-Mail Removed)> 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 languages have similar shortcomings and it's mostly in more
recent languages that the problem has really been recognized, and
addressed with features like option types.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      09-10-2010
In message <(E-Mail Removed)>, 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Scythe Samurai Z Silverstrand Front Page News 0 02-08-2006 04:29 AM
Re: [Ent] From "sword master" Nick Powell to the last Samurai Tom Cruise John Doe Computer Support 0 09-16-2003 03:49 PM
[Entertainment] The Last Samurai Dzuyen Computer Support 1 09-15-2003 03:12 PM
Re: [Infor.] The Last Samurai John Doe Computer Support 0 09-15-2003 03:08 PM
[Info.] Tom Cruise in The Last Samurai Dzuyen Computer Support 1 09-15-2003 09:06 AM



Advertisments