Lists and Tuples

[Fredrik Lundh]

Re: Humpty Dumpty (was Re: Lists and Tuples)

Aahz wrote:
[color=blue]
> From my POV, the ambiguity comes from layering on additional
> meanings beyond that supported by the C API.[/color]

what C API? (duck)

[Joe Francia]

Re: Lists and Tuples

Fredrik Lundh wrote:[color=blue]
> as expected, you spent that thread attacking everyone who dis-
> agreed with you, misrepresented other people's arguments, referred
> to implementation artifacts and design mistakes as "proof", and used
> the same muddled thinking as you've shown in this thread. <snip>[/color]

So you're saying he's a news commentator for Fox News? ;>)

[Donn Cave]

Re: Lists and Tuples

Quoth Arthur <ajsiegel@opton line.com>:
| On Fri, 5 Dec 2003 11:10:34 -0600, Skip Montanaro <skip@pobox.com >
| wrote:
|> Generally, choose between tuples and lists based upon your data. In
|> situations where you have a small, fixed collection of objects of possibly
|> differing types, use a tuple. In situations where have a collection of
|> objects of uniform type which might grow or shrink, use a list. For
|> example, an address might best be represented as a tuple:
|>
|> itcs = ("2020 Ridge Avenue", "Evanston", "IL", "60201")
|> caffe_lena = ("47 Phila Street", "Saratoga Springs", "NY", "12866")
|>
|> Though all elements are actually strings, they are conceptually different
|> types. It probably makes no sense to define itcs as

| "Type" is not normally an ambiguous word. It seems to me that an
| explanation would stress, upfront, that in fact
| homogenous.hete reogenous in this context is at an abstract level, and
| unrelated to type,as such and as your example illustrates.
|
| Or else, why does the word "type" need to occur at all, other than
| perhaps to explain, explicitily, it is not of relevance

Apologies in advance if someone has already said this. It may
be a little too algebraic for the Python world, but for me the
difference can be expressed like this -

n > 0 or m < sizeof(a) and
conceptual_type (a) == conceptual_type (a[n:m])

If that holds, then the conceptual type is naturally implemented
with a list.

I'm not sure it's right to say that the elements of a tuple are
necessarily of conceptually different types, distinguished only
by their positiion. But the point is that they _are_ distinguished
by position (so a slice is not substitable with its source.)

Of course this still relies on a notion of conceptual type that
can't be expressed literally in Python, but it's a healthy one.

Donn Cave, donn@drizzle.co m

[Greg Ewing (using news.cis.dfn.de)]

Re: Lists and Tuples

Douglas Alan wrote:[color=blue]
> mwilson@the-wire.com (Mel Wilson) writes:
>[color=green]
>> To me, it's a distinction without a difference. Tuples
>>*act* like immutable sequences, and I use them that way. I
>>don't know, though, that I won't get caught some day.[/color]
>
> You'll be fine. The only thing you have to watch out for is that some
> rude folks here might call you names.[/color]

That would add some spice to Python's error messages...

Python 3.7 (#1, Sep 31 2007, 14:19:37)
[GCC 5.6.7] on slartibartfast
Type "help", "copyright" , "credits" or "license" for more information.[color=blue][color=green][color=darkred]
>>> t = (1, 3, 77, 654, 8)[/color][/color][/color]
Traceback (most recent call last):
File "<stdin>", line 1, in ?
HumiliationErro r: The programmer is a pink-faced baboon (tuple used where
list would be more appropriate)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing (using news.cis.dfn.de)]

Re: Lists and Tuples

Ron Adam wrote:
[color=blue]
> Items in lists and not in tuples:[/color]
....[color=blue]
> And Items in tuples and not in lists:[/color]

And chicks on blocks but not on clocks...

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Roy Smith]

Re: Lists and Tuples

In article <br0r2a$2572i2$ 1@ID-169208.news.uni-berlin.de>,
"Greg Ewing (using news.cis.dfn.de )" <g2h5dqi002@sne akemail.com>
wrote:
[color=blue]
> Douglas Alan wrote:[color=green]
> > mwilson@the-wire.com (Mel Wilson) writes:
> >[color=darkred]
> >> To me, it's a distinction without a difference. Tuples
> >>*act* like immutable sequences, and I use them that way. I
> >>don't know, though, that I won't get caught some day.[/color]
> >
> > You'll be fine. The only thing you have to watch out for is that some
> > rude folks here might call you names.[/color]
>
> That would add some spice to Python's error messages...
>
> Python 3.7 (#1, Sep 31 2007, 14:19:37)
> [GCC 5.6.7] on slartibartfast
> Type "help", "copyright" , "credits" or "license" for more information.[color=green][color=darkred]
> >>> t = (1, 3, 77, 654, 8)[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> HumiliationErro r: The programmer is a pink-faced baboon (tuple used where
> list would be more appropriate)[/color]

In MVP (Microsoft Visual Python), the "auto-correct" function would just
silently change the ()'s to []'s as you typed them. If you tried to
change them back, clippy would pop up on the screen and say, "You seem
to be trying to do something un-pythonic. Would you like some
assistance?". If you tried to make clippy go away, it would offer to
"install this critical security patch immediately".

[Douglas Alan]

Re: Lists and Tuples

"Greg Ewing (using news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> writes:
[color=blue]
> Douglas Alan wrote:[/color]
[color=blue][color=green]
>> You'll be fine. The only thing you have to watch out for is that
>> some rude folks here might call you names.[/color][/color]
[color=blue]
> That would add some spice to Python's error messages...[/color]
[color=blue]
> Python 3.7 (#1, Sep 31 2007, 14:19:37)
> [GCC 5.6.7] on slartibartfast
> Type "help", "copyright" , "credits" or "license" for more information.[color=green][color=darkred]
> >>> t = (1, 3, 77, 654, 8)[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> HumiliationErro r: The programmer is a pink-faced baboon (tuple used where
> list would be more appropriate)[/color]

Hmmm, could I catch the exception and then continue on anyway? Kind
of like casting away const in C++?

|>oug

[John La Rooy]

Re: Lists and Tuples

On Mon, 08 Dec 2003 16:36:05 +1300
"Greg Ewing (using news.cis.dfn.de )" <g2h5dqi002@sne akemail.com> wrote:
[color=blue]
>
> That would add some spice to Python's error messages...
>
> Python 3.7 (#1, Sep 31 2007, 14:19:37)
> [GCC 5.6.7] on slartibartfast
> Type "help", "copyright" , "credits" or "license" for more information.[color=green][color=darkred]
> >>> t = (1, 3, 77, 654, 8)[/color][/color]
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> HumiliationErro r: The programmer is a pink-faced baboon (tuple used where
> list would be more appropriate)
>[/color]
Hmmm..Sep 31? Should I file a bug report? ;o)


John

[Arthur]

Re: Lists and Tuples

On Sun, 07 Dec 2003 22:42:17 -0500, Roy Smith <roy@panix.co m> wrote:
[color=blue]
>In MVP (Microsoft Visual Python), the "auto-correct" function would just
>silently change the ()'s to []'s as you typed them. If you tried to
>change them back, clippy would pop up on the screen and say, "You seem
>to be trying to do something un-pythonic. Would you like some
>assistance?" . If you tried to make clippy go away, it would offer to
>"install this critical security patch immediately".[/color]

Give some credit.

The unitype system will have been inplemented by then.

One's decoded DNA sequence will be accessed (some people thought web
services would be a bust, back in aught 3), with reference to which,
one's intentions are determined.

Programming now called "hinting". CH4E.

Art

[Arthur]

Re: Humpty Dumpty (was Re: Lists and Tuples)

On 7 Dec 2003 11:02:38 -0500, aahz@pythoncraf t.com (Aahz) wrote:
[color=blue]
>In article <mailman.190.10 70806215.16879. python-list@python.org >,
>Fredrik Lundh <fredrik@python ware.com> wrote:[color=green]
>>Arthur wrote:[color=darkred]
>>>
>>> "Type" is not normally an ambiguous word.[/color]
>>
>>really? in my experience, "type" and "object" are about as ambiguous
>>as words can get, especially when you're talking about Python.[/color][/color]

I actually see the point also, with direct relevance to Lists and
Tuple tutorial semantics, to the extent that I am confused whether
instances of different classes are of the same "type".

I have considered no. By inheriting from object and creating something
new from it I am creating a custom type. I thought. I think this
impression comes from my little experinece with other languages. And
since the way I use lists are to group instances of different classes,
which may have nothing in common other than a single method of the
same name, I have considered my lists to be of heterogenous type.
Which is why I have been confused by the language to describe the
prototypical use of lists.

Art
[color=blue]
>
>Hrm. I see your point, but I also think it's fairly easy to get people
>to agree on definitions for "type" and "object" within the context of a
>discussion. From my POV, the ambiguity comes from layering on additional
>meanings beyond that supported by the C API.[/color]

[Skip Montanaro]

Re: Lists and Tuples

>>>>> "Greg" == Greg Ewing <(using news.cis.dfn.de )" <g2h5dqi002@sne akemail.com>> writes:

Greg> Ron Adam wrote:[color=blue][color=green]
>> Items in lists and not in tuples:[/color][/color]
Greg> ...[color=blue][color=green]
>> And Items in tuples and not in lists:[/color][/color]

Greg> And chicks on blocks but not on clocks...

Through three cheese trees, three free fleas flew...

Skip

[Greg Ewing (using news.cis.dfn.de)]

Re: Lists and Tuples

John La Rooy wrote:[color=blue]
> Hmmm..Sep 31? Should I file a bug report? ;o)[/color]

You're failing to take into account the (highly controversial)
International Calendar Reform of 2006, which gave all months
the same number of days. Python was, of course, the first
language to have its datetime module updated to conform with
the new standard.

(Microsoft Java++#.NET was updated too, but in a subtly
incompatible way -- all their months were given 30
days instead.)


--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Fredrik Lundh]

Re: Lists and Tuples

Greg Ewing wrote:
[color=blue][color=green]
> > Hmmm..Sep 31? Should I file a bug report? ;o)[/color]
>
> You're failing to take into account the (highly controversial)
> International Calendar Reform of 2006, which gave all months
> the same number of days. Python was, of course, the first
> language to have its datetime module updated to conform with
> the new standard.
>
> (Microsoft Java++#.NET was updated too, but in a subtly
> incompatible way -- all their months were given 30
> days instead.)[/color]

it's well known (at least to insiders) that the bug in MSJPCS.NET was the
reason for the reform.

a "32 days is better for computers" alternative was brought forward by the
usual suspects (IBM, Sun, etc, plus a bunch of bloggers hellbent on teaching
Dave Winer a lesson), but was, as usual, largely ignored by everyone else.

31 might be due to a EU translation error, but I'm not sure. I also hear that
the french edition of the standard uses 13 days.

</F>