Hi @voidfiles, thanks for taking this up! I think what you suggested, with regards to pushing this into a class, is a good idea. As you may have read here, I'm making changes to the algorithm.

In doing so, I realized yesterday that v2 of the algorithm/module is noticeably different, and some lines of code lengthier. I'm largely on the side of placing v2 into its own file.

Now here's why:

v2 is an improvement. But eatiht v1 is the stepping stone. I think it would be good to have the original code exist on its own as a reference.
Additions and extensions can be tested and refined on the original (or copy of) eatiht.py first, while
v2 get's its own bugs out in public.

As a corollary, implementing an OO version of eatiht would be great. I don't know what the rule of thumb is for instances like this, but I like the idea of having two concurrent "implementations" of each version:

UPDATED 12/25/14

                v1                                    v2
             ____|____                             ____|____
            |         |                           |         |
      script.py     class.py                 script.py    class.py
     (eatiht.py) (voidfile's html ext)      (etv2.py)      (in. prog.)

Is this over doing it? Another reason I would suggest the above architecture is because
I personally think I'm most likely to skip Python protocol in favor of algorithm turnover. I know
there are way more experienced Python programmers who can develop a beautiful class structure
faster than I can respond to @voidfiles :P

Access to HTML of Article #3

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions