lists v. tuples

[castironpi at gmail.com]

On Mar 17, 11:03 am, Duncan Booth <duncan.bo... at invalid.invalid>
wrote:
> Ninereeds <stephenhorne... at aol.com> wrote:
> > On Mar 17, 1:31 pm, Duncan Booth <duncan.bo... at invalid.invalid> wrote:
>
> >> A common explanation for this is that lists are for homogenous
> >> collections, tuples are for when you have heterogenous collections i.e.
> >> related but different things.
>
> > I interpret this as meaning that in a data table, I should have a list
> > of records but each record should be a tuple of fields, since the
> > fields for a table usually have different forms whereas the records
> > usually all have the same record layout.
>
> That is indeed what Python's Database API usually does (although it doesn't
> mandate it):
>
>         .fetchmany([size=cursor.arraysize])
>
>             Fetch the next set of rows of a query result, returning a
>             sequence of sequences (e.g. a list of tuples). An empty
>             sequence is returned when no more rows are available.

Two things:

>>> b in b
False

in S. D'Aprano's example, which somewhat obscures (casts a shadow on)
its intuitive meaning.  "Hand me everything that's in there. > For x
in There: hand( me, x ).

> For x in rchain( There ): hand( me, x ) < Hand me anything that's in anything that's in there, or is in there.

Closet = [ Box[ ball ] ] >
Box[ ball ]?
or Box, ball?

Despite that 'in' is a very common word [lacks cit.], you don't often
get ambiguities (read: questions) about containers in something.  Too
custom.  The word isn't defined at that extremity of combinations /
cartesian products of particulars (context).  It doesn't have a common
sense, and computer science is a pretty unique field in that it finds
(or, invents) all-and-only definitions of words.

(Which reminds me, what about a classmethod __getitem__ construtor?)

However, from mathematics, which is at least older, if not more in
tune with the common senses and uses, (there exists an a and b such
that) Member( a, b ) != Exists x such that Member( a, b ) & Member( b,
x ).  In other words, Python honors math's definition.

In the example, would you treat 'ball' separately unless explicity
asked to?  (But, keep sure not to alter the contents of any of the
containers that are in there.)  There's a fine example of
miscommunication: neither behavior was the default between the pair:
one knew one default; the other knew another.  (But, it's ok to alter
the contents of any containers.)  Aside, do you think there are trends
among who and when uses what defaults?  Such as math background,
social status, etc.?

Computers are very good at attention to detail: ("I" am.)  "You did
not specify whether to alter containers in it."  Of course, the
program that's following would have to have noticed two things: that
there's a short-cut if you can, and you might not want it to.  It's
not only a problem of formal systems: No= { X, Y, Z }.  Some (finite)
context hasn't determined the convention of wish-expression in every
combination of (future possible) cases.

while 1:
  print( "You made an assumption!" )
  print( "No, -you- made an assumption!" )
  break

while 1:
  print( "I made an assumption." )
  print( "I also made an assumption." )

But is it determined whether it's determined whether the person meant
to?  That is, can you tell whether the person didn't specify?  "I'm
sorry, we haven't spoken about containers in containers enough for me
to tell what your wishes are."

My worry is that popular judgment isn't best in science.  What factors
in to the architect's decision?  His feelings about use cases?  His
calculations about use cases?  His feelings about popularity of each?
His calculations about popularity?  Mabye Python would have ten extra
speakers if __contains__ had been defined differently!  X percent of
all shortest-form syntactic combinations can be written in less tokens
with one definition, but no matter how much I remind them, they won't
remember combination C, so only Y percent are actually, practically
ever written in 2008 Earth programming.  Because we're stupid, no.
Because we have other priorities than programming.  (But my bigger
house for me was more important.)

'rchain', recursive chain, might be the next function on the path that
itertools is on.



Databases have come to (but don't have to stay) use integers as
autokeys in records.  That makes one way to refer to a record to refer
to its integer.  However, if one's testing for identity between
records, that key is redundant.  Just identify yourself, and refer
back to earlier in context.  And incidentally, why namedtuples but no
namedlists?  Or nameddicts?  And could one define an anonymous type?

This is interesting:

>>> type('A',(),{}) is type('A',(),{})
False
>>> type('A',(),{}) == type('A',(),{})
False

>>> type('G',(),{})
<class '__main__.G'>
>>> G
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'G' is not defined

A type went out of scope.  Is there an abstraction of 'pickle' which
doesn't need the type defined in its target module?

>>> pickle.dumps( type('A',(),{}) )
pickle.PicklingError: Can't pickle <class '__main__.A'>: it's not the
same object as __main__.A
>>> pickle.dumps( type('A',(),{})() )
pickle.PicklingError: Can't pickle <class '__main__.A'>: it's not the
same object as __main__.A
>>> del A
>>> pickle.dumps( type('A',(),{}) )
pickle.PicklingError: Can't pickle <class '__main__.A'>: it's not
found as __main__.A
>>> pickle.dumps( type('A',(),{})() )
pickle.PicklingError: Can't pickle <class '__main__.A'>: it's not
found as __main__.A

But all the information's there!