python gripes survey
abelikov72 at hotmail.com
Mon Aug 25 21:45:10 CEST 2003
On Mon, 25 Aug 2003 18:32:35 GMT, Jordan Krushen <jordan at krushen.com>
>On Mon, 25 Aug 2003 18:14:30 GMT, Afanasiy <abelikov72 at hotmail.com> wrote:
>> Sure you can return an associative array, but in my experience the
>> preference is to return a tuple. I'll probably get flamed for saying so,
>> but this is how I feel and it is unavoidable. Returning a struct in C is
>> easier to deal with than returning a near-mystery tuple in Python.
>On one hand, you could always return a dict in your own code. On the
>other, I find dealing with returned tuples to be as easy as it gets:
Obviously, in my own go I do not use near-mystery tuples.
>def f(x, y, z):
> return(z, y, x)
>a, b, c = f()
>print a, b, c # 3 2 1
Yes, returning multiple values, ie. tuples, is useful, but using them as
you would use structs in C is common and the root of my gripe. The problem
I explained above has nothing to do with the code you write. The problem
is knowing what integer position in the tuple represents what field. In C
structs have named fields, but in Python tuple have integer fields. The
meaning of tuple integer fields, for tuples used this way, is only known
in the documentation, not the code directly.
When tuples are used this way, to me, it is akin to using small arrays in
C for multiple values, where it is common to define globals in all caps
for the integer index supposed to be represented. This is not done in
Python because it is very un-python, yet the same type of code which
_causes_ this helpful convention *is* used in Python. Curious.
Often this is not even done in C, because a struct is used instead.
I thought this thread was for gripes, not detailed explanations and
solutions. However, for a solution... Perhaps people should use dicts in
the libraries more often than near-mystery tuples. It's much more explicit
When I have to re-explain and re-gurgitate something like this for benefit
of one confused person I leave myself open to more confused attacks, and I
don't like that. So if that happens this time, I will make sure not to
elaborate so much next time, and will reply abruptly instead.
"I have made this letter longer than usual because I lack the time to make
it shorter." - Blaise Pascal
More information about the Python-list