Re: Exception Handling Practices / Patterns
Hi Steven,
Yea this is great. Thanks for the feedback.
On Saturday, August 24, 2013 3:27:45 AM UTC-7, Steven D'Aprano wrote:
> On Fri, 23 Aug 2013 22:25:55 -0700, snarf wrote:
>
>
>
> [...]
>
> > * Seems like exception handing within Classes is largely avoided and is
>
> > typically only used when calling external libraries.
>
>
>
> There is certainly no rule "avoid exceptions inside classes". Methods
>
> often raise exceptions to signal an error, e.g.:
>
>
>
> "My string".index("spam")
>
>
>
>
>
> Less common, methods can raise exceptions as part of their flow control.
>
> The most obvious example is StopIteration, used by iterators and often by
>
> __iter__ or next methods.
>
>
>
>
>
> > * Try/Except type
>
> > statements seem to be used more within modules, main functions, wrapper
>
> > scripts.
>
>
>
> It depends on whose code you are reading. I don't write a lot of classes,
>
> but when I do, I often use try...except inside them.
>
>
>
> If try...except gets used more frequently in module's top level, it is
>
> because the sort of things that you do at the top level often needs
>
> exception handling. For example, you might have a fallback module:
>
>
>
> try:
>
> import this_module
>
> except ImportError:
>
> import that_module as this_module
>
>
>
>
>
> You will very rarely see that inside a class, since you very rarely
>
> import modules inside a class.
>
>
>
>
>
> > * Classes should be coded in a way that exceptions
>
>
>
> I think you forgot to finish the sentence.
>
>
>
>
>
> > * Better to
>
> > never write your own exceptions (unless you absolutely have to).
>
>
>
> That depends.
>
>
>
> On the one hand, nobody wants a million different exception types. On the
>
> other hand, nobody wants just *one* exception type, and no way to
>
> distinguish between different kinds of errors. Somewhere between one and
>
> one million is an appropriate number of exception types.
>
>
>
> The right answer is to be conservative about creating new exceptions, but
>
> don't be scared to create one when you need one.
>
>
>
> But when you do, it is often better to subclass from an appropriate built-
>
> in exception like ValueError or TypeError or similar, than to subclass
>
> from Exception itself.
>
>
>
>
>
> > * Using
>
> > Exception is typically a bad. More specific the better.
>
>
>
> Yes, you should always try to catch the specific exceptions you care
>
> about:
>
>
>
>
>
> # Best
>
> except ValueError, OverflowError, ZeroDivisionError:
>
>
>
>
>
> # Not so good
>
> except Exception:
>
>
>
>
>
> # Worst
>
> except:
>
>
>
>
>
> Don't use the last one, except maybe in the interactive interpreter,
>
> since it will catch *everything*, even exceptions that probably shouldn't
>
> be caught like KeyboardInterrupt.
>
>
>
>
>
> > * Exceptions
>
> > should never fail silently. (Should exceptions always be logged?)
>
>
>
> Certainly not. Exceptions should fail silently if you don't care about
>
> them. For example, when connecting to a website, there are many temporary
>
> errors that can occur. The best way to handle them is to catch the
>
> exception, sleep for a little while, then try again. You need only care
>
> if repeated attempts to connect, with larger and larger sleeps, continue
>
> to fail.
>
>
>
> Of course, you might have a debug mode that logs all of these, but if
>
> your web browser logged every single time a webpage was slow to respond,
>
> you would soon run out of disk space :-)
>
>
>
> *Errors* should never fail silently, unless explicitly silenced. But an
>
> error isn't an error if you don't care about it, and an exception is not
>
> necessarily an error.
>
>
>
> This is an error, because converting a number to uppercase cannot
>
> possibly mean anything:
>
>
>
> mystring = 42
>
> mystring.upper()
>
>
>
>
>
> This is not necessarily an error, since "the list is empty" could be a
>
> legitimate situation:
>
>
>
> mylist = []
>
> first = mylist[0]
>
>
>
> In this case, it may be appropriate to catch the exception, and either
>
> silently swallow it, or do something else.
>
>
>
>
>
> > Best site I have found for exceptions (hopefully this helps someone): *
>
> > http://c2.com/cgi/wiki?ExceptionPatterns
>
>
>
> I haven't read that page for a long time, but as I recall the c2.com
>
> website, a lot of the ideas there are better suited to Java and C/C++
>
> (and occasionally Lisp) rather than Python. But still, a valuable (if
>
> often confusing) resource.
>
>
>
>
>
>
>
> > I'd be interested in hearing others thoughts on this topic with regards
>
> > to best practices for when to use exceptions, and when to avoid using
>
> > exceptions.
>
>
>
> The try part of a try...except is *very* fast to set up. It's about as
>
> fast as a "pass" (do nothing), so it has little overhead.
>
Re: Exception Handling Practices / Patterns
Appreciate the feedback. I was hoping to get as much perspective as possible. On Saturday, August 24, 2013 12:18:59 AM UTC-7, Dave Angel wrote: > snarf wrote: > > > > > Greetings, > > > > > > As I tread through my journey of OO I am trying to determine if there is a > > good approach for exception handling within classes. > > > > > > From my readings and gatherings - it seems I have found a common theme, but > > I am trying to solicit from the experts. > > > > > > Here is what I have found (I may be restating the obvious so please forgive > > me in advance): > > > > > > * Seems like exception handing within Classes is largely avoided and is > > typically only used when calling external libraries. > > > * Try/Except type statements seem to be used more within modules, main > > functions, wrapper scripts. > > > > Exceptions are used when useful. I don't see any bias towards any one > > location. > > > > > * Classes should be coded in a way that exceptions > > > > You seem to be missing the last part of this sentence. > > > > > * Better to never write your own exceptions (unless you absolutely have to). > > > > If you mean to avoid writing exception classes, then I say nonsense. > > Just derive them from the closest meaningful exception class, so that a > > user can combine handlers when reasonable. > > > > > * Using Exception is typically a bad. More specific the better. > > > > If you mean in an except statement, then I'd agree. > > > > > * Exceptions should never fail silently. (Should exceptions always be > > logged?) > > > > Exceptions should be caught if you can handle them, or if you need to > > convert them to a different exception that someone further up the stack > > can handle. Sometimes handling means do nothing. > > > > > > > > Best site I have found for exceptions (hopefully this helps someone): > > > * http://c2.com/cgi/wiki?ExceptionPatterns > > > > But that's for Java. java is not C++, and neither is it Python. For > > one thing, Python exception overhead is deliberately much less, and they > > are used more freely. > > > > Notice that exceptions are used to terminate for loops, and that's a > > *normal* exit to the loop. They also appear in other places under the > > covers. Don't be afraid of them. > > > > -- > > DaveA -- http://mail.python.org/mailman/listinfo/python-list
Graphing
I am looking to plot some data points related to system metrics. Benchmarking, etc. Can someone give some recommendations on a good way to graph these datapoints in python. I started looking into matplotlib, however was interested in others experiences. -- http://mail.python.org/mailman/listinfo/python-list
Memory
Quick question, What is the best way for pulling resource information for a system running linux? Was wondering if there was a python only way. Methods I am aware of are: 1. Parsing contents of /proc 2. Running a system command like free, or dmidecode and parsing the output. Is there any other way to pull.. lets say memory information? i.e. Find how much total RAM a system has on it. Thanks you. -- http://mail.python.org/mailman/listinfo/python-list
Paramiko Help
Apologies.. Python newb here.. switching from perl to python.. so please forgive if this is a dumb question. I am using the paramiko module and have some global variables defined. i.e. hostname = ' 10.10.10.10' sshport = '22' I am then trying to pass this variable into the client connect method - client = paramiko.SSHClient() client.load_system_host_keys() client.connect(hostname, sshport, root) I also have public key setup between source and destination host, so not sure if this will work, but trying to jump one hurtle at at time. So it seems like the values past to the connect method are taken at face value based on the error message I am seeing: TypeError: an integer is required Any help is much appreciated. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Paramiko help - processing multiple commands
Greetings,
I am trying to process multiple commands using paramiko. I have
searched other threads, and I think my use case is a little different.
I am trying to login to a storage node that has a special shell, and
as such I cant execute a script on the storage node side.
I am also trying to avoid using pexpect because I hate making system
calls.. hence my leaning towards paramiko.
Was hoping someone could help me identify a way to process multiple
commands using paramiko.
I have two commands listed below, however only one is getting processed.
Any help is much appreciated.
Thanks!
Here is my script:
#!/usr/bin/env python
#-Modules-
import optparse
import sys
import paramiko
#-Variables---
plog = 'storagessh.log'
suser = 'root'
#-Config--
#-Subs-Defined
def options():
global hostname
global goldenimage
global lunclone
global sshport
usage = "usage: %prog [options] -n -g -l "
parser = optparse.OptionParser(usage)
parser.add_option("-n", "--node",
dest="hostname",
help="Name of storage node you are connecting to.")
parser.add_option("-g", "--gold",
dest="goldenimage",
help="Name of goldenimage to clone.")
parser.add_option("-l", "--lun",
dest="lunclone",
help="Name of lun to create.")
parser.add_option("-p", "--port",
dest="sshport",
default=22,
help="SSH port number.")
options, args = parser.parse_args()
if not options.hostname:
parser.error("Missing hostname argument.")
exit
elif not options.goldenimage:
parser.error("Missing goldenimage argument.")
exit
elif not options.lunclone:
parser.error("Missing lun argument.")
exit
hostname = options.hostname
goldenimage = options.goldenimage
lunclone = options.lunclone
sshport = options.sshport
def storagessh():
paramiko.util.log_to_file(plog)
client = paramiko.SSHClient()
client.load_system_host_keys()
client.connect(hostname, sshport, suser)
stdin, stdout, stderr = client.exec_command('show')
stdin, stdout, stderr = client.exec_command('help')
print stdout.read()
client.close()
#--Initialization-
if __name__ == "__main__":
options()
storagessh()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Paramiko help - processing multiple commands
Hi Jon,
Thanks for the reply. So there are no errors. Essentially everything
runs as planned. Sorry for being ignorant, but I am not sure if there
is another way for providing trace data. I will look into what other
debugging I can provide.
Essentially what happens is that only the second command gets
processed and the first is ignored.
As far as the global variables are concerned, I am not too sure what
the best way is to allow my variables to be seen by another sub. In
the script I am using optparse, however in order for the variables to
make any sense to my storagessh sub, I have to declare them as global,
since all the variables within my options sub have a local scope.
I am not too sure of a better way to do this. I don't like it much
either. Hopefully you can help me shed some light on this in terms of
best practice.
Normally I declare variable scope outside of my subroutines where required.
However since variable scope is local within a subroutine, seems like
I have to declare them global in order for the other subs to see it.
Anyhow.. your feedback has been much appreciated.. The script is still
a work in progress, so I plan to do so more cosmetic enhancements once
I review it a few more times.
Thanks!
On Wed, Jun 24, 2009 at 4:34 PM, Jon Clements wrote:
> On Jun 24, 11:22 pm, Frank Ruiz wrote:
>> Greetings,
>>
>> I am trying to process multiple commands using paramiko. I have
>> searched other threads, and I think my use case is a little different.
>> I am trying to login to a storage node that has a special shell, and
>> as such I cant execute a script on the storage node side.
>>
>> I am also trying to avoid using pexpect because I hate making system
>> calls.. hence my leaning towards paramiko.
>>
>> Was hoping someone could help me identify a way to process multiple
>> commands using paramiko.
>>
>> I have two commands listed below, however only one is getting processed.
>>
>> Any help is much appreciated.
>>
>> Thanks!
>>
>> Here is my script:
>>
>> #!/usr/bin/env python
>>
>> #-Modules-
>> import optparse
>> import sys
>> import paramiko
>>
>> #-Variables---
>> plog = 'storagessh.log'
>> suser = 'root'
>>
>> #-Config--
>>
>> #-Subs-Defined
>> def options():
>> global hostname
>> global goldenimage
>> global lunclone
>> global sshport
>>
>> usage = "usage: %prog [options] -n -g -l "
>>
>> parser = optparse.OptionParser(usage)
>>
>> parser.add_option("-n", "--node",
>> dest="hostname",
>> help="Name of storage node you are connecting to.")
>> parser.add_option("-g", "--gold",
>> dest="goldenimage",
>> help="Name of goldenimage to clone.")
>> parser.add_option("-l", "--lun",
>> dest="lunclone",
>> help="Name of lun to create.")
>> parser.add_option("-p", "--port",
>> dest="sshport",
>> default=22,
>> help="SSH port number.")
>> options, args = parser.parse_args()
>>
>> if not options.hostname:
>> parser.error("Missing hostname argument.")
>> exit
>> elif not options.goldenimage:
>> parser.error("Missing goldenimage argument.")
>> exit
>> elif not options.lunclone:
>> parser.error("Missing lun argument.")
>> exit
>>
>> hostname = options.hostname
>> goldenimage = options.goldenimage
>> lunclone = options.lunclone
>> sshport = options.sshport
>>
>> def storagessh():
>> paramiko.util.log_to_file(plog)
>> client = paramiko.SSHClient()
>> client.load_system_host_keys()
>> client.connect(hostname, sshport, suser)
>> stdin, stdout, stderr = client.exec_command('show')
>> stdin, stdout, stderr = client.exec_command('help')
>> print stdout.read()
>> client.close()
>>
>> #--Initialization-
>> if __name__ == "__main__":
>> options()
>> storagessh()
>
> Again, as you were asked on the original post -- full tracebacks and
> explain "what is not working".
>
> The use of global variables scares me -- why are those needed?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
