can it be shorter?
steve at REMOVE-THIS-cybersource.com.au
Tue Jun 9 01:44:10 CEST 2009
On Mon, 08 Jun 2009 12:57:58 -0700, Aaron Brady wrote:
> Why won't Python permit:
> url.endswith( '/' ) or url.append( '/' )
(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
> 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
> 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.
More information about the Python-list