On Mon, 08 Jun 2009 12:57:58 -0700, Aaron Brady wrote: > Why won't Python permit: > > url.endswith( '/' ) or url.append( '/' ) > > ?
Because: (1) Strings are immutable, so that won't work. (2) Even if it did, you're programming by side-effect, which is bad style often leading to bugs, and so should be avoided. > Should it? Heavens no! It's bad enough that similar expressions are allowed for lists. Just because they're allowed, doesn't mean we should use them! > Do we find it just as concise and clear? No. It *looks* like a boolean expression which is produced then thrown away uselessly. If not for append() on lists having a side-effect, I'd call it an expensive no-op. > Does it > outweigh the priority of the immutability of strings? Certainly not. Special cases aren't special enough to break the rules. Strings have nice consistent behaviour. You're suggesting making their behaviour inconsistent. > It works on > lists, for example. A sole mutating operation could create a highly and > finely tempered compromise with immutability. You're not thinking it through. You can't say "strings are immutable, except for append, which mutates them". If you allow *one* mutable operation, then the type is mutable, full stop. > Would it be 'append'? > > I like Scott's and MRAB's idea for slicing, not indexing, the last > character. > > The most literal translation of the original natural language is: > >>>> #ensure that the url ends with a '/' >>>> ensure( url, string.endswith, '/' ) > > (Is it not?) But the parameters aren't sufficient to define 'ensure' > generally, and it won't be able to mutate 'url' regardless. This suggestion appears to be a pie-in-the-sky impractical suggestion. It requires a function ensure() with close to human intelligence to "do what I mean". As such, I can't take it seriously. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
