homepage

tkSimpleDialog.askstring allows empty input. The attached patch adds validation to the input to ensure it is not empty.

But what if the empty string is valid input? This change would be backward incompatible.
I think this should instead be a feature request for exposing _QueryDialog so that you can subclass it and provide your own getresult function.

What about adding a validatecommand option like on Tkinter.Entry?
For what I am trying to do it was sort of a kludge to validate the entry because an empty string was invalid, but in the interface design, it would have been "rude" to validate after the dialog closes and then keep popping up another tkSimpleDialog.askstring until the input is correct. It almost makes askstring useless because I can't validate on close.
That wouldn't break backwards compatibility would it?

Adding an option would also be a reasonable feature request, but I think exposing _QueryDialog would be a more general solution, since it would apply to more than just strings.
While not backward incompatible, either of these is a new feature and so can only go into 3.3.

I'm not sure if I misunderstood you, or you misunderstood me, but adding an option to the askstring dialog that would take a function handle would also allow you to use it for things other than strings (ints,etc.)
Tkinter Entry does this: you set the validatecommand option to a function handle that returns true or false to determine whether the input was valid.
I will try and code an example over the weekend.

A bit of both, I think. The current function is actually 'getvalue' and is responsible for retrieving the value, validating its type, and converting to that type (the current ones do both in the same operation). It feels to me like a cleaner interface to decouple retrieval and validation/conversion, so that the validation function gets passed a string and returns the desired type. But in that case, having the string dialog take the validation/coercion function makes the name of the askstring function just wrong.
So, I still think the cleaner API is to expose the class and let the application subclass to provide the validation function.

I think we have to reject this issue.
Adding generic validation make sense, but adding just permanent check for non-empty string is wrong.