On 6/13/2014 11:44 AM, Saimadhav Heblikar wrote:
I would like the keyseq validator to be reviewed.
I will let Tal take first whack at the code.
The diff file:
https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-diff
A sample test runner file:
https://gist.github.com/sahutd/0a471db8138383fd73b2#file-test-keyseq-runner-py
Incomplete patches can be posted to the tracker, where Rietveld can be
used for review. Create a separate issue for 'Tk key-combination
validator.' Make it a dependency of the test_combination and key-entry
issues. If a function looks useful outside of Idle, we can propose
adding it to tkinter.
In its current form, it supports/has
modifiers = ['Shift', 'Control', 'Alt', 'Meta']
alpha_uppercase = ['A']
alpha_lowercase = ['a']
direction = ['Up',]
direction_key = ['Key-Up']
It supports validating combinations upto 4 in length.
Please test for the above set only. (It will extended easily to fully
represent the respective complete sets. The reason it cant be done
*now* is the due to how RE optionals are coded differently in my
patch. See CLEANUP below). I will also add remaining keys like
Backspace, Slash etc tomorrow.
# Cleanup:
If we decide to go ahead with RE validating keys as in the above patch,
0. I made the mistake of not coding RE optionals -> ((pat)|(pat)) same
for all sets. The result is that, extending the current key set is not
possible without making all RE optional patterns similar.(Read the
starting lines of is_valid_keyseq method).
1. There is a lot of places where refactoring can be done and
appropriate comment added.
2. I left the asserts as-is. They can be used in testing the validator
method itself.
3. The above patch still needs support for Backspace, slash etc to be
added. I decided to add, once I am sure we will use it.
4. I would like to know how it will affect Mac? What are system
specific differences? Please run the test-runner script on it and do
let me know.
---
My friend told that this thing can be done by "defining a grammar and
automata." I did read up about it, but found it hard to grasp
everything. Can you say whether it would be easier to solve it that
way than RE?
A regex (in the original form, without latter additions) defines a
regular grammar and gets translated to an automaton automatically. The
later additions make the languages parsed somewhere between regular
languages and context-free languages. The translated automata are more
complicated than the originals. So, if something can sensibly be done
with regex, and not something simpler, there unlikely to be any
advantage to writing the automaton by hand.
Does the Tk manual (at Active state, for instance) anywhere defined the
key-combination language that .bind() accepts? If not, we might have to
settle for a function with three possible answers: definitely ok,
unsure, and definitely not ok (mispelling such as 'Atl', suffix after
the key such as 'Key-a-Shift', repeated modifiers such as
'Alt-Alt-Key-x' (even if Tk would allow that), missing key such as
'Alt-Shift')
--
Terry Jan Reedy
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
