Problems with my python program

[henryford]

Hi I am in a web programming class and have been struggling greatly with this assignment. I am not very familiar with Functions and so forth but I have been truthfully working on this for a few days now. I am at the point where I am stuck. I would appreciate it if any of you guys or gals could help me out. Thanks again.

def employee():
    global eName
    global pRate
    global hWork

def Lowest(hoursList):
    PAYList.sort()
    lowestPay = hoursList[0]
    return lowestPay

def Highest(hoursList):
    hoursList.sort()
    highestPay=hoursList[len(hoursList)-1]
    return highestPay

def Average(hoursList):
    total=0
    for hour in hoursList:
        total += hour
    avgPay = total / len(hoursList)
    return avgPay


raw_input("Hit ENTER to start Payroll Program.")
hours=[]
hWork="1"
while True:
    eName=raw_input("\nPlease enter the employees' first and last name. ")
    hWork=raw_input("How many hours did they work this week? ")
    if hWork < "1" or hWork > "60":
        print "Employees' can't work less than 1 hour or more than 60 hours!"
        continue
    else:
        pRate=int(raw_input("What is their hourly rate? "))
        if pRate < 6 or pRate > 20:
            print "Employees' wages can't be lower than $6.00 or greater than $20.00!"
        else:
##            eName.append(name.title() + "\n")
            hours.append(hWork + "\n")
            ePass = ""
            ePass = raw_input("Type DONE when finished with employees' information. ")
            if ePass  == "DONE":
                try:
                    hoursFile=open("PAY.txt", "w")
                    hoursFile.writelines(hours)
##                    hoursFile.writelines(eName)
                    hoursFile.close()
                except(IOError):
                    print "Error writing hours! "
                    quit()
                try:
                    hoursFile=open("PAY.txt", "r")
                    hoursList=hoursFile.readlines()
                    hoursFile.close()
                    hoursList.sort()
                except(IOError):
                    print "Error writing names! "
                    quit()
                modHours = hoursList
                for hour in hoursList:
                    print hour

[WildBamaBoy]

What exactly is the problem?

[richieking]

on line 29 do int type casting for your raw input.

you are checking string with while loop for int.
not good really.

besides i dont see what you want really.

;)

[henryford]

I just can't get the whole thing to execute. Like I said I am new to this stuff and am struggling.

[ChaosKnight11]

Executes just fine... Tested it just now. Should it only write the hours to the file?

[richieking]

I just tried your code. works ok on my UBUNTU.

change the data type on line 34 to accept float or provide information about the datatype to use. Or Or ... make availability for the 2 datatype.

Files stuff..... The logic of opening the same file 2 time not really good.
If you will be writing and reading, just open the file r+.
Also write data to your file after each session so that you can format your inputs.
Besides everything works fine.

explore ;)

[griswolf]

I notice that lines 1 through 5 are:

• useless
• never called (fortunately)

It almost looks as if you are trying to make an Employee class (which is not a bad idea) but don't understand how to do it. (almost because I don't see how the hWork fits in.) Here's how:

class Employee:
  def __init__(self,name,rate=6):
    self.name = name
    self.rate = rate

# for fun, lets make a global function to pretty-print an Employee's name and rate
# it would probably be better if it were a member function, but leave it for now
def printEmployee(employee):
  print("%s earns $%d.00 per hour"%(employee.name,employee.rate))
# create an employee "Raj" at minimum rate
raj = Employee('Raj')
# show Raj's info
printEmployee(raj)
# create an employee "San" at $15.00 rate
san = Employee('San',15)
# show San's info
printEmployee(san)

[richieking]

Optimise the class like ***

name=raw_input("name: ")

class Employee:
def empDetails(self,name,rate=6): #default value init
self.name = name
self.rate = rate

# for fun, lets make a global function to pretty-print an Employee's name and rate
# it would probably be better if it were a member function, but leave it for now
def print_Employee(self):
print("%s earns $%d.00 per hour"%(self.name,self.rate))
# create an employee "Raj" at minimum rate

raj=Employee(); # Class initialise into class object

raj.empDetails(name)#Better abstraction of data
# show Raj's info
raj.print_Employee()
# create an employee "San" at $15.00 rate
san=Employee()
san.empDetails("fred",15)
# show San's info
san.print_Employee()

[richieking]

;)

[richieking]

OOP need clean encaps.
Class must contain all the dirty job done inside.

griswolf edited

name=raw_input("name: ")

class Employee:
  def empDetails(self,name,rate=6): #default value init
    self.name = name
    self.rate = rate

# for fun, lets make a global function to pretty-print an Employee's name and rate
# it would probably be better if it were a member function, but leave it for now
  def print_Employee(self):
       print("%s earns $%d.00 per hour"%(self.name,self.rate))
# create an employee "Raj" at minimum rate

raj=Employee(); # Class initialise into class object

raj.empDetails(name)#Better abstraction of data
# show Raj's info
raj.print_Employee()
# create an employee "San" at $15.00 rate
san=Employee()
san.empDetails("fred",15)
# show San's info
san.print_Employee()

[richieking]

OOP need clean encaps.
Class must contain all the dirty job done inside.

griswolf edited

name=raw_input("name: ")

class Employee:
  def empDetails(self,name,rate=6): #default value init
    self.name = name
    self.rate = rate

# for fun, lets make a global function to pretty-print an Employee's name and rate
# it would probably be better if it were a member function, but leave it for now
  def print_Employee(self):
       print("%s earns $%d.00 per hour"%(self.name,self.rate))
# create an employee "Raj" at minimum rate

raj=Employee(); # Class initialise into class object

raj.empDetails(name)#Better abstraction of data
# show Raj's info
raj.print_Employee()
# create an employee "San" at $15.00 rate
san=Employee()
san.empDetails("fred",15)
# show San's info
san.print_Employee()

[griswolf]

@richieking: Not every class should have a default constructor. There is no purpose to a nameless employee, and no way to make a reasonable default, so to create an employee, I make you pass the name. Minimum allowable wage is a reasonable default, so I provided that. If we were to code the way you suggest, there is no guarantee that every Employee instance has a name or rate: You are requiring the coder to remember to first create an Employee, and then call the init function (whose name is empDetails ) Better to do it all at once in the constructor (which is spelled __init__ in Python.

It may be that the employee class should have the pretty print function if it exists at all, but it probably should not be a member or a global function (it should be a function local to whatever module or class needs to handle a pretty representation of the Employee). Default string should be an economical representation of the data (not a 'pretty' one) and should be defined in member function __unicode__ (or, __str__ ). See http://stackoverflow.com/questions/1307014/python-str-versus-unicode

To make that point a little more clear, as a mental exercise, imagine a class Number. Should that class define a pretty_string() member function or should that functionality be some other place? If you anthropomorphize the class, imagine it saying "I need to know how to best present myself." or "I don't care what I look like, it's what I hold that really counts." (Obviously, Mr. Number likes puns.) Which of those attitudes makes a Number the most flexible? Which makes it the easiest to use for a beginner? Does 'easy to begin using' make it less useful for experts? What if Mr. Number needs to visit a fancy restaurant one time but a biker bar the next time? Does he 'know how to best present himself' in every possible setting?

[richieking]

look dont take thing personal buddy.

I was just showing another way to your psedo.

;)

[griswolf]

look dont take thing personal buddy.

I was just showing another way to your psedo.

;)

It ain't personal, its didactic. Did you think about it? Perhaps I should have had Mr. Number visit a science expo one time and a primary school the next. Is the representation of the value 1111.111111 better as "1.11111*10^3", as "approximately 1100" as "1111 plus 1/9" or something else? Does the appropriate choice for 'pretty' representation depend in any way on the data itself (except for the represented value)?

[Gribouillis]

It ain't personal, its didactic. Did you think about it? Perhaps I should have had Mr. Number visit a science expo one time and a primary school the next. Is the representation of the value 1111.111111 better as "1.11111*10^3", as "approximately 1100" as "1111 plus 1/9" or something else? Does the appropriate choice for 'pretty' representation depend in any way on the data itself (except for the represented value)?

Your ideas go against the YAGNI paradigm. One doesn't need to implement every hypothetical future use of the data.

[richieking]

griswolf,

You are getting into the nitty gritty in O/I stream here which ofcourse is not the point. It was another class operation.
I personally like your illustration about Mr. Number and the flexibility stuff. But does the thread poster?? i dont think so.

No doubt that you got a very fine idea in python and i dont wanna take that from away you.
Maybe you can be my teacher one day. Who knows.? And greetings to Mr. Number ;)

[TrustyTony]

Beauty is in the eye of beholder, I have written super simple pretty printer as I did not like the result of pprint module for shallow lists.

I could think that object with pretty format template attribute settable from user would not be bad thing, just remember to keep repr as near as possible to object creation statement (ideally possible to run through eval to produce == object)

Think of locale: locale.str versus standard str.

Most important and understandable principle must not be forgotten: KISS (Keep it simple, stupid). I think it is close to YAGNI (You Ain't Gona Need It) Maybe it should be applied ot message threads in addition of the programming :)

Hope this thread is solved now, if so mark it so, dear OP!

[griswolf]

Your ideas go against the YAGNI paradigm. One doesn't need to implement every hypothetical future use of the data.

Could not agree more. If you don't need a pretty print function, don't implement it (for some pretty small value of 'need').

On the other hand, it is good to think about issues in advance of need, as an exercise for growing your programming skills. If you do need a pretty print function, where should it live? This is the thing I'm talking about above: Where, not whether. There are basically three options:

1. A member function. Pro: The class knows its own member data, easier to maintain as the class evolves. Con: The class has no good idea about the meaning of 'pretty'
2. A global function. Pro: Can be easily shared among code that needs to call it. Con: 'Global' has no good idea about the meaning of 'pretty' and also may make maintenance harder as the class evolves.
3. In the context of the place it is needed. Pro: Does know what 'pretty' means in this context. Con: Not directly associated with the class.

I think there is no clear 'always right' answer. I tend to make 'util print' (__str__) a class member, and put 'pretty print' in the context where the printing is needed.

Pretty printing is a specific example of the kind of issues that often arise when 'keep concerns separate' runs up against concerns about too tight coupling. Agree that this is a pretty sharp turn away from the concerns of the OP; and will stop now...

[Gribouillis]

Could not agree more. If you don't need a pretty print function, don't implement it (for some pretty small value of 'need').

On the other hand, it is good to think about issues in advance of need, as an exercise for growing your programming skills. If you do need a pretty print function, where should it live? This is the thing I'm talking about above: Where, not whether. There are basically three options:

1. A member function. Pro: The class knows its own member data, easier to maintain as the class evolves. Con: The class has no good idea about the meaning of 'pretty'
2. A global function. Pro: Can be easily shared among code that needs to call it. Con: 'Global' has no good idea about the meaning of 'pretty' and also may make maintenance harder as the class evolves.
3. In the context of the place it is needed. Pro: Does know what 'pretty' means in this context. Con: Not directly associated with the class.

I think there is no clear 'always right' answer. I tend to make 'util print' (__str__) a class member, and put 'pretty print' in the context where the printing is needed.

Pretty printing is a specific example of the kind of issues that often arise when 'keep concerns separate' runs up against concerns about too tight coupling. Agree that this is a pretty sharp turn away from the concerns of the OP; and will stop now...

I think I would definitely choose a member function, otherwise the 'pretty print' feature will be hidden somewhere in a module and never reused. The place where the pretty print feature is potentialy needed is where we have an instance of the class. If the method is in the class, it will be imediately available then.

[richieking]

If you wanna use a class, you are definately in for using its member function. Proper encapsulation not when it suites you.

Designing a class is an art.
;)