[Python-Dev] Review tool not detecting all changed files
Hi, We were working on IDLE related issue [1] , when I noticed that the review tool does not detect all affected files for the cfg-ext-34-2.diff patch uploaded by Terry Reedy. Version 1 of the same patch does not have this issue - the only difference between the two files being line endings and time stamps. Also see Terry Reedy's message in the same issue. [3] Could someone please let me know if this is normal behavior or not? [1] - http://bugs.python.org/issue3068 [2] - http://bugs.python.org/file36904/cfg-ext-34-2.diff [3] - http://bugs.python.org/issue3068#msg229315 -- Regards Saimadhav Heblikar ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] KeyConfig, KeyBinding and other related issues.
Hi, I would like the keyseq validator to be reviewed. 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 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? Regards On 13 June 2014 17:15, Saimadhav Heblikar saimadhavhebli...@gmail.com wrote: On 13 June 2014 16:58, Tal Einat talei...@gmail.com wrote: On Fri, Jun 13, 2014 at 2:22 PM, Saimadhav Heblikar saimadhavhebli...@gmail.com wrote: Just a heads up to both: I am writing a keyseq validator method. It currently works for over 800 permutations of ['Shift', 'Control', 'Alt', 'Meta', 'Key-a', 'Key-A', 'Up', 'Key-Up', 'a', 'A']. It works for permutations of length 2 and 3. Beyond that its not worth it IMO. I am currently trying to integrate it with test_configuration.py and catching permutations i missed out. I post this, so that we dont duplicate work. I hope it to be ready by the end of the day.(UTC +5.5) What is the method you are using? Regex. It is not something elegant. The permutations are coded in.(Not all 800+ obviously, but around 15-20 general ones.). The only advantage is it can be used without creating a new Tk instance. What do you mean by permutations? If you mean what I think, then I'm not sure I agree with 3 not being worth it. I've used keyboard bindings with more than 2 modifiers before, and we should certainly support this properly. I am sorry. I meant to write 3 modifier permutations. (i.eControl-Shift-Alt-Meta+Key-X is not covered. But Control-Shift-Alt-Key-X is.) -- Regards Saimadhav Heblikar -- Regards Saimadhav Heblikar ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Idle-dev] KeyConfig, KeyBinding and other related issues.
Apologies for the accidental cross post. I intended to send it to idle-dev. I am sorry again :( On 13 June 2014 20:11, Saimadhav Heblikar saimadhavhebli...@gmail.com wrote: Hi, I would like the keyseq validator to be reviewed. 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 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? Regards On 13 June 2014 17:15, Saimadhav Heblikar saimadhavhebli...@gmail.com wrote: On 13 June 2014 16:58, Tal Einat talei...@gmail.com wrote: On Fri, Jun 13, 2014 at 2:22 PM, Saimadhav Heblikar saimadhavhebli...@gmail.com wrote: Just a heads up to both: I am writing a keyseq validator method. It currently works for over 800 permutations of ['Shift', 'Control', 'Alt', 'Meta', 'Key-a', 'Key-A', 'Up', 'Key-Up', 'a', 'A']. It works for permutations of length 2 and 3. Beyond that its not worth it IMO. I am currently trying to integrate it with test_configuration.py and catching permutations i missed out. I post this, so that we dont duplicate work. I hope it to be ready by the end of the day.(UTC +5.5) What is the method you are using? Regex. It is not something elegant. The permutations are coded in.(Not all 800+ obviously, but around 15-20 general ones.). The only advantage is it can be used without creating a new Tk instance. What do you mean by permutations? If you mean what I think, then I'm not sure I agree with 3 not being worth it. I've used keyboard bindings with more than 2 modifiers before, and we should certainly support this properly. I am sorry. I meant to write 3 modifier permutations. (i.eControl-Shift-Alt-Meta+Key-X is not covered. But Control-Shift-Alt-Key-X is.) -- Regards Saimadhav Heblikar -- Regards Saimadhav Heblikar -- Regards Saimadhav Heblikar ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GSOC 2014 - IDLE Project
Hi, Saimadhav Heblikar here.I would like to express my interest in working on IDLE improvement project as a part of Google Summer of Code 2014 for Python Core projects under the Python Software Foundation.I am currently a freshman Computer Science undergraduate student at PESIT , Bangalore. Similar to most Python programmers, i started my python journey on IDLE,and once i came to know that IDLE was one of the prospective projects,i knew this was great opportunity to give back to IDLE and the community as whole. I have created an account on the bug tracker and submitted the PSF contributor agreement.My username on the tracker is sahutd(saimadhav heblikar) http://bugs.python.org/user18939. I use the same nickname on the IRC channel. To enhance my understanding of the codebase, i have submitted few patches, some which have been committed http://bugs.python.org/issue20634 http://bugs.python.org/issue20677 and some which are under review http://bugs.python.org/issue20403 (IDLE related) http://bugs.python.org/issue20640 (Adds IDLE unittest) http://bugs.python.org/issue20451 http://bugs.python.org/issue20466 -- Coming to the point,as the theme of the project which i am interested in and the theme for the IDLE GSOC `13 projects by Jayakrishnan and Phil Webster are the same, i have a few questions to ask the python mentors/devs. 1.What will be the scope of the idle gsoc 2014?By scope,i want to know,whether i will be expected to continue the work done in 2013, or start afresh. 2. If i were to start afresh,i have explored the following two possibilities, a)Code recommender feature for IDLE - Similar to the feature in Eclipse but made for Python(would work from the shell or in IDLE).As an example of how it would work,we could think of it as a web api, which would return information about most used functions in a module.It would help beginners and experts alike to make better use of their dev time.It would also go a long way in making python even more social.If any questions on this proposal,i am looking forward to answer it. (I would like to know the community's opinion on this,GSOC or otherwise)If this generates a positive response, i will immediately come up with a plan to develop it. b)Working on a project to integrate a passive checker like pyflakes with the ability to highlight and possibly correct errors on-the-fly and on demand.Automatically integrate the above feature to work on folders/directories, selection of files ,projects etc. 2.If i were to continue the work done in gsoc 2013,would it involve a)building on features for PEP8(or other style checker,though after reading http://bugs.python.org/issue18704 i am inclined to believe it is not a must have atm. ) b)extending the unittest framework. Would i be completing(or to an extent) , the missing tests in idlelib/idle_test?What would be the priorities? c)features which don't seem to have been completed from gsoc 2013 like line numbering,improving cursor behavior and making right click more intuitive.(Anything gsoc 13 related which i have missed out?) -- I believe from the abstracts of GSOC 13 projects which were selected,that , i am expected to increase test coverage for idle AND add a new feature . Is my understanding correct? I would like to know whom i can contact(mentors) if have questions about the proposal writing and/or other technical questions relating to GSOC 14. I would also like to come up with overall outline based on your feedback so that it can critiqued before i submit the application on the google page. Awaiting your replies. Saimadhav Heblikar(sahutd) Bug Tracker username: sahutd (http://bugs.python.org/user18939) Email : saimadhavhebli...@gmail.com Github : https://github.com/sahutd ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: GSOC 2014 - IDLE Project
Hi, Saimadhav Heblikar here.I would like to express my interest in working on IDLE improvement project as a part of Google Summer of Code 2014 for Python Core projects under the Python Software Foundation.I am currently a freshman Computer Science undergraduate student at PESIT , Bangalore. Similar to most Python programmers, i started my python journey on IDLE,and once i came to know that IDLE was one of the prospective projects,i knew this was great opportunity to give back to IDLE and the community as whole. I have created an account on the bug tracker and submitted the PSF contributor agreement.My username on the tracker is sahutd(saimadhav heblikar) http://bugs.python.org/user18939. I use the same nickname on the IRC channel. To enhance my understanding of the codebase, i have submitted few patches, some which have been committed http://bugs.python.org/issue20634 http://bugs.python.org/issue20677 and some which are under review http://bugs.python.org/issue20403 (IDLE related) http://bugs.python.org/issue20640 (Adds IDLE unittest) http://bugs.python.org/issue20451 http://bugs.python.org/issue20466 -- Coming to the point,as the theme of the project which i am interested in and the theme for the IDLE GSOC `13 projects by Jayakrishnan and Phil Webster are the same, i have a few questions to ask the python mentors/devs. 1.What will be the scope of the idle gsoc 2014?By scope,i want to know,whether i will be expected to continue the work done in 2013, or start afresh. 2. If i were to start afresh,i have explored the following two possibilities, a)Code recommender feature for IDLE - Similar to the feature in Eclipse but made for Python(would work from the shell or in IDLE).As an example of how it would work,we could think of it as a web api, which would return information about most used functions in a module.It would help beginners and experts alike to make better use of their dev time.It would also go a long way in making python even more social.If any questions on this proposal,i am looking forward to answer it. (I would like to know the community's opinion on this,GSOC or otherwise)If this generates a positive response, i will immediately come up with a plan to develop it. b)Working on a project to integrate a passive checker like pyflakes with the ability to highlight and possibly correct errors on-the-fly and on demand.Automatically integrate the above feature to work on folders/directories, selection of files ,projects etc. 2.If i were to continue the work done in gsoc 2013,would it involve a)building on features for PEP8(or other style checker,though after reading http://bugs.python.org/issue18704 i am inclined to believe it is not a must have atm. ) b)extending the unittest framework. Would i be completing(or to an extent) , the missing tests in idlelib/idle_test?What would be the priorities? c)features which don't seem to have been completed from gsoc 2013 like line numbering,improving cursor behavior and making right click more intuitive.(Anything gsoc 13 related which i have missed out?) -- I believe from the abstracts of GSOC 13 projects which were selected,that , i am expected to increase test coverage for idle AND add a new feature . Is my understanding correct? I would like to know whom i can contact(mentors) if have questions about the proposal writing and/or other technical questions relating to GSOC 14. I would also like to come up with overall outline based on your feedback so that it can critiqued before i submit the application on the google page. Awaiting your replies. Saimadhav Heblikar(sahutd) Bug Tracker username: sahutd (http://bugs.python.org/user18939) Email : saimadhavhebli...@gmail.com Github : https://github.com/sahutd ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
