Extract String From Enclosing Tuple

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • rshepard@nospam.appl-ecosys.com

    #1

    Extract String From Enclosing Tuple

    I'm a bit embarrassed to have to ask for help on this, but I'm not finding
    the solution in the docs I have here.

    Data are assembled for writing to a database table. A representative tuple
    looks like this:

    ('eco', "(u'Roads', )", 0.0739698873013 48305)

    Pysqlite doesn't like the format of the middle term:
    pysqlite2.dbapi 2.InterfaceErro r: Error binding parameter 1 - probably
    unsupported type.

    I want to extract the 'Roads', part from the double-quoted enclosing
    tuple. The unicode part should be automatically removed when the string is
    printed, but I suspect it's the double quotes and extra parentheses that are
    the problem. I know that tuples are immutable, but I thought that I could
    slice it. If so, I'm not doing it correctly, because each attempt results in
    TypeError: unsubscriptable object

    Even when I assign that middle term to a variable before assembling the
    tuple for insertion in the database, I just cannot get the job done. Whether
    in the tuple of three terms or by itself, I haven't applied the proper
    technique.

    Insight appreciated.

    Rich
  • Bruno Desthuilliers

    #2
    Re: Extract String From Enclosing Tuple

    rshepard@nospam .appl-ecosys.com a écrit :
    I'm a bit embarrassed to have to ask for help on this, but I'm not finding
    the solution in the docs I have here.
    >
    Data are assembled for writing to a database table. A representative tuple
    looks like this:
    >
    ('eco', "(u'Roads', )", 0.0739698873013 48305)
    >
    Pysqlite doesn't like the format of the middle term:
    pysqlite2.dbapi 2.InterfaceErro r: Error binding parameter 1 - probably
    unsupported type.
    >
    I want to extract the 'Roads', part from the double-quoted enclosing
    tuple. The unicode part should be automatically removed when the string is
    printed, but I suspect it's the double quotes and extra parentheses that are
    the problem. I know that tuples are immutable, but I thought that I could
    slice it. If so, I'm not doing it correctly, because each attempt results in
    TypeError: unsubscriptable object
    Where do you get your data from ? MHO is that you'd better handle the
    problem at the source (ie : dont put a string representation of a tuple
    in your data) instead of trying to fix it afterward.

    Comment

    • attn.steven.kuo@gmail.com

      #3
      Re: Extract String From Enclosing Tuple

      On Feb 28, 12:40 pm, rshep...@nospam .appl-ecosys.com wrote:
      I'm a bit embarrassed to have to ask for help on this, but I'm not finding
      the solution in the docs I have here.
      >
      Data are assembled for writing to a database table. A representative tuple
      looks like this:
      >
      ('eco', "(u'Roads', )", 0.0739698873013 48305)
      >
      Pysqlite doesn't like the format of the middle term:
      pysqlite2.dbapi 2.InterfaceErro r: Error binding parameter 1 - probably
      unsupported type.
      >
      I want to extract the 'Roads', part from the double-quoted enclosing
      tuple.
      (snipped)



      Perhaps something like:
      >>t = ('eco', "(u'Roads', )", 0.0739698873013 48305)
      >>t2 = eval(t[1], { '__builtins__' : {} }, {} )
      >>t2
      (u'Roads',)
      >>t2[0].encode('ascii' )
      'Roads'

      >>import itertools
      >>tuple(itertoo ls.chain((t[0], t2[0].encode('ascii' )), t[2:]))
      ('eco', 'Roads', 0.0739698873013 48305)
      >>tuple(itertoo ls.chain((t[0], (t2[0].encode('ascii' ),)), t[2:]))
      ('eco', ('Roads',), 0.0739698873013 48305)


      --
      Hope this helps,
      Steven

      Comment

      • Ben Finney

        #4
        Re: Extract String From Enclosing Tuple

        rshepard@nospam .appl-ecosys.com writes:
        Data are assembled for writing to a database table. A
        representative tuple looks like this:
        >
        ('eco', "(u'Roads', )", 0.0739698873013 48305)
        You refer to the second item as "a tuple" later, but it's not; it's
        now just a string (not even a unicode string). Whatever has assembled
        these has effectively lost the structure of the data and you are now
        left with three items in a tuple: string, string, float.

        Some RDBMSs can store a structure of multiple values in one value;
        SQLite cannot. The usual solution for this limitation is to take these
        structural values and store the component values as separate rows of a
        different table, and have each of those rows refer back to the
        identifying key of the original table so they can be joined easily.

        E.g., I might conceptually think of order records as the following
        tuples, with further tuples-of-tuples for the items on each order:

        orders = (
        # fields: id, cust_code, date, order_items
        (1, "cust1234", "2007-02-15", (("item002", 1), ("item005", 3), ("item007", 1))),
        (2, "cust4567", "2007-02-19", (("item001", 5), ("item005", 2))),
        )

        Since I can't store those as-is in SQLite, I would need to restructure
        the tables: separate the "order items" to separate rows in a dedicated
        table, and refer to the "order" table key in each "order item" row.

        orders = (
        # fields: id, cust_code, date
        (1, "cust1234", "2007-02-15"),
        (2, "cust4567", "2007-02-19"),
        )

        order_items = (
        # fields: id, order_id, item_code, quantity
        (1, 1, "item002", 1),
        (2, 1, "item005", 3),
        (3, 1, "item007", 1),
        (4, 2, "item001", 5),
        (5, 2, "item005", 2),
        )

        Then you can use SQL JOIN clauses as necessary, with the
        order_item.orde r_id field a foreign key into the order table.

        --
        \ "I moved into an all-electric house. I forgot and left the |
        `\ porch light on all day. When I got home the front door wouldn't |
        _o__) open." -- Steven Wright |
        Ben Finney

        Comment

        • Ben Finney

          #5
          Re: Extract String From Enclosing Tuple

          Ben Finney <bignose+hate s-spam@benfinney. id.auwrites:
          orders = (
          [...]
          )
          >
          order_items = (
          [...]
          )
          For clarity, these sequences of records should be lists (with each
          item being a tuple containing the record fields), not tuples.

          A tuple implies a meaning associated with each position in the
          sequence (like a record with a positional meaning for each field), a
          list implies the opposite (a sequence with order but not meaning
          associated with each position).

          --
          \ "If you were going to shoot a mime, would you use a silencer?" |
          `\ -- Steven Wright |
          _o__) |
          Ben Finney

          Comment

          • Bjoern Schliessmann

            #6
            Re: Extract String From Enclosing Tuple

            Ben Finney wrote:
            A tuple implies a meaning associated with each position in the
            sequence (like a record with a positional meaning for each field),
            a list implies the opposite (a sequence with order but not meaning
            associated with each position).
            Explain. I know tuples as immutable lists ...

            BTW, don't confuse python tuples with tuples from mathematics.

            Regards,


            Björn

            --
            BOFH excuse #214:

            Fluorescent lights are generating negative ions. If turning them off
            doesn't work, take them out and put tin foil on the ends.

            Comment

            • Ben Finney

              #7
              Tuples vs Lists: Semantic difference (was: Extract String FromEnclosing Tuple)

              Bjoern Schliessmann <usenet-mail-0306.20.chr0n0s s@spamgourmet.c omwrites:
              Ben Finney wrote:
              >
              A tuple implies a meaning associated with each position in the
              sequence (like a record with a positional meaning for each field),
              a list implies the opposite (a sequence with order but not meaning
              associated with each position).
              >
              Explain.
              Well, since you ask so politely :-)
              I know tuples as immutable lists ...
              That's a common misconception.

              Tuples are intended for use as heterogeneous data structures: every
              index in the sequence *means* something, a semantic meaning applied to
              the item at that index. It's for this reason that a tuple is
              immutable: removing items, inserting them in the middle, etc. would
              imply that the index doesn't have semantic meaning for the structure,
              which is not true.

              Lists are intended for use as homogeneous sequences: not that every
              value is of the same type, but that a particular index in the sequence
              doesn't *mean* anything about the semantic interpretation of the item
              at that position. It's for this reason that a list is mutable: since
              the index of an item has no semantic meaning, inserting new items or
              removing them from anywhere in the sequence doesn't alter the meaning
              of the structure.

              James Tauber explains further:

              <URL:http://jtauber.com/blog/2006/04/15/python_tuples_a re_not_just_con stant_lists>

              --
              \ "You can be a victor without having victims." -- Harriet Woods |
              `\ |
              _o__) |
              Ben Finney

              Comment

              • George Sakkis

                #8
                Re: Tuples vs Lists: Semantic difference (was: Extract String From Enclosing Tuple)

                On Feb 28, 10:45 pm, Ben Finney <bignose+hate s-s...@benfinney. id.au>
                wrote:
                Bjoern Schliessmann <usenet-mail-0306.20.chr0n.. .@spamgourmet.c omwrites:
                I know tuples as immutable lists ...
                >
                That's a common misconception.
                And this catch phrase, "that's a common misconception", is a common
                aping of the BDFL's take on this. As several long threads have shown,
                it is a highly controversial topic and claiming that one side has
                misconceived it doesn't make it more true than a Catholic claiming
                that Protestants are misconceived about the True Christianity or vice
                versa.
                Tuples are intended for use as heterogeneous data structures: every
                index in the sequence *means* something, a semantic meaning applied to
                the item at that index. It's for this reason that a tuple is
                immutable: removing items, inserting them in the middle, etc. would
                imply that the index doesn't have semantic meaning for the structure,
                which is not true.
                >
                Lists are intended for use as homogeneous sequences: not that every
                value is of the same type, but that a particular index in the sequence
                doesn't *mean* anything about the semantic interpretation of the item
                at that position. It's for this reason that a list is mutable: since
                the index of an item has no semantic meaning, inserting new items or
                removing them from anywhere in the sequence doesn't alter the meaning
                of the structure.
                >
                James Tauber explains further:
                >
                <URL:http://jtauber.com/blog/2006/04/15/python_tuples_a re_not_just_con stan...>
                Nice, that's a good summary of the straw man arguments about the
                "true" distinction between tuples and lists. Now can you please
                explain why an "heterogene ous data structure":
                1) does not support __setitem__, changing the value of an existing
                item from 3 to 4,
                2) supports iteration over its ("heterogeneneo us") elements, but not
                an index() method, and
                3) why using indices rather than names for implied semantics is a good
                idea anyway.

                As for addition/removal/insertion of elements not making sense for a
                heterogeneous data structure, have you heard of database schema
                change ?

                Heterogeneous data structures are well known for several decades now;
                they are commonly spelled "records" though, not tuples, and have a
                more reasonable API to support their semantics.

                George

                Comment

                • Bjoern Schliessmann

                  #9
                  Re: Tuples vs Lists: Semantic difference

                  Ben Finney wrote:
                  Bjoern Schliessmann <usenet-mail-0306.20.chr0n0s s@spamgourmet.c om>
                  >Explain.
                  >
                  Well, since you ask so politely :-)
                  I admit, sometimes I'm a little short-spoken ;)
                  >I know tuples as immutable lists ...
                  >
                  That's a common misconception.
                  [...]
                  Thanks for pointers, there's more to it than I suspected.

                  Regards,


                  Björn

                  --
                  BOFH excuse #384:

                  it's an ID-10-T error

                  Comment

                  • bearophileHUGS@lycos.com

                    #10
                    Re: Tuples vs Lists: Semantic difference (was: Extract String From Enclosing Tuple)

                    George Sakkis, I agree with the things you say.
                    Sometimes you may have a sequence of uniform data with unknown len (so
                    its index doesn't have semantic meaning). You may want to use it as
                    dict key, so you probably use a tuple meant as just an immutable list.
                    I don't know Ruby, but I think it allows such purposes with a freezing
                    function.

                    Bye,
                    bearophile

                    Comment

                    • rshepard@nospam.appl-ecosys.com

                      #11
                      Re: Extract String From Enclosing Tuple

                      On 2007-02-28, attn.steven.kuo @gmail.com <attn.steven.ku o@gmail.comwrot e:
                      >>>import itertools
                      >>>tuple(iterto ols.chain((t[0], t2[0].encode('ascii' )), t[2:]))
                      ('eco', 'Roads', 0.0739698873013 48305)
                      Steven,

                      As suggested in the previous article, I handled it where the values are
                      read from the list retrieved from the database. By adding an additional
                      index of [0] the format is correct.

                      Thank you all very much,

                      Rich

                      Comment

                      • MonkeeSage

                        #12
                        Re: Tuples vs Lists: Semantic difference (was: Extract String From Enclosing Tuple)

                        On Mar 1, 5:02 am, bearophileH...@ lycos.com wrote:
                        I don't know Ruby, but I think it allows such purposes with a freezing
                        function.
                        In ruby all objects can be frozen (freeze is a method on Object, from
                        which all other objects derive), not just Arrays (Arrays == lists in
                        python; ruby has no built-in container equiv. to tuple). But that's
                        more of an implementation detail rather than anthing to do with the
                        structure/semantics of a certain type of object (e.g., a String can be
                        frozen, a Hash can be frozen, &c).

                        Regards,
                        Jordan

                        Comment

                        • Ben Finney

                          #13
                          Re: Tuples vs Lists: Semantic difference

                          "George Sakkis" <george.sakkis@ gmail.comwrites :
                          On Feb 28, 10:45 pm, Ben Finney wrote:
                          >
                          Tuples are intended for use as heterogeneous data structures [...]
                          Lists are intended for use as homogeneous sequences [...]
                          >
                          Nice, that's a good summary of the straw man arguments about the
                          "true" distinction between tuples and lists.
                          I'm not sure why you say it's a "straw man argument". I'm presenting
                          *my* understanding of a position that I also share, in order to defend
                          it; a straw man argument is a misrepresentati on of *another party's*
                          position for the purpose of appearing to attack that party's position.

                          straw man fallacy, red herring, informal fallacy, informal fallacies, logical fallacy, logical fallacies, critical thinking


                          Whose position have I misrepresented and attacked?
                          Now can you please explain why an "heterogene ous data structure":
                          1) does not support __setitem__, changing the value of an existing
                          item from 3 to 4,
                          In the case of a tuple, because the "value" is conceptually the entire
                          tuple. To change one of its items would be to create a new value -- so
                          that's what is supported.
                          2) supports iteration over its ("heterogeneneo us") elements, but not
                          an index() method
                          An index() method would imply that the index of an item has some
                          meaning, such that extracting a single item is meaningful. Since a
                          tuple represents a single conceptual structural value, to extract one
                          item is something to be done at the same time as extracting all the
                          others.
                          3) why using indices rather than names for implied semantics is a
                          good idea anyway.
                          You've already shown that one *doesn't* use an index for accessing
                          items in a tuple.
                          As for addition/removal/insertion of elements not making sense for a
                          heterogeneous data structure, have you heard of database schema
                          change ?
                          A database schema change is not an operation one performs with the
                          expectation that the tuples will remain the same. Thus, one would
                          expect to discard the old tuples as obsolete and retrieve them from
                          the relation again, getting new tuples.
                          Heterogeneous data structures are well known for several decades
                          now; they are commonly spelled "records" though, not tuples, and
                          have a more reasonable API to support their semantics.
                          Python doesn't natively support relational schema operations. It does
                          natively support tuples. I never professed that the two were the same,
                          and don't accept that they should be.

                          --
                          \ "I have never made but one prayer to God, a very short one: 'O |
                          `\ Lord, make my enemies ridiculous!' And God granted it." -- |
                          _o__) Voltaire |
                          Ben Finney

                          Comment

                          Working...