Re: stylistic question

23 views
Skip to first unread message

William Stein

unread,
Feb 7, 2009, 3:33:25 PM2/7/09
to Phaedon Sinis, sage-f...@googlegroups.com
On Sat, Feb 7, 2009 at 8:55 AM, Phaedon Sinis <phaedo...@gmail.com> wrote:
> Hi William,
> hope all is well!
> I'm not sure why, but I woke up thinking about my FinanceDate library, and
> it just occurred to me that I should ask your guidance.
> When I first wrote this for work, I put all the functions directly into a
> module, so I would use the code as follows...
>>>> addBusinessDays( datetime.date(2009, 2, 6) , 5 )
> datetime.date(2009, 2, 13)
> Because I've been mostly dealing with C# since SD9, I have been rewriting
> this for Sage purposes in a class:
> class FinanceDate(datetime.date):
> pass # code goes here
> so then the user would write
>>>> FinanceDate(2009, 2, 6).addBusinessDays(5)
> datetime.date(2009, 2, 13)
> In both cases, I have to assign the result to a new variable, because
> datetime.date does not allow its properties "year", "month", and "day" to be
> modified.
> Is this just a style question or does it have deeper implications for
> development of the libraries? And in either case, should I prefer one over
> the other?
> best
> Phaedon

I've cc'd this to the sage-finance Sage development group, which you
might want to subscribe to:
http://groups.google.com/group/sage-finance

Regarding your question:

1. It should be FinanceDate(2009, 2, 6).add_business_days(5)
since in Python people usually use CamelCase for class constructors,
but lower case and underscores for function names. It's just the
usual convention.

2. What you are doing -- returning a new object -- is generally a
good idea, though of course it depends on context. If you don't,
imagine code like this:

sage: foo = FinanceDate(2009,2,6)
sage: foo
datetime.date(2009, 2, 6)
sage: o = find_optimum(bar, foo)
sage: foo
datetime.date(2009, 2, 14)

... suddenly foo has a completely different value just because you happened
to call some function, which happened to internally muck with foo's
value. By making the date object immutable, this possible confusing
side-effect is avoided.

In C++ there is a const keyword that helps avoid this problem. But in
Python there is not const -- anything passed into a function is just a
reference, and has to "protect itself".

How's your finance package work going?

William

Reply all
Reply to author
Forward
0 new messages