Hi Alan,
A lot of great guidance here!
I'm stepping back to simply return the DealID from the XML using the
concept of a class. My code results in exit code 0 but doesn't print
any results. Could you give me a hint where I'm missing something?
Thank you,
Daryl
root = tree.getroot()
class Deal:
def __init__(self, rt):
for deal in rt.findall("Deals/Deal"):
self.dealID = deal.get("DealID")
def __str__(self):
return self.dealID
def __iter__(self):
return self.dealID
def __next__(self):
if self.dealID is not None:
print(self.dealID)
else:
raise StopIteration
Deal(root)
On Wed, Jul 4, 2018 at 10:53 AM Alan Gauld via Tutor wrote:
>
> On 04/07/18 12:08, Daryl Heppner wrote:
>
> > If you have any suggestions for continued self-learning (books,
> > courses, etc.) I'd appreciate any tips.
>
> So far as OOP goes you can't go far wrong with the latest version
> of Grady Booch's OOAD book. I've read both the previous versions
> and the latest update is the best yet.
>
> > A bit of context, in case you're curious - we're parsing the XML for
> > load into a T SQL database for reporting purposes which is why I've
> > parsed each value to a unique "cell". The print statement is merely a
> > QA step before ultimately making use of the pyodbc method.
>
> I guessed as much.
>
> As for the database inserts I'd consider making them part of the
> class init method, so once you create the new class instance
> it automatically saves itself (or updates if the ID already
> exists?)
>
> > The need to extrapolate the full rent schedule is to address a few
> > reporting needs. Free Rent, where applicable, is not expressed as a
> > dollar value with a specific date. Rather, it is described as a
> > percentage of Base Rent with a reference to the month in which it
> > applies. A lease can have multiple Free Rent periods which may or may
> > not be consecutive and there are several examples where a Free Rent is
> > applied in the 2nd month and again in the 14th month which means that
> > the dollar value of the Free Rent could be different if a rent step
> > occurs at the end of the first year.
>
> Put the calculations as methods into the corresponding classes.
> If necessary break them up so each class does only its own bit
> of the calculation. Remember the adage that "objects do things to
> themselves". If an object owns a piece of data it should be the
> thing that operates (including doing calculations) on that data.
> Calculations are operations on objects not objects in their
> own right. (Unless you are building a calculation framework,
> like Matlab say...)
>
> One of the most common OOP anti-patterns is having some kind of
> calculator object that fetches data from all the surrounding
> objects, does a complex calculation then stores the result
> into some other object.
>
> Instead the calculation should commence in the target object and it
> should ask each of the supplier objects to do their own bits only
> returning to the target the end result of their subcalculation.
> The target object should, in turn, only be performing calculations
> on the results returned plus the data actually stored in the
> target itself. Of course it is not always that clean but if
> the object data is partitioned well it should be pretty close.
>
> But it takes most non-OOP programmers a little time to turn their
> thinking inside out like that. So don't sweat if it feels
> unnatural to start with.
>
> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
> ___
> Tutor maillist - Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
