Extract String From Enclosing Tuple

[rshepard]

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]

rs******@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.

[attn.steven.kuo]

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

[Ben Finney]

rs******@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

[Ben Finney]

Ben Finney <bi************ ****@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

[Bjoern Schliessmann]

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.

[Ben Finney]

Bjoern Schliessmann <us************ **************@ spamgourmet.com writes:

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

[George Sakkis]

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

[Bjoern Schliessmann]

Ben Finney wrote:

Bjoern Schliessmann <us************ **************@ spamgourmet.com >

>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

[bearophileHUGS]

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