can it be shorter?

[Steven D'Aprano]

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