Lie Ryan schreef:
> On 1/7/2010 10:43 PM, Roel Schroeven wrote:
>> - I tend to think that not following that practice trains me to be
>> careful in all cases, whereas I'm afraid that following the practice
>> will make me careless, which is dangerous in all the cases where the
>> practice won't pro
Lie Ryan wrote:
That's a sign of a gotcha... a well-designed language makes you think
about your problem at hand and less about the language's syntax.
Not until you learn the language that is.
From a Python newbee ;-)
--
http://mail.python.org/mailman/listinfo/python-list
On 1/7/2010 10:43 PM, Roel Schroeven wrote:
- I tend to think that not following that practice trains me to be
careful in all cases, whereas I'm afraid that following the practice
will make me careless, which is dangerous in all the cases where the
practice won't protect me.
That's a sign of a
Bruno Desthuilliers schreef:
> Phlip a écrit :
>> On Jan 5, 8:49 pm, Steven D'Aprano
>> wrote:
>>
(A related question - why can't I just go 'if record = method(): use
(record)'. Why extra lines just to trap and assign the variable before
using it?)
>>> Because that idiom is respons
Steve Holden writes:
> Brilliant. It takes a real whole human being to make an admission like
> that (or even to bother to question their own behavior sufficiently to
> bother re-reading the thread). I think a lot more of you for the
> admission.
Seconded.
--
\ “bash awk grep perl sed,
r0g wrote:
> r0g wrote:
>> Steven D'Aprano wrote:
>>> On Wed, 06 Jan 2010 23:58:21 +, r0g wrote:
>>>
Steven D'Aprano wrote:
> On Wed, 06 Jan 2010 22:46:33 +, r0g wrote:
>
>> Grant Edwards wrote:
>>> On 2010-01-06, r0g wrote:
See? Spoiling for an argument even now!
r0g wrote:
> Steven D'Aprano wrote:
>> On Wed, 06 Jan 2010 23:58:21 +, r0g wrote:
>>
>>> Steven D'Aprano wrote:
On Wed, 06 Jan 2010 22:46:33 +, r0g wrote:
> Grant Edwards wrote:
>> On 2010-01-06, r0g wrote:
>>> See? Spoiling for an argument even now! I never said you were
Steven D'Aprano wrote:
> On Wed, 06 Jan 2010 23:58:21 +, r0g wrote:
>
>> Steven D'Aprano wrote:
>>> On Wed, 06 Jan 2010 22:46:33 +, r0g wrote:
>>>
Grant Edwards wrote:
> On 2010-01-06, r0g wrote:
>> See? Spoiling for an argument even now! I never said you weren't allowed
>> to bu
On Wed, 06 Jan 2010 23:58:21 +, r0g wrote:
> Steven D'Aprano wrote:
>> On Wed, 06 Jan 2010 22:46:33 +, r0g wrote:
>>
>>> Grant Edwards wrote:
On 2010-01-06, r0g wrote:
> NO! It's a rude way to start a sentence don't you think?
No. When somebody asks a yes/no question,
Steven D'Aprano wrote:
> On Wed, 06 Jan 2010 22:46:33 +, r0g wrote:
>
>> Grant Edwards wrote:
>>> On 2010-01-06, r0g wrote:
>>>
NO! It's a rude way to start a sentence don't you think?
>>> No. When somebody asks a yes/no question, answering yes or no seems
>>> quite polite to me. Follo
Grant Edwards writes:
> Answering a yes/no question with "no" doesn't seem to me to be
> combative if the correct answer is indeed "no". But I've lost
> track of the post you found objectionable...
In fairness, the “No” was in response, not to an explicit question, but
to an assertion.
Every a
On Wed, 06 Jan 2010 22:46:33 +, r0g wrote:
> Grant Edwards wrote:
>> On 2010-01-06, r0g wrote:
>>
>>> NO! It's a rude way to start a sentence don't you think?
>>
>> No. When somebody asks a yes/no question, answering yes or no seems
>> quite polite to me. Following the yes/no answer with
Grant Edwards wrote:
> On 2010-01-06, r0g wrote:
>
>> NO! It's a rude way to start a sentence don't you think?
>
> No. When somebody asks a yes/no question, answering yes or no
> seems quite polite to me. Following the yes/no answer with an
> explanation of the answer is always nice, and I've
Ben Finney wrote:
> r0g writes:
>
>> NO! It's a rude way to start a sentence don't you think?
>
> Shouting is usually rude, yes.
>
>> Just because you're correcting someone doesn't mean you have to be
>> combative and try and make them feel small.
>
> Again, you're reading something that isn't
On Jan 5, 9:44 am, Steven D'Aprano wrote:
>
> I'm glad we agree on that, but I wonder why you previously emphasised
> machine efficiency so much, and correctness almost not at all, in your
> previous post?
Uh… Because the original poster quoted one small paragraph out of a
large article and that
Phlip wrote:
> On Jan 6, 10:23 am, Lie Ryan wrote:
>> On 1/7/2010 3:41 AM, Phlip wrote:
>>
>>> Steve Holden wrote:
y'all just keep defending the approach to programming that
*you* think is best.
>>> Speak for yourself...
>> Everyone speaks for themselves, is that a problem?
>
> Of cours
On Wed, 06 Jan 2010 12:39:36 -0800, Phlip wrote:
> And now, if everyone will excuse me, I have to get back to writing a
> unit-test-to-code ratio of 2:1.
In my experience, that's about half as many unit-tests as needed for full
code coverage for even a simple class. If you're trying to impress u
On 1/6/2010 1:20 PM, Lie Ryan wrote:
Python decided that the default behavior should be raising exception and
sentinel have to use the dict.get() method. Simple and clear. The other
possible behavior (i.e. slicing returns a sentinel while dict.get()
raises an exception) is arguably just as simpl
On Jan 6, 10:23 am, Lie Ryan wrote:
> On 1/7/2010 3:41 AM, Phlip wrote:
>
> > Steve Holden wrote:
>
> >> y'all just keep defending the approach to programming that
> >> *you* think is best.
>
> > Speak for yourself...
>
> Everyone speaks for themselves, is that a problem?
Of course not. I was poi
On 2010-01-06, Lie Ryan wrote:
> On 1/7/2010 3:41 AM, Phlip wrote:
>> Steve Holden wrote:
>>
>>> y'all just keep defending the approach to programming that
>>> *you* think is best.
>>
>> Speak for yourself...
>
> Everyone speaks for themselves, [...]
Except for the Lorax. He speaks for the trees
On 1/7/2010 3:41 AM, Phlip wrote:
Steve Holden wrote:
y'all just keep defending the approach to programming that
*you* think is best.
Speak for yourself...
Everyone speaks for themselves, is that a problem?
--
http://mail.python.org/mailman/listinfo/python-list
On 1/7/2010 2:12 AM, Phlip wrote:
On Jan 5, 10:54 pm, Benjamin Kaplan wrote:
{41: None}[41] ?
In cases where None is a valid result, you can't use it to signal failure..
Asked and answered. You change the "sentinel" in .fetch to something
else.
I believe Ben Kaplan's point is that if dict
Steve Holden wrote:
y'all just keep defending the approach to programming that
*you* think is best.
Speak for yourself...
--
http://mail.python.org/mailman/listinfo/python-list
On 1/6/10 10:12 AM, Phlip wrote:
On Jan 5, 10:54 pm, Benjamin Kaplan wrote:
{41: None}[41] ?
In cases where None is a valid result, you can't use it to signal failure.
Asked and answered. You change the "sentinel" in .fetch to something
else.
When did I specify a sentinel value
Phlip a écrit :
On Jan 5, 8:49 pm, Steven D'Aprano
wrote:
(A related question - why can't I just go 'if record = method(): use
(record)'. Why extra lines just to trap and assign the variable before
using it?)
Because that idiom is responsible for probably the most common error in C
of all, a
Phlip wrote:
> On Jan 5, 8:49 pm, Steven D'Aprano
> wrote:
>
>>> (A related question - why can't I just go 'if record = method(): use
>>> (record)'. Why extra lines just to trap and assign the variable before
>>> using it?)
>> Because that idiom is responsible for probably the most common error
On 2010-01-06, r0g wrote:
> NO! It's a rude way to start a sentence don't you think?
No. When somebody asks a yes/no question, answering yes or no
seems quite polite to me. Following the yes/no answer with an
explanation of the answer is always nice, and I've little doubt
that's what happened.
Phlip wrote:
[...]
> Don't prevent me from using a technique just because others had
> trouble with it.
>
I presume you also campaign against anti-lock braking systems (or at
least don't use cars which have them - after all, anyone who knows how
to drive should be able to brake properly, right? An
On Jan 5, 10:54 pm, Benjamin Kaplan wrote:
> {41: None}[41] ?
>
> In cases where None is a valid result, you can't use it to signal failure.
Asked and answered. You change the "sentinel" in .fetch to something
else.
But y'all keep on defending the language making your programming
decisions for
On Jan 5, 8:49 pm, Steven D'Aprano
wrote:
> > (A related question - why can't I just go 'if record = method(): use
> > (record)'. Why extra lines just to trap and assign the variable before
> > using it?)
>
> Because that idiom is responsible for probably the most common error in C
> of all, at
r0g writes:
> NO! It's a rude way to start a sentence don't you think?
Shouting is usually rude, yes.
> Just because you're correcting someone doesn't mean you have to be
> combative and try and make them feel small.
Again, you're reading something that isn't there. I utterly deny the
motives
On Tue, Jan 5, 2010 at 8:45 PM, Phlip wrote:
>
> Here's a super easy example:
>
> { 42: 'forty two' }.get(41, None)
>
> Because I can supply a default, I can decide what is an error and what
> is .
>
> Now the equivalent in a language that does not enjoy this false "Zen":
>
> { 42: 'forty two' }
On Tue, 05 Jan 2010 17:45:58 -0800, Phlip wrote:
> On Jan 5, 5:01 pm, Chris Rebert wrote:
>
>> > Why can't int('nonnumeric') return None?
>>
>> Errors should never pass silently.
>
> You are saying I, as the programmer, cannot decide what is an error and
> what is a pass-thru. The decision is m
On Tue, 05 Jan 2010 15:51:29 -0800, Phlip wrote:
> Why can't int('nonnumeric') return None?
It could do that, but it shouldn't, because returning magic values
instead of raising exceptions is usually a bad, bad idea.
> (A related question - why can't I just go 'if record = method(): use
> (rec
On Wed, 06 Jan 2010 00:58:58 +, r0g wrote:
> Steven D'Aprano wrote:
>> On Wed, 06 Jan 2010 09:39:08 +1100, Ben Finney wrote:
>>
>>> r0g writes:
>>>
Of course I'm now guilty of pedantry too :/ I might have let it slip
had you not started your reply with the word "No", that just p***
On Tue, Jan 5, 2010 at 5:45 PM, Phlip wrote:
> On Jan 5, 5:01 pm, Chris Rebert wrote:
>> > Why can't int('nonnumeric') return None?
>>
>> Errors should never pass silently.
>
> You are saying I, as the programmer, cannot decide what is an error
> and what is a pass-thru. The decision is made for
> Errors should never pass silently.
> Unless explicitly silenced.
> -- The Zen of Python (http://www.python.org/dev/peps/pep-0020/)
"The person who says it cannot be done should never interrupt the
person doing it"
--
http://mail.python.org/mailman/listinfo/python-list
On Jan 5, 5:01 pm, Chris Rebert wrote:
> > Why can't int('nonnumeric') return None?
>
> Errors should never pass silently.
You are saying I, as the programmer, cannot decide what is an error
and what is a pass-thru. The decision is made for me. (Yes yes I can
write int_or_None(), etc...)
Here's
Lie Ryan wrote:
> On 1/6/2010 1:48 AM, r0g wrote:
>> Steven D'Aprano wrote:
>>> On Tue, 05 Jan 2010 13:06:20 +, r0g wrote:
If
that's the case how can you expect it to validate anything at all in
production?
>>>
>>> The asserts still operate so long as you don't use the -O switch.
On Tue, Jan 5, 2010 at 3:51 PM, Phlip wrote:
> Peng Yu wrote:
>> Otherwise, could some python expert explain to me why exception is
>> widely used for error handling in python? Is it because the efficiency
>> is not the primary goal of python?
>
> It's not about efficiency, it's about making assum
Steven D'Aprano wrote:
> On Wed, 06 Jan 2010 09:39:08 +1100, Ben Finney wrote:
>
>> r0g writes:
>>
>>> Of course I'm now guilty of pedantry too :/ I might have let it slip
>>> had you not started your reply with the word "No", that just p* me
>>> off.
>> Well, if being told “no” is going to p
Peng Yu wrote:
> Otherwise, could some python expert explain to me why exception is
> widely used for error handling in python? Is it because the efficiency
> is not the primary goal of python?
It's not about efficiency, it's about making assumptions for the
programmer about what kind of rigor th
On Wed, 06 Jan 2010 09:39:08 +1100, Ben Finney wrote:
> r0g writes:
>
>> Of course I'm now guilty of pedantry too :/ I might have let it slip
>> had you not started your reply with the word "No", that just p* me
>> off.
>
> Well, if being told “no” is going to piss you off, I think you're i
r0g writes:
> Of course I'm now guilty of pedantry too :/ I might have let it slip
> had you not started your reply with the word "No", that just p* me
> off.
Well, if being told “no” is going to piss you off, I think you're in for
a rough time.
> Having said that I find the mental image of
D'Arcy J.M. Cain wrote:
> On 05 Jan 2010 14:02:50 GMT
> Steven D'Aprano wrote:
>> shouldn't use assert for validating user data except for quick-and-dirty
>> scripts you intend to use once and throw away.
>
> A mythcial beast that has yet to be spotted in the wild.
>
Not true (he wrote, picking
On 1/6/2010 1:48 AM, r0g wrote:
Steven D'Aprano wrote:
On Tue, 05 Jan 2010 13:06:20 +, r0g wrote:
If
that's the case how can you expect it to validate anything at all in
production?
The asserts still operate so long as you don't use the -O switch.
Do you mean for debugging in situ or so
r0g wrote:
Dave Angel wrote:
r0g wrote:
Maybe, although I recently learned on here that one can't rely on assert
statements in production code, their intended use is to aid debugging
and testing really.
Hopefully, what you learned is that you can't use assert() in product
Steven D'Aprano wrote:
> On Tue, 05 Jan 2010 13:06:20 +, r0g wrote:
>> Well maybe I didn't quite get it then, could you explain a bit further?
>>
>> My understanding was that asserts aren't executed at all if python is
>> started with the -O or -OO option,
>
> Correct.
>
>
>> or run throug
Ben Finney wrote:
> r0g writes:
>
>> Paul Rudin wrote:
>>> Doesn't python just return a single result? (I know it can be a
>>> tuple and assignment statements will unpack a tuple for you.)
>> Yes, it returns a tuple if you return more than one value, it just has
>> a lovely syntax for it.
>
> No
On 05 Jan 2010 14:02:50 GMT
Steven D'Aprano wrote:
> shouldn't use assert for validating user data except for quick-and-dirty
> scripts you intend to use once and throw away.
A mythcial beast that has yet to be spotted in the wild.
--
D'Arcy J.M. Cain | Democracy is three wolves
http
On Tue, 05 Jan 2010 13:06:20 +, r0g wrote:
> Dave Angel wrote:
>>
>>
>> r0g wrote:
>>>
>>>
>>> Maybe, although I recently learned on here that one can't rely on
>>> assert
>>> statements in production code, their intended use is to aid debugging
>>> and testing really.
>>>
>>>
>> Hopefully
In article ,
r0g wrote:
> No, but that's why I try not to use languages where you can only return
> a single result, I always found that an arbitrary and annoying
> constraint to have. I leads to ugly practices like "magic" return values
> in C or explicitly packing things into hashtables like
Dave Angel wrote:
>
>
> r0g wrote:
>>
>>
>> Maybe, although I recently learned on here that one can't rely on assert
>> statements in production code, their intended use is to aid debugging
>> and testing really.
>>
>>
> Hopefully, what you learned is that you can't use assert() in productio
r0g writes:
> Paul Rudin wrote:
> > Doesn't python just return a single result? (I know it can be a
> > tuple and assignment statements will unpack a tuple for you.)
>
> Yes, it returns a tuple if you return more than one value, it just has
> a lovely syntax for it.
No, there is nothing inherent
r0g wrote:
Maybe, although I recently learned on here that one can't rely on assert
statements in production code, their intended use is to aid debugging
and testing really.
Hopefully, what you learned is that you can't use assert() in production
code to validate user data. It's fine t
Paul Rudin wrote:
> r0g writes:
>
>> Steven D'Aprano wrote:
>>> On Tue, 05 Jan 2010 02:31:34 +, r0g wrote:
>>>
A pattern I have used a few times is that of returning an explicit
success/failure code alongside whatever the function normally returns.
>>> That doesn't work for language
Chris Rebert wrote:
>
> On Tue, Jan 5, 2010 at 1:07 AM, r0g wrote:
>> Lie Ryan wrote:
>>> I have been looking at Haskell recently and the way the pure functional
>>> language handled exceptions and I/O gives me a new distinct "insight"
>>> that exceptions can be thought of as a special return val
r0g writes:
> Steven D'Aprano wrote:
>> On Tue, 05 Jan 2010 02:31:34 +, r0g wrote:
>>
>>> A pattern I have used a few times is that of returning an explicit
>>> success/failure code alongside whatever the function normally returns.
>>
>> That doesn't work for languages that can only return
Steven D'Aprano wrote:
> On Tue, 05 Jan 2010 02:31:34 +, r0g wrote:
>
>> A pattern I have used a few times is that of returning an explicit
>> success/failure code alongside whatever the function normally returns.
>
> That doesn't work for languages that can only return a single result,
> e.
On Tue, Jan 5, 2010 at 1:07 AM, r0g wrote:
> Lie Ryan wrote:
>> I have been looking at Haskell recently and the way the pure functional
>> language handled exceptions and I/O gives me a new distinct "insight"
>> that exceptions can be thought of as a special return value that is
>> implicitly wra
Lie Ryan wrote:
> On 1/5/2010 1:31 PM, r0g wrote:
>> Michi wrote:
>>> On Jan 4, 1:30 pm, Steven D'Aprano
>>> wrote:
>> A pattern I have used a few times is that of returning an explicit
>> success/failure code alongside whatever the function normally returns.
>> While subsequent programmers migh
On Tue, 05 Jan 2010 02:31:34 +, r0g wrote:
> A pattern I have used a few times is that of returning an explicit
> success/failure code alongside whatever the function normally returns.
That doesn't work for languages that can only return a single result,
e.g. C or Pascal. You can fake it by
On 1/5/2010 1:31 PM, r0g wrote:
Michi wrote:
On Jan 4, 1:30 pm, Steven D'Aprano
wrote:
In some, limited, cases you might be able to use the magic return value
strategy, but this invariably leads to lost programmer productivity, more
complex code, lowered readability and usability, and more
Michi wrote:
> On Jan 4, 1:30 pm, Steven D'Aprano
> wrote:
>> In some, limited, cases you might be able to use the magic return value
>> strategy, but this invariably leads to lost programmer productivity, more
>> complex code, lowered readability and usability, and more defects,
>> because progr
On Mon, 04 Jan 2010 13:34:34 -0800, Michi wrote:
> On Jan 4, 1:30 pm, Steven D'Aprano
> wrote:
>>
>> This is very true, but good APIs often trade-off increased usability
>> and reduced defect rate against machine efficiency too. In fact, I
>> would argue that this is a general design principle of
Michi wrote:
On Jan 4, 1:30 pm, Steven D'Aprano
wrote:
[snip]
* Is it appropriate to force the caller to deal with the condition in
a catch-handler?
* If the caller fails to explicitly deal with the condition, is it
appropriate to terminate the program?
Only if the answer to these questions
On Jan 4, 1:30 pm, Steven D'Aprano
wrote:
>
> This is very true, but good APIs often trade-off increased usability and
> reduced defect rate against machine efficiency too. In fact, I would
> argue that this is a general design principle of programming languages:
> since correctness and programmer
On Sun, 03 Jan 2010 22:36:44 -0500, Roy Smith wrote:
> In article ,
> Steven D'Aprano wrote:
>
>> This last one can be *very* problematic. In the early 1990s, I was
>> programming using a callback API that could only return an integer. The
>> standard way of indicating an error was to return -1
In article ,
Steven D'Aprano wrote:
> This last one can be *very* problematic. In the early 1990s, I was
> programming using a callback API that could only return an integer. The
> standard way of indicating an error was to return -1. But what happens if
> -1 is a legitimate return value, e.g
On Sun, 03 Jan 2010 13:44:29 -0800, Michi wrote:
> The quoted sentence appears in a section of the article that deals with
> efficiency. I point out in that section that bad APIs often have a price
> not just in terms of usability and defect rate, but that they are often
> inefficient as well.
T
Michi wrote:
On Jan 1, 2:47 pm, Peng Yu wrote:
In the article API Design Matters by Michi Henning
Communications of the ACM
Vol. 52 No. 5, Pages 46-56
10.1145/1506409.1506424http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
It says "Another popular design flaw—namely, thr
On Jan 1, 2:47 pm, Peng Yu wrote:
>
> In the article API Design Matters by Michi Henning
>
> Communications of the ACM
> Vol. 52 No. 5, Pages 46-56
> 10.1145/1506409.1506424http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext
>
> It says "Another popular design flaw—namely, throw
On 1/2/2010 10:04 AM, Peng Yu wrote:
For my own interest, I want understand the run time behavior of python
That depends on the implementation.
and what details causes it much slower.
A language feature that slows all implementation is the dynamic
name/slot binding and resolution. Any imp
> For my own interest, I want understand the run time behavior of python
> and what details causes it much slower. Although people choose python
> for its programming efficiency, but sometimes the runtime still
> matters. This is an important aspect of the language. I'm wondering
> this is not even
On Sat, Jan 2, 2010 at 6:05 AM, Diez B. Roggisch wrote:
> Peng Yu schrieb:
>>
>> On Thu, Dec 31, 2009 at 11:24 PM, Chris Rebert wrote:
>>>
>>> On Thu, Dec 31, 2009 at 8:47 PM, Peng Yu wrote:
I observe that python library primarily use exception for error
handling rather than use e
> I mentioned an "exception stack" above, though I'm not 100% sure if that is
> the proper term. I think that exceptions can be stacked upon each other
> (e.g. an HTTPD throwing a high-level RequestError when it encounters a low-
> level IOError) and that that is also how the backtrace is implem
Peng Yu schrieb:
On Thu, Dec 31, 2009 at 11:24 PM, Chris Rebert wrote:
On Thu, Dec 31, 2009 at 8:47 PM, Peng Yu wrote:
I observe that python library primarily use exception for error
handling rather than use error code.
In the article API Design Matters by Michi Henning
Communications of th
Peng Yu wrote:
> Could somebody let me know how the python calls and exceptions are
> dispatched? Is there a reference for it?
I'm not a Python expert, but I have read some parts of the implementation.
Hopefully someone steps up if I misrepresent things here...
In order to understand Python exce
On Fri, Jan 1, 2010 at 5:36 PM, Peng Yu wrote:
> >> Otherwise, could some python expert explain to me why exception is
> >> widely used for error handling in python? Is it because the efficiency
> >> is not the primary goal of python?
> >
> > Correct; programmer efficiency is a more important goa
In article <4b3dcfab.3030...@v.loewis.de>,
Martin v. Loewis wrote:
>
>Notice that in cases where the failure may be expected, Python
>also offers variants that avoid the exception:
>- if you look into a dictionary, expecting that a key may not
> be there, a regular access, d[k], may give a KeyErr
On Thu, Dec 31, 2009 at 11:24 PM, Chris Rebert wrote:
> On Thu, Dec 31, 2009 at 8:47 PM, Peng Yu wrote:
>> I observe that python library primarily use exception for error
>> handling rather than use error code.
>>
>> In the article API Design Matters by Michi Henning
>>
>> Communications of the A
> You do understand that exceptions aren't just for errors? They are raised
> under specific circumstances. Whether that circumstance is an error or
> not is entirely up to the caller.
I think that's a fairly narrow definition of the word error, and
probably also the source of confusion in this
On Fri, 01 Jan 2010 11:02:28 -0500, Benjamin Kaplan wrote:
> I was trying to point out that in
> Python, you don't test errors for your typical conditions, but for ones
> that you know still exist but don't plan on occurring often.
I'm sorry, but that makes no sense to me at all. I don't understa
Steven D'Aprano wrote:
> On Fri, 01 Jan 2010 02:43:21 -0800, Jonathan Gardner wrote:
>
>> On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote:
>>> In article ,
>>> Benjamin Kaplan wrote:
>>> >In Python, throwing exceptions for expected outcomes is considered
>>> >very bad form [...]
>>>
>>> W
On Fri, Jan 1, 2010 at 9:49 AM, Steven D'Aprano
wrote:
>
> Exceptions are *exceptional*, not "errors" or "unexpected". They are
> exceptional because they aren't the "normal" case, but that doesn't mean
> they are surprising or unexpected. Are you surprised that your "for x in
> range(1000)" loop
On 1/1/2010 3:47 PM, Peng Yu wrote:
I observe that python library primarily use exception for error
handling rather than use error code.
In the article API Design Matters by Michi Henning
Communications of the ACM
Vol. 52 No. 5, Pages 46-56
10.1145/1506409.1506424
http://cacm.acm.org/magazines/
On Fri, 01 Jan 2010 00:26:09 -0500, Benjamin Kaplan wrote:
> On Thu, Dec 31, 2009 at 11:47 PM, Peng Yu wrote:
>> I observe that python library primarily use exception for error
>> handling rather than use error code.
>>
>> In the article API Design Matters by Michi Henning
>>
>> Communications of
On Fri, 01 Jan 2010 02:43:21 -0800, Jonathan Gardner wrote:
> On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote:
>> In article ,
>> Benjamin Kaplan wrote:
>> >In Python, throwing exceptions for expected outcomes is considered
>> >very bad form [...]
>>
>> Who says that? I certainly don't.
>
On Fri, 01 Jan 2010 11:34:19 +0100 "Martin v. Loewis"
wrote:
> Your observation is not wrong, but, as Benjamin already explained,
> you are misinterpreting Michi Henning's statement. He doesn't condemn
> exception handling per se, but only for the handling of *expected*
> outcomes. He would consi
On Jan 1, 12:43 am, a...@pythoncraft.com (Aahz) wrote:
> In article ,
> Benjamin Kaplan wrote:
> >In Python, throwing exceptions for expected outcomes is considered
> >very bad form [...]
>
> Who says that? I certainly don't.
Agreed.
int("asdf") is supposed to return what, exactly? Any languag
Peng Yu wrote:
> I observe that python library primarily use exception for error
> handling rather than use error code.
[...]
> It says "Another popular design flaw—namely, throwing exceptions for
> expected outcomes—also causes inefficiencies because catching and
> handling exceptions is almost al
In article ,
Benjamin Kaplan wrote:
>
>In Python, throwing exceptions for expected outcomes is considered
>very bad form [...]
Who says that? I certainly don't.
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings
On Thu, 31 Dec 2009 20:47:49 -0800, Peng Yu wrote:
> I observe that python library primarily use exception for error handling
> rather than use error code.
>
> In the article API Design Matters by Michi Henning
>
> Communications of the ACM
> Vol. 52 No. 5, Pages 46-56
> 10.1145/1506409.1506424
On Thu, Dec 31, 2009 at 11:47 PM, Peng Yu wrote:
> I observe that python library primarily use exception for error
> handling rather than use error code.
>
> In the article API Design Matters by Michi Henning
>
> Communications of the ACM
> Vol. 52 No. 5, Pages 46-56
> 10.1145/1506409.1506424
> ht
On Thu, Dec 31, 2009 at 8:47 PM, Peng Yu wrote:
> I observe that python library primarily use exception for error
> handling rather than use error code.
>
> In the article API Design Matters by Michi Henning
>
> Communications of the ACM
> Vol. 52 No. 5, Pages 46-56
> 10.1145/1506409.1506424
> htt
I observe that python library primarily use exception for error
handling rather than use error code.
In the article API Design Matters by Michi Henning
Communications of the ACM
Vol. 52 No. 5, Pages 46-56
10.1145/1506409.1506424
http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fullte
96 matches
Mail list logo
