5
\$\begingroup\$

I've written a python module that randomly generates a list of ideas that can be used as the premises for furthur research. For instance, it would be useful in situations where a new thesis topic is required, either for a masters or a doctorate program. Or if someone is just simply bored with their lives and wants some brainstorming ideas about the kind of project that they would like to be involved in, this python module can be used.

The output is a list of random ideas or technologies. It is up to the user as to how they interpret the output. Each idea in the list can be assessed individually, or the ideas can be combined in ways never thought off before to create something new.

I would like some input on how else I can improve the project or what other features I may add. The project is hosted on github. The name of the project is ranto for lack of a better name.

For the impatient, here is the code from the sole python file in the project...

import random
import sys

def topics(f):
    f = open(f, 'r')
    wordlist = []

    for i in f:
        wordlist.append(i.strip())
    return wordlist

def mainp():
    wordlist = topics('../data/' + sys.argv[1])

    while True:
        print random.sample(wordlist, int(sys.argv[2]))
        if raw_input() == '':
            continue
        else:
            break   

mainp()

If you want to test it out, you need to download one of the data files from the github repo linked earlier.

Any feedback would be appreciated.

\$\endgroup\$
  • 1
    \$\begingroup\$ Even for such simple program there's a thing you could do: replace each <tab> with four spaces (it isn't obvious here, but it is on the GitHub); this is a PEP recommendation. On a slightly unrelated note (since this is Code Review, not Feature Review), it would be cool if Ranto could get data for topics from other sources—for example, Wikipedia. \$\endgroup\$ – Tony Jul 6 '11 at 16:21
2
\$\begingroup\$

I can't tell from your question whether you are wanting ideas to improve this python code or the project itself. Your code above works and is readable, so take the following re-spelling of it as minor nitpicks.

def topics(f):
    for i in open(f):   # inline the call to open(), and drop the implicit 'r'.
        yield i.strip() # "yield" turns this into a generator function that will only
                        # read as many lines of the file as are requested.

def mainp():  # consider renaming to something more descriptive (generate_topics?)
    wordlist = topics('../data/' + sys.argv[1])
    response = True # Or any "truthy" value that drops us into the while loop one time.
    while response:
        print random.sample(wordlist, int(sys.argv[2]))
        response = raw_input()

if __name__ == "__main__":  # Putting in this if guard allows you to import your 
    mainp()                 # functions above from anywhere else you might want them.

You may want to peruse the HOWTO for generator functions.

\$\endgroup\$
  • \$\begingroup\$ -1: "and drop the implicit 'r'." Never works out well in the long run. Only really smart people remember that 'r' is the default. The rest of us have to look it up. \$\endgroup\$ – S.Lott Jul 11 '11 at 14:51
  • \$\begingroup\$ @S.Lott: Weird. I thought this was generally known, and am not so smart. \$\endgroup\$ – Tshepang Jul 11 '11 at 15:40
  • \$\begingroup\$ @Tshepang: "generally known" is really hard to determine. However, I do (1) Explicit is better than implicit and (2) I have to look up the defaults and (3) I've had other programmers unable to remember this kind of default. So, for those reasons, I suggest avoiding defaults for this kind of thing. It may be "generally known", but it still doesn't work out well in the long run. \$\endgroup\$ – S.Lott Jul 11 '11 at 15:42
  • \$\begingroup\$ I agree with Lott on this one. If not for all the reasons but one.......'Explicit' is better than 'Implicit'. \$\endgroup\$ – Jay Jul 12 '11 at 20:54
  • \$\begingroup\$ @S.Lott: I don't see how anyone can misread for i in open(f) as opening the file for writing. Do you similarly specify the slice step as 1 when slicing a sequence (e.g. chunk = seq[10:20:1])? That's certainly more explicit, but readability suffers from the extra noise. \$\endgroup\$ – Don Spaulding Jul 19 '11 at 12:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.