General question about Python design goals

[Paul Rubin]

When was that, old-timer?

It was before my time, but I have the impression that classes arrived
with 1.3 or somewhere around then. Maybe some of the oldbies here
remember. I started using Python around when 2.1 was released, I think.

 

[Paul Rubin]

fwiw, the tuple and class implementation were both checked into
CVS in october 1990.

maybe he's talking about ABC?

No I think I'm just plain mistaken. For some reason I thought classes
came much later. It was way before my time so I defer to your wisdom.

 

[Duncan Booth]

Yep -- "time tuples" have also become pseudo-tuples (each element can be
accessed by name as well as by index) a while ago, and I believe there's
one more example besides stats and times (but I can't recall which one).

Apart from time and os.stat all the uses seem to be restricted to Unix
only: pwd, grp and resource modules all use StructSequence, also os.statvfs
and spwd (new in 2.5). Thats from an svn checkout though so there may be
fewer uses in released code.

 

[Mike Meyer]

How could list(t) work, if for x in t didn't?

Good question.

For me, conceptually, if an object can't be accessed
sequentially, then it can't be mapped to a sequence.

So you're saying that for should implicitly invoke list (or maybe
iter) on any object that it's passed that's not a list or iterator?

Anyway, it seems to me that in the end this is about
that balance between practicality and purity. Maybe
it's more like tuples have a primary intended purpose,
and some support for other applications. Not white,
but not pure black either.

If you do that, you've just weakened the case for not having count
etc. as methods of tuples.

It really is the dichotomy of "tuples aren't meant to be sequences so
they don't have ..." versus being able to access them sequentially
that gets me. That just doesn't seem right.

<mike

 

[Aahz]

So you're saying that for should implicitly invoke list (or maybe
iter) on any object that it's passed that's not a list or iterator?

for does in fact implicitly invoke iter() on its loop expression.

 

[Donn Cave]

Quoth Mike Meyer <[email protected]>:
....
|> For me, conceptually, if an object can't be accessed
|> sequentially, then it can't be mapped to a sequence.
|
| So you're saying that for should implicitly invoke list (or maybe
| iter) on any object that it's passed that's not a list or iterator?

Not really saying anything so concrete about it -- doesn't make
any difference to me how it works, just saying that all these
things come together. Convert to list, iterate, for. They're
conceptually not just related, but bound together.

|> Anyway, it seems to me that in the end this is about
|> that balance between practicality and purity. Maybe
|> it's more like tuples have a primary intended purpose,
|> and some support for other applications. Not white,
|> but not pure black either.
|
| If you do that, you've just weakened the case for not having count
| etc. as methods of tuples.
|
| It really is the dichotomy of "tuples aren't meant to be sequences so
| they don't have ..." versus being able to access them sequentially
| that gets me. That just doesn't seem right.

The case is weakened only if we have been pretending it was really
strong. I guess this may be why this issue drives certain people
crazy. There's a case for "don't have", but it isn't air-tight, so
what do we do? Well, that's the one thing I really like about the
winter holiday season -- some particularly flavorful ales come out
of the local micro-breweries around this time of year, just in time
to ease my worries about tuples.

Donn Cave, (e-mail address removed)