>>> You MUST check EVERY function call for errors! >> >> Yes, I know :) >> > > Believe me, if you don't, there is a risk of crashing the program. And > they're a lot harder to find and fix.
Sure, what I meant by the smiley is just that it was a quick and dirty example, not real code. In a real code I do check these sorts of things. >>> And check the argument's type (how do you know it is a list?). Once you >>> are sure the first parameter *is* a list, you may use the "macro" >>> version >>> of several functions, like PyList_GET_SIZE and PyList_GET_ITEM. >> >> The macro versions are preferable because they are faster? > > Yes, because they don't do any additional checking. PyList_GET_ITEM just > retrieves the item; PyList_GetItem checks whether it is called on a list > object, then checks if index is out of bounds, and only then goes to > retrieve the item. Thanks, I was wondering what the difference between these versions are, now it's clear. >>> You should check that both lists have the same length too. >>> And you should check that elements are integers, or convertible to >>> integers (in case of error, PyInt_AsLong returns -1 and PyErr_Occurred() >>> is true) >>> To fill the resulting tuple, use PyTuple_SET_ITEM instead. BTW, why >>> return >>> a tuple and not a list? >> >> No particular reason, other than the fact that I won't need to modify >> these lists/tuples from python so whenever something will not change, >> I use a tuple because it's immutable. Or this is not a very good >> practice? There is no difference between lists and tuples in terms of >> speed I suppose (getitem, setitem, etc). > > Usually lists represent an ordered collection of similar items, where > position is not relevant (the third item is treated more or less the same > as the tenth); by example, a list of attendants to certain event. It makes > sense to process the whole list doing the same thing to each element, and > it makes sense to ask "is this item in the list?." > > Tuples represent an ordered collection of dissimilar items, where position > is relevant (because it identifies each item); by example, a row from a > database table (name, address, age, phone number), or a point (x,y,z) in > space. It isn't common to process the whole tuple doing the same thing for > each element, and usually it doesn't make sense to look for certain item > in the tuple. But it does make sense to refer to individual items like > t[2], or t.age (namedtuple, 2.6 and up) > > From this point of view, lists and tuples are conceptually different - > tuples aren't "frozen" lists. But this is just common usage, or maybe > historical intent; of course you are free to use whatever structure you > feel adequate. > > Once the list/tuple is created and filled, there is no speed difference > accessing the individual items. Creating an empty list that grows one > element at a time is slow for large lists (the memory block has to be > re-allocated and copied over evry time it gets full) but this doesn't > happen if you provide the final size when creating the list. All right, this is clear then too, I'll probably use a list. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
