Re: [Tutor] raw_input() slice list
Excellent, thank you
and yes I need to work on how to catch and handle exceptions
Thanks again!
On Wed, Sep 28, 2011 at 4:13 PM, bob gailer wrote:
> On 9/27/2011 11:18 PM, questions anon wrote:
>
> I would like to use user_input() to decide how to slice a list.
> This works fine until I try to leave it blank to try and select the whole
> list [:]
> I have posted the section of interest below and the error I get when I try
> to press enter. Further below that is the entire code.
> Any feedback will be greatly appreciated.
> *
> section of code of interest:*
> startperiod=int(raw_input("Start slice (e.g. 1 ): "))
> endperiod=int(raw_input("End slice (e.g. 2): "))
> skipperiod=int(raw_input("skip slice (e.g. 1): "))
>
> if startperiod=="" and endperiod=="" and skipperiod=="":
> startperiod=""
> endperiod=""
> skipperiod=""
>
>
> int() expects a character representation of an integer. An empty string
> will raise the exception you reported.
>
> startperiod will NEVER == "", as it will be an integer.
>
> The entire if statement does nothing! Discard it.
>
> Defer applying int().
>
> Then you can check startperiod etc for equality to "".
>
> if startperiod == "":
> startperiod = None
> else:
> startperiod = int(startperiod)
> if endperiod == "":
>
> endperiod = None
> else:
> endperiod = int(endperiod)
> if skipperiod == "":
> skipperiod = None
> else:
> skipperiod= int(skipperiod)
>
> AND BE PREPARED to catch & handle exceptions in case user enters a
> non-integer value.
>
>
> for (path, dirs, files) in os.walk(MainFolder):
> for dir in dirs:
> print dir
> path=path+'/'
>
> for ncfile in files:
> if ncfile[-3:]=='.nc':
> print "dealing with ncfiles:",
> path+ncfile
> ncfile=os.path.join(path,ncfile)
> ncfile=Dataset(ncfile, 'r+', 'NETCDF4')
>
> variable=ncfile.variables[ncvariablename][:]
> TIME=ncfile.variables['time'][:]
>
> fillvalue=ncfile.variables[ncvariablename]._FillValue
> ncfile.close()
>
> for variable, TIME in
> zip((variable[startperiod:endperiod:skipperiod]),(TIME[startperiod:endperiod:skipperiod])):
>
>
> *the error:*
>
> Traceback (most recent call last):
> File "", line 1, in
> plotrawdata('TSFC')
> File "D:\My Dropbox\Python_code\functions.py", line 39, in plotrawdata
> startperiod=int(raw_input("Start slice (e.g. 1 ): "))
> ValueError: invalid literal for int() with base 10: ''
>
>
> *THE WHOLE PROGRAM:*
> from netCDF4 import Dataset
> import numpy as N
> import matplotlib.pyplot as plt
> from numpy import ma as MA
> from mpl_toolkits.basemap import Basemap
> from netcdftime import utime
> from datetime import datetime
> import os
> import matplotlib.colors as mc
> import matplotlib.colorbar as c
>
> OutputFolder=r"D:/DSE_work/temp_samples2/"
> MainFolder=r"D:/DSE_work/temp_samples2/"
>
>
> def plotrawdata(variable):
> if variable=='TSFC':
> ncvariablename='T_SFC'
> MainFolder=r"D:/DSE_work/temp_samples2/"
> ticks=[-5,0,5,10,15,20,25,30,35,40,45,50]
> Title='Surface Temperature'
>
> elif variable=='RHSFC':
> ncvariablename='RH_SFC'
>
> MainFolder=r"E:/DSE_BushfireClimatologyProject/griddeddatasamples/temp_samples6/"
> ticks=[0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 101]
> Title='Surface RH'
>
>
> fileforlatlon=Dataset("D:/DSE_work/temp_samples2/2020/01/IDZ00026_VIC_ADFD_T_SFC.nc",
> 'r+', 'NETCDF4')
> LAT=fileforlatlon.variables['latitude'][:]
> LON=fileforlatlon.variables['longitude'][:]
>
> startperiod=int(raw_input("Start slice (e.g. 1 ): "))
> endperiod=int(raw_input("End slice (e.g. 2): "))
> skipperiod=int(raw_input("skip slice (e.g. 1): "))
>
> if startperiod=="" and endperiod=="" and skipperiod=="":
> startperiod=str("")
> endperiod=str("")
> skipperiod=str("")
>
>
> for (path, dirs, files) in os.walk(MainFolder):
> for dir in dirs:
> print dir
> path=path+'/'
>
> for ncfile in files:
> if ncfile[-3:]=='.nc':
> print "dealing with ncfiles:",
> path+ncfile
> ncfile=os.path.join(path,ncfile)
> ncfile=Dataset(ncfile, 'r+', 'NETCDF4')
>
> variable=ncfile.variables[ncvariablename][:]
> TIME=ncfile.variables['time'][:]
>
> fillval
Re: [Tutor] Why subclassing exceptions?
On 28/09/11 07:33, Mac Ryan wrote:
raise BaseException('Something is wrong here!')
Never raise BaseException directly!
**I would like to know more on the rationale behind this
guidelines, though.**
raise StandardError('This value should be True.')
does the job in a much more elegant way than:
class ShouldBeTrueError(StandardError):
...
raise ShouldBeTrueError('Doh! An error!')
Can you explain why you think that is "more elegant"?
To me it looks ugly. If there are multiple errors
I need to open up the exception and test against
the message string (with all the dangers of mis-spelling
etc)
Compare:
try: someFuncWithMultipleExceptions()
except StandardError, e:
if e.message == "This value should be True":
makeItTrue()
elif e.message == "This value should be black":
makeItBlack()
except ValueError:
var = raw_input("oops, that's an invalid value, try again")
With
try: someFuncWithMultipleExceptions()
except ShouldBeTrueError:
makeItTrue()
except ShouldBeBlackError:
makeItBlack()
except ValueError()
var = raw_input("oops, that's an invalid value, try again")
The second form is more precise, more robust, and consistent
with the built in exception handling.
Remember that when handling exceptions we should be trying
to recover the situation not just bombing with an error message.
Exceptions should not be thought of as purely about
messages, they are opportunities to recover the situation without the
user even being aware that something went wrong. Only when recovery is
impossible should we bomb out with a message. Otherwise you might as
well do it this way:
if errorDetected:
print "It's all gone terribly wrong"
raise SystemExit
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] map one file and print it out following the sequence
On 28/09/11 04:34, lina wrote: File 1 is: 3 C 1 CUR C19 10.200 12.0110 4 CR1 1 CUR C20 1 -0.060 12.0110 5HC 1 CUR H20 10.060 1.0080 File 2 is: ATOM 2 H20 CUR 1 30.338 28.778 -6.812 1.00 0.00 ATOM 4 C20 CUR 1 31.394 28.922 -7.039 1.00 0.00 ATOM 5 C19 CUR 1 31.790 29.357 -8.323 1.00 0.00 I wish to get: ATOM 5 C19 CUR 1 31.790 29.357 -8.323 1.00 0.00 ATOM 4 C20 CUR 1 31.394 28.922 -7.039 1.00 0.00 ATOM 2 H20 CUR 1 30.338 28.778 -6.812 1.00 0.00 The dictionary is C19 C20 H20 sequence read from file 1 field 5. rearrange the file 2 field 3 following the sequence of C19, C20, H20. OK, so just to confirm: you want to sort file 2 based on the order of field 5 in file 1. So read file2 into a dictionary keyed by field 3 Then read file 1 and output the dictionary entry associated with field 5 So in pseudo code: d = dict() for line in file1: d[ line.split()[2] ] = line for line in file1: print d[ line.split()[4] ] Is that what you want? -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Why subclassing exceptions?
On Wed, 28 Sep 2011 09:03:11 +0100
Alan Gauld wrote:
> Remember that when handling exceptions we should be trying
> to recover the situation not just bombing with an error message.
> Exceptions should not be thought of as purely about
> messages, they are opportunities to recover the situation without the
> user even being aware that something went wrong. Only when recovery
> is impossible should we bomb out with a message.
Thank you Alan for the quick response. I totally see your logic, and
surely I can't (nor I wish to) argue with it in the context you
illustrated.
I have to say - however - that even after a few years of python
development I seldom use exceptions that way: in fact I can only
remember having subclassed error classes once, when I wrote a library
that was intended to be used by third-parties (for the exact same
reasons that you exemplified).
In all other cases (code that doesn't expose an API to third parties)
I consider that either my program works (and thus it can handle all
possible situations) or it does not, in which case - given that nothing
should silently fail - I'm happy for it to scream out loud with a raise
BaseException('').
In fact, I use exceptions only when I can't write an ``assert``
statement concise enough. In the original code to which you initially
reacted I used an exception simply because it was more concise to put
it under the else clause rather then writing an ``assert`` statement
with all the if/else possibility it would have needed.
Is there any reason for which you (or anybody on the list, of course)
think I should avoid doing this?
/mac
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Why subclassing exceptions?
On 28/09/11 10:23, Mac Ryan wrote:
I have to say - however - that even after a few years of python
development I seldom use exceptions that way: in fact I can only
remember having subclassed error classes once, when I wrote a library
that was intended to be used by third-parties (for the exact same
reasons that you exemplified).
That doesn't make it good :-)
You can write a lot of code without using functions or classes or
exceptions. But it doesn't mean it couldn't be improved by adding
those features.
In all other cases (code that doesn't expose an API to third parties)
I consider that either my program works (and thus it can handle all
possible situations) or it does not, in which case - given that nothing
should silently fail - I'm happy for it to scream out loud with a raise
BaseException('').
If all you can do is scream out then raising an exception is mostly a
waste of space. Exceptions are there to be caught and handled. Error
messages are where we should scream out, not the exceptions themselves.
In fact, I use exceptions only when I can't write an ``assert``
But asserts should be used in debugging only. They are dangerous things
to rely on in production code. Unless you are using assert in a wider
context than literal assert() calls?
> reacted I used an exception simply because it was more concise to put
it under the else clause rather then writing an ``assert`` statement
with all the if/else possibility it would have needed.
Using asserts is a form of the if/else type error handling that plagued
programmers during the 70's,80's and even into the 90's (thanks
Microsoft!) and which try/except style exceptions were, in part,
designed to eliminate. The problem with "assert" and if/else style
checking is it greatly complexifies the code structure and makes it much
harder to see the "happy path" flow. Exceptions allow us to code in the
same way we write use cases during analysis:
Precondition check
happy path sequence
exception cases
postcondition check
That makes for more readable and therefore more maintainable code.
It also means we can add new exception handlers as needed without
interfering with the core algorithm structure. (It also means the core
algorithm can be optimised for speed without all the explicit if/else
checks going on, but that should be considered a free bonus not a reason
to adopt exceptions!)
And finally, as you suggest, when code gets reused (and often that
happens to code we didn't expect to reuse!) exceptions make for an
easier and more consistent interface for the reuser (who may be yourself!)
Is there any reason for which you (or anybody on the list, of course)
think I should avoid doing this?
It's perfectly possible to write code the way you are doing but it
involves multiple error mechanisms (because the standard library uses
exceptions) and is less familiar to other programmers. If its only for
your own use then its a moot point, it really becomes significant when
working on collaborative projects or for reuse.
OTOH writing with exceptions takes very few extra keystrokes so why not
just use as intended? ;-)
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Why subclassing exceptions?
Mac Ryan wrote:
I have to say - however - that even after a few years of python
development I seldom use exceptions that way: in fact I can only
remember having subclassed error classes once, when I wrote a library
that was intended to be used by third-parties (for the exact same
reasons that you exemplified).
You don't have to subclass exceptions. You can raise exception classes
that already exist. Most of the time, that's exactly what you should do.
In all other cases (code that doesn't expose an API to third parties)
I consider that either my program works (and thus it can handle all
possible situations) or it does not, in which case - given that nothing
If your program can handle ALL possible situations, that would be a
first for any program written in any language in the entire history of
computing. Well done!
should silently fail - I'm happy for it to scream out loud with a raise
BaseException('').
Well here's the thing. It's your program, you can make it do anything
you like. If you want it to raise TooMuchCoffee exceptions, go right
ahead. But there are standard meanings for exceptions in Python, and you
are ignoring them.
The error message gives you a human readable message. The exception type
tells you the category of error. You are ignoring or abusing that
information channel by mis-using BaseException. Regardless of whether
the exception gets caught or not, the exception type gives the user
valuable information.
Think of it this way: exceptions are like a great big control panel with
warning lights. There's a warning light for "fuel warnings", another one
for "temperature warnings", a third for "did you remember to lock the
front door when you left home", and so forth. Each light can blink in a
pattern, which a human being can look up in the manual to see exactly
what sort of fuel warning: "no fuel in engine 3", say. But even without
reading the detailed message (which sometimes can be fairly cryptic),
the mere fact that it's a fuel warning gives you a lot of useful
information: it's a *fuel* warning, not a flat tire.
You are always using the same "miscellaneous unknown warning" light, for
*everything*:
"miscellaneous unknown warning: out of fuel"
"miscellaneous unknown warning: doors left unlocked"
"miscellaneous unknown warning: temperature too high"
"miscellaneous unknown warning: out of milk"
In fact, I use exceptions only when I can't write an ``assert``
statement concise enough. In the original code to which you initially
reacted I used an exception simply because it was more concise to put
it under the else clause rather then writing an ``assert`` statement
with all the if/else possibility it would have needed.
If you are using asserts for data validation, then your code is broken.
The caller can disable every single assert, and hence remove your data
validation, by simply passing a command line switch when calling your
program.
--
Steven
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Why subclassing exceptions?
>If you are using asserts for data validation, then your code is broken. >The caller can disable every single assert, and hence remove your data >validation, by simply passing a command line switch when calling your >program. To be fair, there are plenty of situations where someone has enough control of their execution environment to prevent that from happening. I agree on principle and for readability/maintainability; if I saw that I would be highly confused as to why asserts were everywhere. Ramit Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology 712 Main Street | Houston, TX 77002 work phone: 713 - 21h6 - 5423 This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Why subclassing exceptions?
On Wed, 28 Sep 2011 10:15:07 -0400 "Prasad, Ramit" wrote: > >If you are using asserts for data validation, then your code is > >broken. The caller can disable every single assert, and hence remove > >your data validation, by simply passing a command line switch when > >calling your program. > > To be fair, there are plenty of situations where someone has enough > control of their execution environment to prevent that from > happening. I agree on principle and for readability/maintainability; > if I saw that I would be highly confused as to why asserts were > everywhere. Thank you Alan, Steve, Ramit for all your answers, very appreciated and useful. I would like to point out that I am not using ``assert`` for data validation. I am using it to understand if my code works. The reason why I prefer asserts over exceptions is just what you pointed out. Keeping building on Steve's simile: when I use asserts in my code, I'm still at the car factory. I'm not trying to communicate anything to a potential driver: I'm just trying to prevent myself to say "the car is ready" if there is a major flow in its design. In other words: rather than creating a specific "EngineerForgotToDesignEngine" warning light, I want the engineer to realise at a much earlier stage that she does need to put an engine on the car before the car is ready for prime time. Maybe the initial example that generated this thread was misleading, as a function is a typical example of a code that never knows what parameters will be passed in. All that said, I totally see your point and I swear that from now on I will give a deeper thought to what to write after the word "raise"! :) Thank you very much once more, /mac ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
