Steven D'Aprano wrote:
On Sun, 26 Dec 2010 09:15:32 -0800, Ethan Furman wrote:
Steven D'Aprano wrote:
Right. But I have thought of a clever trick to get the result KJ was
asking for, with the minimum of boilerplate code. Instead of this:
def _pre_spam(args):
if condition(args):
On Dec 25, 2:49 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
But that's a separate issue from what is being discussed here. What we're
discussing here is the idea that a function should be able to delegate
work to private subroutines without the caller being aware of that
On Dec 25, 6:21 am, Robert Kern robert.k...@gmail.com wrote:
On 12/24/10 4:24 AM, Steven D'Aprano wrote:
On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
OTOH, going the extra mile to hide useful information from a user is
asinine. As a user, I will decide for myself how I want to use
Carl Banks wrote:
Python is not, and never has been, about hiding internal details.
It's about openness, and there's no reason a traceback should hide
internal details any more than a class should--in fact hiding
information in the traceback is far worse, because you're suppressing
information
Steven D'Aprano wrote:
On Sat, 25 Dec 2010 09:17:27 -0500, Robert Kern wrote:
On 12/24/10 5:14 PM, Ethan Furman wrote:
There are also times when I change the exception being raised to match
what python expects from that type of object -- for example, from
WhatEverException to KeyError for a
Steven D'Aprano wrote:
Right. But I have thought of a clever trick to get the result KJ was
asking for, with the minimum of boilerplate code. Instead of this:
def _pre_spam(args):
if condition(args):
raise SomeException(message)
if another_condition(args):
raise
In mailman.280.1293287106.6505.python-l...@python Robert Kern
robert.k...@gmail.com writes:
Except that the *caller* never gets the traceback (unless if it deliberately
inspects the stack for some metaprogramming reason). It gets the exception,
and
that is the same no matter what you do. The
In mailman.301.1293383804.6505.python-l...@python.org Ethan Furman
et...@stoneleaf.us writes:
You failed to mention that cleverness is not a prime requisite of the
python programmer -- in fact, it's usually frowned upon.
That's the party line, anyway. I no longer believe it. I've been
On 12/25/2010 2:50 PM, Steven D'Aprano wrote:
On Fri, 24 Dec 2010 10:51:32 -0800, John Nagle wrote:
On 12/24/2010 3:24 AM, Carl Banks wrote:
On Dec 24, 1:24 am, Steven D'Apranosteve
+comp.lang.pyt...@pearwood.info wrote:
All I'm
suggesting is that there should be a way of reducing the
On 12/26/2010 2:14 PM, kj wrote:
In mailman.301.1293383804.6505.python-l...@python.org Ethan Furman
et...@stoneleaf.us writes:
You failed to mention that cleverness is not a prime requisite of the
python programmer -- in fact, it's usually frowned upon.
That's the party line, anyway. I
On Dec 23, 3:22 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
You seem to have completely missed that there will be no bug report,
because this isn't a bug. (Or if it is a bug, the bug is elsewhere,
external to the function that raises the exception.) It is part of the
On Dec 26, 11:09 am, kj no.em...@please.post wrote:
In mailman.280.1293287106.6505.python-l...@python Robert Kern
robert.k...@gmail.com writes:
Except that the *caller* never gets the traceback (unless if it deliberately
inspects the stack for some metaprogramming reason). It gets the
On Dec 25, 2:49 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Sat, 25 Dec 2010 09:17:27 -0500, Robert Kern wrote:
On 12/24/10 5:14 PM, Ethan Furman wrote:
There are also times when I change the exception being raised to match
what python expects from that type of
On Sun, 26 Dec 2010 09:15:32 -0800, Ethan Furman wrote:
Steven D'Aprano wrote:
Right. But I have thought of a clever trick to get the result KJ was
asking for, with the minimum of boilerplate code. Instead of this:
def _pre_spam(args):
if condition(args):
raise
On Sun, 26 Dec 2010 17:12:50 -0800, misno...@gmail.com wrote:
On Dec 23, 3:22 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
You seem to have completely missed that there will be no bug report,
because this isn't a bug. (Or if it is a bug, the bug is elsewhere,
external to
Steven D'Aprano wrote:
...
I think critics of my position have forgotten what it's like to learning
the language. One of the most valuable skills to learn is to *ignore
parts of the traceback* -- a skill that takes practice and familiarity
with the library or function in use. To those who
On 12/24/10 5:14 PM, Ethan Furman wrote:
There are also times when I change the exception being raised to match
what python expects from that type of object -- for example, from
WhatEverException to KeyError for a dict-like object. So in this regard I agree
with Steven.
Steven isn't arguing
On 12/24/10 4:24 AM, Steven D'Aprano wrote:
On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
OTOH, going the extra mile to hide useful information from a user is
asinine. As a user, I will decide for myself how I want to use
implementation-defined information, and I don't want the
On Sat, 25 Dec 2010 09:17:27 -0500, Robert Kern wrote:
On 12/24/10 5:14 PM, Ethan Furman wrote:
There are also times when I change the exception being raised to match
what python expects from that type of object -- for example, from
WhatEverException to KeyError for a dict-like object. So
On Fri, 24 Dec 2010 10:51:32 -0800, John Nagle wrote:
On 12/24/2010 3:24 AM, Carl Banks wrote:
On Dec 24, 1:24 am, Steven D'Apranosteve
+comp.lang.pyt...@pearwood.info wrote:
All I'm
suggesting is that there should be a way of reducing the boilerplate
needed for this idiom:
def
On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
Do you accept that, as a general principle, unhandled errors should be
reported as close as possible to where the error occurs? If your answer
to that is No, then where do you think unhandled errors should be
reported?
No, and where the
On Dec 24, 1:24 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
OTOH, going the extra mile to hide useful information from a user is
asinine. As a user, I will decide for myself how I want to use
implementation-defined
On 12/24/2010 3:24 AM, Carl Banks wrote:
On Dec 24, 1:24 am, Steven D'Apranosteve
+comp.lang.pyt...@pearwood.info wrote:
All I'm
suggesting is that there should be a way of reducing the boilerplate
needed for this idiom:
def _validate_arg(x):
if x == 'bad input': return False
Carl Banks wrote:
On Dec 24, 1:24 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 23 Dec 2010 22:38:05 -0800, Carl Banks wrote:
OTOH, going the extra mile to hide useful information from a user is
asinine. As a user, I will decide for myself how I want to use
On Dec 22, 7:22 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
There should be a mechanism for Python functions to distinguish between
unexpected exceptions (commonly known as bugs), which should be
reported as coming from wherever they come from, and documented, expected
On Thu, 23 Dec 2010 02:54:52 -0800, Carl Banks wrote:
On Dec 22, 7:22 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
There should be a mechanism for Python functions to distinguish between
unexpected exceptions (commonly known as bugs), which should be
reported as coming
On Dec 23, 8:55 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Thu, 23 Dec 2010 02:54:52 -0800, Carl Banks wrote:
On Dec 22, 7:22 pm, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
There should be a mechanism for Python functions to distinguish between
In mailman.65.1292517591.6505.python-l...@python.org Robert Kern
robert.k...@gmail.com writes:
Obfuscating the location that an exception gets raised prevents a lot of
debugging...
The Python interpreter does a lot of that obfuscation already, and I
find the resulting tracebacks more useful
On Dec 22, 8:52 am, kj no.em...@please.post wrote:
In mailman.65.1292517591.6505.python-l...@python.org Robert Kern
robert.k...@gmail.com writes:
Obfuscating the location that an exception gets raised prevents a lot of
debugging...
The Python interpreter does a lot of that obfuscation
In 1f47c36d-a509-4d05-ba79-62b4a534b...@j19g2000prh.googlegroups.com Carl
Banks pavlovevide...@gmail.com writes:
On Dec 22, 8:52=A0am, kj no.em...@please.post wrote:
In mailman.65.1292517591.6505.python-l...@python.org Robert Kern rober=
t.k...@gmail.com writes:
Obfuscating the location that
On Wed, 22 Dec 2010 13:53:20 -0800, Carl Banks wrote:
On Dec 22, 8:52 am, kj no.em...@please.post wrote:
In mailman.65.1292517591.6505.python-l...@python.org Robert Kern
robert.k...@gmail.com writes:
Obfuscating the location that an exception gets raised prevents a lot
of debugging...
The
On 12/16/10 6:33 PM, Steven D'Aprano wrote:
On Thu, 16 Dec 2010 10:39:34 -0600, Robert Kern wrote:
On 12/16/10 10:23 AM, Steven D'Aprano wrote:
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote:
Tim Arnold wrote:
Ethan Furmanet...@stoneleaf.us wrote in message
Tim Arnold wrote:
Ethan Furman et...@stoneleaf.us wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
The one thing I don't like about this strategy is that the tracebacks
of exceptions raised during the execution of __pre_spam include one
unwanted stack level
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote:
Tim Arnold wrote:
Ethan Furman et...@stoneleaf.us wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
The one thing I don't like about this strategy is that the tracebacks
of exceptions raised during the
On 12/16/10 10:23 AM, Steven D'Aprano wrote:
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote:
Tim Arnold wrote:
Ethan Furmanet...@stoneleaf.us wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
The one thing I don't like about this strategy is that
On Thu, 16 Dec 2010 10:39:34 -0600, Robert Kern wrote:
On 12/16/10 10:23 AM, Steven D'Aprano wrote:
On Thu, 16 Dec 2010 07:29:25 -0800, Ethan Furman wrote:
Tim Arnold wrote:
Ethan Furmanet...@stoneleaf.us wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
On Dec 15, 2:16 am, Steven D'Aprano steve
+comp.lang.pyt...@pearwood.info wrote:
On Tue, 14 Dec 2010 21:14:35 +, kj wrote:
Consider this code:
def spam(*args, **kwargs):
args, kwargs = __pre_spam(*args, **kwargs)
# args kwargs are OK: proceed
# ...
def
On 12/14/2010 6:31 PM, Ethan Furman wrote:
kj wrote:
The one thing I don't like about this strategy is that the tracebacks
of exceptions raised during the execution of __pre_spam include one
unwanted stack level (namely, the one corresponding to __pre_spam
itself).
__pre_spam should be
On 12/16/2010 7:33 PM, Steven D'Aprano wrote:
Python's exception system has to handle two different situations: buggy
code, and bad data. It's not even clear whether there is a general
distinction to be made between the two, but even if there's not a general
distinction, there's certainly a
On Tue, 14 Dec 2010 21:14:35 +, kj wrote:
Consider this code:
def spam(*args, **kwargs):
args, kwargs = __pre_spam(*args, **kwargs)
# args kwargs are OK: proceed
# ...
def __pre_spam(*args, **kwargs):
# validate args kwargs;
# return canonicalized
Ethan Furman et...@stoneleaf.us wrote in message
news:mailman.4.1292379995.6505.python-l...@python.org...
kj wrote:
The one thing I don't like about this strategy is that the tracebacks
of exceptions raised during the execution of __pre_spam include one
unwanted stack level (namely, the one
Consider this code:
def spam(*args, **kwargs):
args, kwargs = __pre_spam(*args, **kwargs)
# args kwargs are OK: proceed
# ...
def __pre_spam(*args, **kwargs):
# validate args kwargs;
# return canonicalized versions of args kwargs;
# on failure, raise some
kj wrote:
The one thing I don't like about this strategy is that the tracebacks
of exceptions raised during the execution of __pre_spam include one
unwanted stack level (namely, the one corresponding to __pre_spam
itself).
__pre_spam should be completely invisible and unobtrusive
I am unaware
43 matches
Mail list logo
