On 06/12/2012 08:49, Bruno Dupuis wrote:
On Thu, Dec 06, 2012 at 04:32:34AM +0000, Steven D'Aprano wrote:
On Thu, 06 Dec 2012 03:22:53 +0000, Rotwang wrote:
On 06/12/2012 00:19, Bruno Dupuis wrote:
[...]
Another advice: never ever
except XXXError:
pass
at least log, or count, or warn, or anything, but don't pass.
Really? I've used that kind of thing several times in my code. For
example, there's a point where I have a list of strings and I want to
create a list of those ints that are represented in string form in my
list, so I do this:
listofints = []
for k in listofstrings:
try:
listofints.append(int(k))
except ValueError:
pass
Another example: I have a dialog box with an entry field where the user
can specify a colour by entering a string, and a preview box showing the
colour. I want the preview to automatically update when the user has
finished entering a valid colour string, so whenever the entry field is
modified I call this:
def preview(*args):
try:
previewbox.config(bg = str(entryfield.get()))
except tk.TclError:
pass
Is there a problem with either of the above? If so, what should I do
instead?
They're fine.
Never, ever say that people should never, ever do something.
*cough*
Well, dependening on the context (who provides listofstrings?) I would
log or count errors on the first one... or not.
The actual reason for the first example is that I have a text widget
with a bunch of tags (which are identified by strings), and I want to
add a new tag whose name doesn't coincide with any of the existing tag
names. I achieve this by setting my listofstrings equal to the list of
existing tag names, and setting the new tag name as
str(max(listofints) + 1) if listofints else '0'
I realise that there are a bunch of other ways I could have done this.
But I haven't a clue how I could rewrite the second example without
using a try statement (other than by writing a function that would
recognise when a string defines a valid Tkinter colour, including the
long and possibly version-dependent list of colours with Zoolanderesque
names like 'LightSteelBlue3').
On the second one, I would split the expression, because (not sure of
that point, i didn't import tk for years) previewbox.config and
entryfield.get may raise a tk.TclError for different reasons.
The point is Exceptions are made for error handling, not for normal
workflow.
Although I'm something of a noob, I'm pretty sure the Python community
at large would disagree with this, as evidenced by the fact that 'EAFP'
is an entry in the official Python glossary:
EAFP
Easier to ask for forgiveness than permission. This common Python
coding style assumes the existence of valid keys or attributes and
catches exceptions if the assumption proves false. This clean and
fast style is characterized by the presence of many try and except
statements. The technique contrasts with the LBYL style common to
many other languages such as C.
(from http://docs.python.org/2/glossary.html)
--
I have made a thing that superficially resembles music:
http://soundcloud.com/eroneity/we-berated-our-own-crapiness
--
http://mail.python.org/mailman/listinfo/python-list
