[Tutor] Python Extensions in C

[ALAN GAULD]

> I suppose it's up to the programmer. 

It is, provided the programmer is remembering that the audience 
is not him/herself buty the many other programmers who will 
have to read and maintain the code over the years to follow.
So if the programmer genuinely believes that one form is clearer 
then its fine, or if there is a real need to optimise.  

> Personally, I find something like this:
>
> variable += something
>
> a lot easier to read than

Fine if the something is a constant (or at least fixed at the 
time of assignment) but if its really:

variable += something()

and something() might return a NULL or non numeric value 
then you have a much harder bug to find than if you split it.

> For me, it's just another variable I have to worry about 
> allocating/deallocating/seeing if it's used anywhere 
> else/accidentally using when I shouldn't.

If its not a pointer you don;t need to worry about allocation.
As for usage, yes that's an issue but a well chosen name 
helps prevent misuse (unless you have psychopathically 
destructive programmers!). Unless you are programming a 
microcontroller the amount of memory taken up by an int 
or long in C is hardly ever an issue.

> ...James asked about memory management 

Yes, but specifically about dynamic memory(pointers) not static.

> ...depending on the program you're using and the size 
> of your inputs, it actually can make a difference. 

Absolutely, and as I said, you can optimise C to the point of obscurity 
but you should only do so once you have proved that there really 
is a need and after trying other techniques like redesigning your 
data structures and algorithms. Fine tuning code should be the 
last resort not the first. And often it's better to drop into assembler 
for the critical section. Clear assembler is much easier to maintain 
than obscure C.

Alan G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20110527/aaa4c7c4/attachment-0001.html>