[Zope3-dev] Notations for paths

[Guido van Rossum]

> Great!  Now in addition to parsing errors, we can have errors caused
> by accidentally modifying shared mutable objects.  Zope 3
> applications will then be even *more* fun to debug than Zope 2
> applications...  if you're a masochist, anyway.  ;)
> 
> IMO, immutability is an application framework's first line of
> defense against "how the heck is *that* happening?" errors by the
> framework's users.  Raising errors early (as would happen when an
> API tries to coerce an invalid location object) is the second.
> 
> I'd say I don't really care about this because I'm not the one
> who'll have to support Zope 3, but that's not really the case.  I
> *will* be the person supporting Zope 3 for my development staff, and
> occasionally people in other parts of the company I work for as
> well.  That's why I'm -0 on using simple types where a
> framework-specific interface is desirable, and -1 or more on using
> mutable types anywhere that "value" semantics are desired.  These
> are both near the top of my hypothetical list of the "top 10 ways to
> mess up users of a framework and make their programs hard to debug".

I'm all for using strings as the canonical representation of locations
or paths.  Tuples (or lists) are clumsy for that.  However they are
useful to hold broken-down path components -- and there I'm not
worried about sharing.

--Guido van Rossum (home page: http://www.python.org/~guido/)