[Twisted-Python] twisted.positioning: status report and request for comments/feedback

Glyph Lefkowitz glyph at twistedmatrix.com
Thu Jul 30 10:20:38 EDT 2009

On Thu, Jul 30, 2009 at 10:14 AM, Laurens Van Houtven <lvh at laurensvh.be>wrote:

> Oh, by the way: would you guys expect NMEASentences to be immutable
> objects?

Yes, but by convention, not necessarily by enforcement.  The really
important thing is that the framework should not share or mutate
NMEASentence objects internally.

> I suppose it makes sense, but maybe I've been thinking too much
> Haskell recently. After all, an NMEASentence is an alternative way of
> describing a past event (namely, something that a GPS told you).
> Changing it would be like changing history, you can't do that -- even
> if you're really replacing it with the same data but encoded
> differently.

> I know that you can't *really* make immutable python objects, but
> they'd be immutable in the sense that:
> sentence.latitude, sentence.longitude = Coordinate(50.49),
>  Coordinate(-3.34)
> ... wouldn't work (specifically, latitude and longitude aren't really
> attributes of the class, but things you can get with my __getattr__ --
> and I don't set __setattr__, so you'd need to know the guts of the
> class, which currently are public but I might make private before the
> code review).

Ugh.  __getattr__, really?  Is that necessary?  It would be nice not to rely
on this kind of magic.

For NMEASentence, I don't really care, because I hope I'm never going to
write an application that actually deals with one of those.  But if you have
a Point object or something like that, then I think it's important to have a
return-a-modified-copy API if mutation is actually disallowed.  For example,
point.moveTo(50.49, -3.34) => a new Point.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://twistedmatrix.com/pipermail/twisted-python/attachments/20090730/a0aaa18e/attachment.htm 

More information about the Twisted-Python mailing list