Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

The Samurai Principle

 
 
Tim Chase
Guest
Posts: n/a
 
      09-07-2010
On 09/07/10 13:53, Phlip wrote:
> On Sep 7, 11:36 am, Tim Chase<(E-Mail Removed)> 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) cases. E.g. iterators raising
>> StopException when exhausted.

>
> Exceptions are not "because we should only return one type of thing".
> They are for situations which the caller should care not to handle.
> Exceptions are for propagating. A "record not found" is an exemplary
> example of a situation the caller _should_ handle.


Um...first you state "Exceptions are for catastrophic errors that
the caller should not care to handle. A 'record not found' is not
a catastrophe" and then you contradictingly go on to state "A
'record not found' is an exemplary example of a situation the
caller _should_ handle". I'm not sure I follow your logic here.
Exceptions allow both (1) the ability to handle the exceptional
condition locally if you want to (including suppressing it) and
(2) propagate the exception if you want to make the caller handle it.

And if you really want, you can just subclass QuerySet to provide
your own get_or_none() method to return your sentinel.

>> items = list(MyModel.objects.filter(...))
>> if len(items) == 1:
>> do_something(items[0])
>> else:
>> what_the(...)

>
> Both your version and mine read an entire cursor. But mine only rezzed
> the first object, whereas yours rezzed every object in the cursor,
> just to throw most of them away!


If a .get() returns more than one object (non-unique criteria are
used), what _should_ it return? Agreed, if it pulls back a
bajillion records, that's bad, so if you're concerned your
conditions might do that despite the expectation they bring back
1-and-only-1 (.get() currently raises an exception if it brings
back more than one result db/models/query.py around line 342
where MultipleObjectsReturned is raised), then I'd just slice them:

items = list(MyModel.objects.filter(...)[:1])
if items:
do_something(items[0])
else:
what_the(...)

-tkc



 
Reply With Quote
 
 
 
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      09-07-2010
Phlip a écrit :
> On Sep 7, 10:12 am, Bruno Desthuilliers <bruno.
> (E-Mail Removed)> 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 newb
> who doesn't understanding it? F'em.


F'... newbies is definitly not the pythonic mindset. Python's mindset is
about doing the most obvious thing, no trying to be smart. The obvious
code here is:

try:
return Model.objects.get(pk=42)
except Model.DoesNotExist:
return sentinel

so yes, your above snippet is bordering on WTF since it's not immediatly
obvious - it takes at least one more second for me to parse, and I'm
definitly not a Python nor Django newbie. That's something I'd
immediatly rewrite if I had to work on this code.

> I would guess that Django provides some basic rules for avoiding name
> collisions.


yes : common sense.

> Nobody should call a field "pk__in"


Nope, but "default" - which would be the obvious keyword here - is also
a perfectly legitimate field name.

>> But if you feel like you found the correct name, you can of course
>> monkeypatch queryset !-)

>
> Know I gotta learn to add a new method to an existing class!


It's as straightforward as possible once you know Python's object model:

def somefunc(self, whatever):
self.do_something_with(whatever)

import somemodule
somemodule.SomeClass.mymethod = somefunc
 
Reply With Quote
 
 
 
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      09-07-2010
Phlip a écrit :
> On Sep 7, 10:36 am, Ian Kelly <(E-Mail Removed)> wrote:
>> On Tue, Sep 7, 2010 at 10:02 AM, Phlip <(E-Mail Removed)> 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.DoesNotExist:
>> return sentinel
>>
>> The flow of control is much clearer this way.

>
> It reminds me of Visual Basic.


Strange enough, your own code snippet reminds me of what I used to find
when fixing VB programs some ten years ago.

> And no it's not "much clearer".


It is for any Python programmer - it's even TheOneObviousWay.

> Exceptions are for catastrophic errors


Chapter and verse, please ?

Exceptions are for exceptional situations. When you call queryset.get,
you do expect to have one single instance matching the lookup - specialy
when doing a pk lookup.


> AAAND you need to test that the DoesNotExist occurs for the exact
> reason you expect.


Bullshit. The only reason you'd get this exception is because there's no
record matching your where clause.

> Your except is not complete.


Why so ?

> Making it complete is
> very hard, and will break as soon as the model changes.


Why so ?
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      09-07-2010
On Sep 7, 1:06*pm, Bruno Desthuilliers
<(E-Mail Removed)> 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 membership. It also could not
enumerate by key and value (which would be 'for k,v in dict.items()').
To test for membership, you _had_ to catch an exception - using VB's
tragically clumsy exception model.

Hours of fun. That leads us to this topic:

http://www.google.com/search?q=don't+use+exceptions+for+normal+control+f low
 
Reply With Quote
 
Benjamin Kaplan
Guest
Posts: n/a
 
      09-07-2010
On Tue, Sep 7, 2010 at 6:20 PM, Phlip <(E-Mail Removed)> wrote:
> On Sep 7, 1:06*pm, Bruno Desthuilliers
> <(E-Mail Removed)> 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 membership. It also could not
> enumerate by key and value (which would be 'for k,v in dict.items()').
> To test for membership, you _had_ to catch an exception - using VB's
> tragically clumsy exception model.
>
> Hours of fun. That leads us to this topic:
>
> http://www.google.com/search?q=don't+use+exceptions+for+normal+control+f low
> --



An experienced C programmer can program C in any language, but that
doesn't mean it's a good idea to.

When you're using a language, you should use the style that the
language emphasizes. While you shouldn't use exceptions for control
flow in C++, Java, or C#, there's nothing wrong with using them as
such in Python.
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      09-08-2010
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

 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      09-08-2010
In message
<(E-Mail Removed)>, 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".


Does catching the exception not defeat the “Samurai Principle”?
 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      09-08-2010
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
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      09-08-2010
On Sep 7, 6:23*pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> 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 worse than GOTO.
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      09-08-2010
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.
 
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