Confused compare function :)

[Rotwang]

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