Mutable strings

[Hans-Joachim Widmaier]

Am Mon, 22 Sep 2003 15:26:56 +0200 schrieb Alex Martelli:

> On Monday 22 September 2003 02:50 pm, Jeff Epler wrote:
>> On Mon, Sep 22, 2003 at 12:31:58PM +0000, Alex Martelli wrote:
>> > But, there IS one!  So, hat's wrong with it...?!
>>
>> People seem to love to have literals for things.  Otherwise, they feel
>> that a type is second-class.
> 
> Sure.  I have no problem deeming "mutable strings" (array of bytes)
> to be "second-class" in some vague sense, since their use is so rare
> and the need for literals of that type even rarer; lacking literals for,
> e.g., sets.Set "troubles" me far more;-).
> 
> I do keep daydreaming of some "user-defined semiliteral syntax"
> such as, e.g. <identifier>{<balanced-parentheses tokens>} to
> result in a call to (e.g.) <identifier>.__literal__ with a list (or other
> sequence) of tokens as the argument, returning whatever that
> call returns.  But perhaps it isn't that good an idea after all (it
> does imply the __literal__ classmethod or staticmethod doing
> some sort of runtime compilation and execution of those tokens,
> and opens the doors to the risk of some seriously nonPythonic
> syntax for such "literals-initializers").

[Sorry for replying so late]

After writing what I did, I kept thinking about the issue. I finally
realized the same thing - it wasn't so much the missing datatype, as you
can use array but the missing literals. Having to construct constant
values at runtime doesn't strike me as nice. I'm coming from the embedded
world (hmm, that's not entirely true, as I'm not leaving it), and doing
something efficiently is a big concern there, so doing something at
runtime what you could do upfront is considered a bad thing.

Python doesn't have and cannot be the perfect language for just
everything. But even without "mutable strings", why does it have to be so
handy even for manipulating binaries then?

I'll get over it and give array a try.

Thanks to Jeff for finding the gist of it and Alex for his analysis.
It helps.

Hans-J.