Question about Object Oriented + functions/global vars?
onurb at xiludom.gro
Tue Jun 7 11:17:35 CEST 2005
> ok, so to my knowledge, object oriented means splitting something into
> the simplest number of parts and going from there.
So you may want to refine your knowledge. What you're talking about is
top-down functional decomposition, and it's almost the opposite of OO.
OO is about interacting objects. An object is defined by an identity, a
state, a behaviour, and (even if implicitely) an interface. Objects do
interact by sending messages to each others. The interface of a given
object is the list of *what* messages this object understands (ie: can
respond to). The behavior is defined by *how* a given object responds to
messages (different objects can respond differently to the same message,
and a given object may respond differently to the same message according
to it's current state). The state is made up of the object's internals
> But the question is-
> when is it enough?
> For example I have the following code:
> #def put_file(file_id, delete=False):
> # """ Function to put the file on the FTP Server
> # """
> # print "["+file_id+"] FTP for this file started"
> # print "[" + file_id + "] Connecting to machine " + global_addr
Where does this 'global_addr' var come from ?
> # ftp_pool = FTP_pool(file_id,1,40,global_uid,global_pwd)
idem for global_uid and global_pwd. And what are those magic numbers 1
and 40 ?
> # print 'in put_file'
> # try:
> # ftp = ftplib.FTP(global_addr)
> # ftp.login(global_uid, global_pwd)
> # print ftp.getwelcome() +'\n'
> # ftp.cwd(global_ftp_loc)
>># ext = os.path.splitext(file_id)
>># if ext not in (".sc4", ".snpickle"):
>># ftp.storlines("STOR " + file_id, open(file_id))
>># ftp.storbinary("STOR " + file_id, open(file_id, "rb"), 1024)
> # ftp.quit()
> # ftp_pool.close_all()
> # except:
Take care of too-large-except-clause. Here it's ok since you re-raise
the exception, but this is usually a bad practice to not specify the
exception class(es) you want to catch. Hint: sys.exit() works by raising
> # ftp_pool.close_all()
> # print "[" + file_id + "]Unable to access FTP location"
> # print "[" + file_id + "]Error:" + str(sys.exc_info()) + " "
> + str(sys.exc_info())
> # upload_status[file_id] = "FAILED"
Where does this upload_status comes from ?
> # raise
> # else:
> # print "[" + file_id + "] FTP for file completed"
> # upload_status[file_id] = "SUCCESS"
> would the lines with '>#' best be split up into a seperate function,
> for example:
> #def upload(ftp, file):
dont use 'file', it shadows the builtin file class.
> # ext = os.path.splitext(file)
> # if ext in (".txt", ".htm", ".html"):
> # ftp.storlines("STOR " + file, open(file))
> # else:
> # ftp.storbinary("STOR " + file, open(file, "rb"), 1024)
<IMHO> The calling code should not have to worry about this. This should
be a responsability of some object(s) abstracting the file, and should
be implemented as different behaviors (using text or binary) in response
to the same message.</IMHO> In short, this could look like:
the_file = FtpFileDescriptor(path)
# the_file objects knows if it must use text or binary.
# we, as client, just don't care about this gory detail.
except MyFtpUploadError, e:
> and then doing the call 'upload(file_id)', or is it a better practice
> to leave things the way they were? I'm confused.
> Finally, is it considered 'un-object-oriented' in python to have
> functions inside a module that are called by objects (ie the upload
> function above) and/or use global variables in combination?
In Python, everything's an object (well... almost everything). At
runtime, a module is an object :
<module 'ftplib' from '/usr/lib/python2.3/ftplib.pyc'>
module-level 'functions' are methods of the given module object, and
'global' vars (the term 'global' is somewhat misleading, since it reaaly
means 'module-level') are attributes of the module object.
Now what makes the difference between OO and non-OO is not the use of
classes, objects etc, but how you *design* your program. Your code
snippet makes use of OO features (classes, objects etc), but is typical
of procedural style. Not because you use 'module-level' functions and
vars, but because there's no abstraction, no separation of concerns and
> -thanks in advance
HTH (not sure, but...)
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb at xiludom.gro'.split('@')])"
More information about the Python-list