Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental solve.py,1.2,1.3

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
[snip]
> >   point([1, 2, 3])
> >=20
> > or
> >=20
> >   point((1, 2, 3))
> >=20
> > is completely irrelevant (as long as you stay away from the
> > naughtiness of type checking ;).
>=20
> I'm not so sure. To me it makes a difference.

Not unless you're doing type checking ;)

I'm talking from the perspective of the function, not the caller. The
function should simply treat the argument as a sequence, and not
bother with how it is implemented.

> A tuple is something, where the items do have a fixed, specific
> position and the meaning of the items might be different depending
> on their position.

That is the philosophical reasoning, yes. I still think tuples are
pretty bogus. You could easily use lists to represent the same
thing... *Or* you could have fixed-length lists. *Or* you could have
mutable tuples. I don't know...

Anyway, it really shouldn't have anything to do with how the function
is implemented, as long as it doesn't realy on any functionality
present in tuples but not elsewhere (and I can't think of any).

> Hence a crucial feature of tuples is to be immutable in their
> length.

Sure. I can see how that can be useful -- sort of. Although not very
much.

> Well, they are immutable in their values as well, but this keeps to
> be strange to me. It's kind of unpythonic ... well. I don't know.

I think so too. When I wrote the chapter on sequences in my Python
book I had real problems justifying the existence of tuples. I tried
to ask Alex Martelly (who was one of my tech editors) and he didn't
have any good explanations either.

The only use of tuples, IMO (as a Python type, not as a concept -- you
could easily use a list to model a mathematical tuple, where each
position has a specific meaning and so forth) is that they are
hashable, and thus can be used as keys in dicts, members of sets and
so forth. You have the same dichotomy (list vs. tuple) in the set
implementation (with set and frozenset).

> Vectors, where each component is a value for a certain dimension is
> not a very good example for that discussion, I think. At least when
> all dimensions are equal to each other like in an Euclid space. May be
> the theory of relativity with its four component vectors is a
> resonable example even for a vector being a tuple, not a list ...

Sure. But that's still just (IMO) the thing you're *modeling* using
the specific object (a tuple or a list). I *don't* see why using a
tuple is any better, unless you really need it to be static/frozen
(which, in most cases, you really don't).

And I really, really think this is not something a function such as
this should care about. It should simply accept any iterable object.

Now -- it may be that we're discussing two different things... I'm
arguing that a list and a tuple as arguments should be seen as
equivalent; you may, perhaps, be arguing that positional arguments
(i.e. point(1, 2, 3)) is the way to go? I'm not really very opposed to
that. I just brought the (somewhat "standard") point(seq) syntax as an
alternative.

> Beside that, you're right. We should forget about type checking and
> than it usually becomes unimportant.
>=20
> > The real difference is between this
> > and
> >=20
> >   point(1, 2, 3)
> >=20
> > Even the numarray arrays use the first form, as do, really, all
> > sequence types, including tuples.
>=20
> In my redesign I'm only left with a single vector class. Here I'm
> using the list like version to create a constant and a plain number to
> specify a variable vectors dimension.

OK.

> I'm not sure whether you'll like this syntax in the end, but the
> user is left with just a scalar and a vector. Period. That's nice, I
> think, but we can discuss those details and the naming again once we
> see how it works out.

Indeed.

> > I'm just saying that the "standard" constructor for sequence
> > types admits a single iterable objects as its argument.
>=20
> BTW: How invented this stange *single* iterable object. I would really
> like to be allowed to use several of them. This limitation is annoying
> and unnecessary to me. (I haven't thought very hard about that, but I
> really don't see any reasoning why this limitation exist.)

What do you mean? Would you like to use several iterable objects as
arguments to list(), for example? What would that mean? Something like
list(chain(iter1,iter2,iter3))? (The chain function is available in
the itertools module.)

> Andr=E9

--=20
Magnus Lie Hetland     "Canned Bread: The greatest thing since sliced
http://hetland.org      bread!" [from a can in Spongebob Squarepants]