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.073969887301348305)

Pysqlite doesn't like the format of the middle term:
pysqlite2.dbapi2.InterfaceError: 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]

(e-mail address removed)-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.073969887301348305)
>
Pysqlite doesn't like the format of the middle term:
pysqlite2.dbapi2.InterfaceError: 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]

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.073969887301348305)

Pysqlite doesn't like the format of the middle term:
pysqlite2.dbapi2.InterfaceError: 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.073969887301348305)
t2 = eval(t[1], { '__builtins__' : {} }, {} )
t2 (u'Roads',)
t2[0].encode('ascii')

'Roads'

import itertools
tuple(itertools.chain((t[0], t2[0].encode('ascii')), t[2:]))

('eco', 'Roads', 0.073969887301348305)

tuple(itertools.chain((t[0], (t2[0].encode('ascii'),)), t[2:]))

('eco', ('Roads',), 0.073969887301348305)

 

[Ben Finney]

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

('eco', "(u'Roads',)", 0.073969887301348305)

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.order_id field a foreign key into the order table.

 

[Ben Finney]

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

 

[Bjoern Schliessmann]

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

 

[Ben Finney]

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_are_not_just_constant_lists>

 

[George Sakkis]

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

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 "heterogeneous data structure":
1) does not support __setitem__, changing the value of an existing
item from 3 to 4,
2) supports iteration over its ("heterogeneneous") 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]

Bjoern Schliessmann <[email protected]>

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

 

[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

 

[rshepard]

import itertools
tuple(itertools.chain((t[0], t2[0].encode('ascii')), t[2:]))

('eco', 'Roads', 0.073969887301348305)

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

 

[MonkeeSage]

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

 

[Ben Finney]

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 misrepresentation of *another party's*
position for the purpose of appearing to attack that party's position.

http://www.fallacyfiles.org/strawman.html

Whose position have I misrepresented and attacked?

Now can you please explain why an "heterogeneous 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 ("heterogeneneous") 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.