Confused compare function :)
sg552 at hotmail.co.uk
Thu Dec 6 20:24:04 CET 2012
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:
>>>> 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:
>>> except ValueError:
>>> 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):
>>> previewbox.config(bg = str(entryfield.get()))
>>> except tk.TclError:
>>> Is there a problem with either of the above? If so, what should I do
>> They're fine.
>> Never, ever say that people should never, ever do something.
> 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
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:
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.
I have made a thing that superficially resembles music:
More information about the Python-list