On 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Another potential generic function use case that occurred to me is the open() > builtin. > > If that was extensible, the discussion about providing a nice filesystem path > abstraction in the standard lib wouldn't need to waste any time on the > question of whether or not to inherit from unicode - it would just register a > new open() signature for path objects.
It needn't waste time on that question anyway -- the only sensible answer is no. > Ditto for if we later added objects to represent URLs/URIs. I'm not sure I follow this whole use case. Different VFSs probably all represent their pathnames as strings (at some level) so the type wouldn't be a useful differentiator. If you already have a path object specific to a VFS (or one for the URL space), the open operation should just be a method on the path object. Generic/overloaded functions (of the kind dispatched on the argument type(s)) mainly have a place when the operation is defined separate from the object. That's not a reasonable assumption in your use case -- the path object is defined in close coordination with the open() implementation so there's no decoupling requirement; a regular method is fine. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
