[Zope3-dev] Notations for paths
Jim Fulton
jim@zope.com
Fri, 20 Dec 2002 10:40:15 -0500
Guido van Rossum wrote:
>>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.
Me too. Let's make strings the canonical representation
and make sewquences no longer cacnonical.
The string format for paths must be consistent with expections that
people have from dealing with paths in other systems (e.g. file paths
and urls). Absolute paths start with '/'.
> 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.
Right, if a system finds sequences convenient internally, that's fine
and it can use whatever convention for using sequences it
finds conventient.
Jim
--
Jim Fulton mailto:jim@zope.com Python Powered!
CTO (888) 344-4332 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org