[Tutor] suitability to task

Sean 'Shaleh' Perry shalehperry@attbi.com
Wed, 21 Aug 2002 10:21:35 -0700


On Tuesday 20 August 2002 05:55 pm, Darren Reynolds wrote:
> just doing some planning work on a project i'm going to be doing for
> myself, and was wondering if ppl might be able to tell me if python (or
> another language) would be better suited for it.  i'm also not decided
> yet on what form the data storage is going to take place.  the program
> isn't going to be very complex (mp3 database / indexing), and is going
> to run in the console as opposed to graphical interface.  in essence it=
s
> operation will be this ...
>

easily accomplished in python (-;

> -- will do an 'ls -R /cdrom' (or some other command that will give me
> recirsive listing of all files and directories on the cd) and re-direct
> output to a temporary flat-text file

import os.path and look into os.path.walk.

> -- will name the text file based on user input
> -- once disc has been read, text file will be processed to read the
> following information; artist, album, year pf release, # of tracks per
> album, track names, format, disc "name" (as entered by user ... as all
> the cds will have consistent layout, program shouldn't have a problem
> picking these pieces out or knowing when new album listing has started)
> -- take this information and place it into data storage (both flat-text
> file storage and mysql have been suggested by friends of mine)

a db of sort sort (sql or not) is probably a good idea, more on this in a=
=20
moment.

> -- remove the temporary text file once data has been successfully
> committed to storage
> -- will also have options for user to search indexed cds by; artist.
> album, track name

this would be aided by a db backend, most of the hard work would be done =
for=20
you.

> -- will pipe search results to screen (through pager such as less) and
> indicate to user all criteria matches and which cds the tracks / albums
> can be found (the user entered "name" for each cd will be used as the
> indicator as to track location)
>
> so, if anyone has any in advance "caveats" for me to look out for, or
> could make any suggestions about data storage ... i'm all "ears" ... :)
>

A sql db has some pros and cons:

cons --

* Must be running to use it.  This means you lose some cpu and memory.  N=
ot=20
bad if you use the db for other projects or if it is on another machine.

* Must maintain the db.

* Must learn about dbs.

pros --

* they have solved the storage and efficiencies problems

* can output the data to multiple programs / views

* flat text can be implemented via the db and even by a separate app

* flexibility in general

There are other db style approaches that may not require an actual runnin=
g db=20
server.