We did this once and had to revert because it broke backward compatibility. I guess we can try again but the object must derive type string.
On Jan 12, 10:43 am, Jonathan Lundell <[email protected]> wrote: > On Jan 12, 2012, at 8:33 AM, Anthony wrote: > > > > > > > > > > > On Thursday, January 12, 2012 10:59:09 AM UTC-5, Jonathan Lundell wrote: > > It's an interesting idea, but URL just returns a string, and aside from > > being a fairly big rewrite, it's likely that it would break existing code > > that relies on it being a string. > > > You could create your own object that takes the same arguments as URL and > > stores them as attributes, and whose __str__ and __repr__ functions are the > > actual call to URL(). > > > Perhaps this isn't advisable or worthwhile, but maybe we could subclass str > > so URL still returns a string but can also have attributes to store the > > controller, function, etc. > > > class URL(str): > > def __new__(cls, a, c, f, etc.): > > [build url string as usual] > > url = str.__new__(cls, url_string) > > url.controller = controller > > url.function = function > > etc. > > return url > > David also wants to be able to edit the attributes of the resulting object, > with the results reflected in the string, so it'd need to be a more elaborate > object, hence the need for lazy evaluation via __str__. > > Setting that aside, though, your idea has the advantage of being compatible > with the existing URL, while my version requires a separate object. (In > yours, it'd be good to make the stored attributes read-only, to guard against > someone assuming that they could be usefully edited.)
