[Tutor] Re: Advice needed on first project

Adam adam at monkeez.org
Thu Apr 15 15:33:29 EDT 2004


Andrei wrote:

> Adam wrote on Thursday 15 April 2004 18:49:
> <snip>
> 
><snip>
> 
> Triple-quoted strings can have this form:
> """First line
> Second line""",
> which makes them a better way of specifying long strings. So it does have to
> do with the newline characters in long strings :). It would also remove the
> need to make a function especially for the purpose of showing the welcome
> string, since it could simply be a variable which gets printed, "print
> welcome".
> 
> Another neat trick is to use a docstring at the top of your module and use
> that for welcome too:
> 
> """My doc""" # doc string for module
> print __doc__ # print docstring at top of module

I thought so - this is a very intuitive language to pick up (well, at 
least for me it is). This will be adopted.

> Other suggestions about the code:
> 
> - don't use tabs. The preferred way of writing Python code is by using 4
> spaces per indentation level. This is what you do in create_new_articles,
> but you use tabs in menu. If you now try to copy-paste code from the one to
> the other in order to avoid the mini-modules, you'll get some errors I
> think.
> The best way to not worry about this is to set up your editor in such a way
> that pressing TAB will insert 4 spaces and that auto-indentation uses 4
> spaces.
> 
> - raw_input takes a parameter:
>     >>> raw_input("Your name: ")
>     Your name: Adam
>     'Adam'
> Use this in order to avoid all the print statements in create_new_article.
> This will almost halve the amount of code in that function.

I think I already experienced some problems with the tabs already. I 
started off using jedit (please don't start a discussion about merits of 
  text editors!) and then gave pyalamode a go - it seemed to report 
errors with the indentation. I imagine that if I use one editor 
consistently, it will prevent this.

> - always assume your users are stupid - I do that even if I only code for
> myself :). What happens if your user answers "n" or 'new' in the menu or
> accidentally types a space before or after the 'n'? He's told the choice is
> invalid. Case sensitive menus are not a very good idea. That's why it makes
> sense to clean up the response a bit:
> 
>   response = response.strip().lower() # remove spaces and lower-case it
> 
> In order to account for cases when the user answers 'new', you could also:
> 
>   response = response[:1] # only look at the first char
> 
> - there's no way to exit from the menu, nor instructions on how to terminate
> the program by other means (Ctrl+Z).
> 

This kind of feature is coming and it seems very easy to implement, but 
I bet that it is quite difficult to do well (ie. taking into account all 
  eventualities of user input).

Thanks again.

adam



More information about the Tutor mailing list