python gripes survey
jordan at krushen.com
Mon Aug 25 22:11:35 CEST 2003
On Mon, 25 Aug 2003 19:45:10 GMT, Afanasiy <abelikov72 at hotmail.com> wrote:
> 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
> 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.
I agree here. Returning tuples is only useful when very few arguments are
being returned. I must admit, I haven't seen many cases where they're used
as [larger] C structs are -- in most of those cases, some kind of
methodless container object is usually returned. For trivial cases, it's
much less work for the developer to simply return a tuple than to create a
class just for the result.
Therein lies much of the problem, I believe. Developers tend to code to
whatever method makes life easier for them. This is fine for closed
application development, but developers working on libraries often forget
that a little extra work up front will save time for many other coders as
they continue to use the library.
> Often this is not even done in C, because a struct is used instead.
Indeed. In Python, I prefer to simply toss a methodless object back,
instead. Obviously, this incurs some overhead though (both finger-and run-
time). I wonder if occurences of tuples being returned in the standard
library are there for performance reasons (select.select, etc).
> 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 that way.
I'm just trying to determine where you have most of an issue with this --
in the standard library, in other libraries, or what is being recommended
as Pythonic. If it's an inconsistency/readability issue in the standard
library, we can fix it! Isn't that the point of this thread? Simply
detailing gripes without any attempt to fix them is quite unproductive,
If the complaint is more specifically what you deem or perceive others to
deem as Pythonic, then I can't say I have seen many cases of mystery-tuples
being returned, except for the low-layer library wrappers (win32all comes
to mind), but those seem to often be written as shims, with the expectation
that another, more OO and developer-friendly API will be exposed afterward.
I can't say I've seen many cases where people *recommend* returning
tuples, as readability does tend to suffer.
> 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'm neither confused or attacking. This is a concern of mine that lines up
with your own, but I'm looking at a potential fix for the problem, and
trying to clarify where you perceive the issue to exist.
More information about the Python-list