[Chicago] FW: Playing with generics

[RCRamsdell@gldd.com]

Two concerns with this:
It is fairly particular to the case of 2-tuple versus x and y input.  It
is not that easily extensible to handle, for example, xyz inputs, or
zero inputs, in which case the method should pull from the object.

Good call on the scale variable.  After reading your code I realized
that I do 180/pi or pi/180 (conversion to and from radians and degrees)
in a number of places.  But I already have a perfectly good
UnitConversions module from another project with a variable deg_to_rad
that I should use instead.  I feel a refactoring coming on.

Robert

> -----Original Message-----
> From: chicago-bounces at python.org 
> [mailto:chicago-bounces at python.org] On Behalf Of Michael Tobis
> Sent: Thursday, November 17, 2005 2:22 PM
> To: The Chicago Python Users Group
> Subject: Re: [Chicago] FW: Playing with generics
> 
> 
> If I understand what you are after correctly, I would prefer 
> functional programming for this sort of thing.
> 
> How about:
> 
> 
> ####
> 
> from operator import add
> 
> def toSequence(item):
>    try: iter(item)
>    except: return [item]
>    else: return item
> 
> def Flatten(listOfListsAndScalars):
> 
>    # nonrecursive: handles only one level of list nesting
>    # see also 
> http://aspn.activestate.com/ASPN/Mail/Message/python-tutor/230
2137

   return reduce(add,[toSequence(item) for item in
listOfListsAndScalars])

##########
from math import atan, pi
scale = 180./pi

def RobertCalc(*args):
    xa,ya = Flatten(args)[:2]
    return atan(xa/ya)*scale

##########
# -mt
_______________________________________________
Chicago mailing list
Chicago at python.org http://mail.python.org/mailman/listinfo/chicago