Mutable strings

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Gordon Airport

    #16
    Re: Mutable strings - symetry with list types

    Dennis Lee Bieber wrote:
    [color=blue]
    > Prior to the creation of string methods, you'd have done
    >
    > import string
    >
    > ... string.join(bla h, ' ')
    >
    >[/color]

    Yes, it looks even worse that way. I guess that it's just rare to use a
    literal in the code as an object...I'm having trouble thinking of other
    situations where you use the ability, but I won't pretend to be an
    expert in the language.
    [color=blue][color=green]
    >>not obvious and it looks like a hack, IMO. Plus you can't do
    >>somestring = '%s %s %s' % [ 'nine', 'bladed', 'sword' ][/color]
    >
    >
    > If you know both sides have equal numbers of terms (the %s matches the
    > number of entries in the list) you /can/ do a minor modification to
    > that line:
    >
    > somestring = "%s %s %s" % tuple(["nine", "bladed", "sword"])[/color]

    I just found it strange that you couldn't do it directly without
    'casting'...Pro bably doesn't come up much anyway. Now that I think about
    it it's an assignment so it's not really relevant to the discussion of
    mutable strings.
    [color=blue]
    >
    > Of course, you could also create a dictionary and store those as
    > attributes (though to my mind, you have a sword with one modifier
    > "nine-bladed"; as is it could be interpreted to mean nine
    > bladed-sword(s) -- though all swords are bladed...).
    >
    >[color=green][color=darkred]
    >>>>weapon = {"type":"Sword" , "attribute":"bl aded", "modifier":"nin e"}
    >>>>weapon[/color][/color]
    >
    > {'attribute': 'bladed', 'modifier': 'nine', 'type': 'Sword'}
    >[color=green][color=darkred]
    >>>>somestrin g = "%(modifier )s %(attribute)s %(type)s" % weapon
    >>>>somestrin g[/color][/color]
    >
    > 'nine bladed Sword'
    >[/color]

    All very handy, but I don't see how it could be done better with mutable
    strings. I need to come up with some examples of applications.

    Comment

    • Andrew Dalke

      #17
      Re: Mutable strings

      Rob Tillotson:[color=blue]
      > There already is one: array. Mutable blocks of bytes (or shorts,
      > longs, floats, etc.), usable in many places where you might otherwise
      > use a string (struct.unpack, writing to a file, etc.).[/color]

      Even regular expressions
      [color=blue][color=green][color=darkred]
      >>> import array, re
      >>> t = "When in the course of human events"
      >>> s = array.array("c" , t)
      >>> pat = re.compile(r"([aeiou]{2,})")
      >>> m = pat.search(s)
      >>> m.group(1)[/color][/color][/color]
      array('c', 'ou')[color=blue][color=green][color=darkred]
      >>>[/color][/color][/color]

      Andrew
      dalke@dalkescie ntific.com


      Comment

      • Hans-Joachim Widmaier

        #18
        Re: Mutable strings

        Am Mon, 22 Sep 2003 15:26:56 +0200 schrieb Alex Martelli:
        [color=blue]
        > On Monday 22 September 2003 02:50 pm, Jeff Epler wrote:[color=green]
        >> On Mon, Sep 22, 2003 at 12:31:58PM +0000, Alex Martelli wrote:[color=darkred]
        >> > But, there IS one! So, hat's wrong with it...?![/color]
        >>
        >> People seem to love to have literals for things. Otherwise, they feel
        >> that a type is second-class.[/color]
        >
        > 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>{<b alanced-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").[/color]

        [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.

        Comment

        Working...