On 1/5/2015 7:24 AM, Chris Angelico wrote:
On Mon, Jan 5, 2015 at 8:34 PM, Jonas Wielicki <jo...@wielicki.name> wrote:
As a first iteration, I would try with any editor written in Python.
Are you familiar with the ast[1] module? It could be worth trying to
use this module and perform some kind of pattern matching on the
results to recover the information.
An AST parse throws away a lot of information. You can't easily
reconstruct the original code from that; at best, you can decompile
the AST back into functionally-equivalent source code, but it's not
something you want to do as part of editing code.
Chris is right. I looked at this and came up with the same conclusion.
Here's a use case that I haven't talked about yet but is part of the
problem of speech driven programming. I have a chunk of code that I
created that is exactly right but it's in the wrong place or wrong
method or even just the wrong environment. I need to capture it and then
move it to the right place.
At first glance, this would look like a simple cut-and-paste and,
sometimes it is but more often it's not. Let's take the example of a
simple file generator. Opening the file, iterating over the input until
the input data transformation process runs out of data.
This is a real common pattern and what changes are certain elements of
the code, variables, strings whatever but also the indentation. So
putting the old chunk of code into the new place requires transformation
that most of you guys do by hand without thinking twice. Me it's,
#()@!&#$, and I use a whole bunch of kill words to strip out the old
data and put in the new.
Imagine being able to rip out a piece of code, identify the substitution
points and the indentation adjustment levels and then being able to put
in that piece of code in other places and just fill in the blanks as a
part of the insertion dialogue. Now this gets us to the same point I
was first talking about which is the ability to identify the idiom and
code to operate on it as an idiom. some of the stuff I've seen with
snippets is partly there, again it is a one-way transform.
It seems to me that those of us with hands and those of us with broken
hands could use this same functionality given the right supportive user
interface.
Now I've been living with this kind of idea for a while and I realize
that may not make sense in this abstract written description. What do I
need to fill in?
However, back when I was doing my PEP 463 research, someone suggested
looking into the 2to3 parser. I regretfully admit that I have yet to
actually do so, but it ought in theory allow source-level
transformations with a measure of intelligence. It's not a ready-made
solution by any means, but it could be a useful tool. [2]
Good idea.
Hope this helps. I find that topic pretty interesting. Is there
anything I can follow to see progress on this?
Likewise!
ChrisA
Is there any problem with keeping the conversation going here or would
you prefer some other way of talking about it? I've been hesitant to put
my work up on github because it's flailing about with also the bloody
loose ends because I'm trying to solve up number of problems all at the
same time. The problem first being a framework where I can add speech
driven UI elements to an editor so I can start experimenting with a
bunch of these pieces.
Another way you can help is be my hands. sometimes I just run out of
hand time and it takes a while for me build up enough energy so I can
spend the day working for money and a day working on this.
--- eric
--
https://mail.python.org/mailman/listinfo/python-list
