[Tutor] From C to Python

[Alan Gauld]

"Dhruva Kulkarni" <dhruva_lives at yahoo.com> wrote

> Ok, i get the idea about the referencing, but i got some (;-)) 
> doubts :

Many C/C++ programs find the transition a bit scary at first
because they are giving up control of the low level details.
But the truth is that in higher level languages like Python
(and Lisp and smalltalk etc) you just don't need that level
of control. You are not hand carving the thing from a solid
tree trunk, you are assembling prefabricated items from
the building yard.

> 1.if I want to duplicate some 'mutable object' , then
> just assignment wont work, so i'm sure there must
> be some way of explicitly telling the interp to duplicate

Yes, you can use the copy methods/modules. For simple
sequence types you can use slicing:

a = [1,2,3]
b = a    # a refernce to the same list
c = a[:]   # a copy of the list

> ( or do i have create another list and then copy

No, take a copy using the slice.

> can i also do some operator-overloading ?

Yes, you can define the operator methods (__add__, __mul__ etc)
for any class you define.

> 2.The scoping rules in C go from innermost to outermost,
> does this also happen in Python?

Sort of, but they are different and you should read up on the
namespaces and scoping rules in the docs.

> Also, i couldn't find the keywords for data encapsulation
> ( private protected in c++ )..

A foolish overhyped concept thats rarely used in Python or
indeed most dynamically typed OO languages) :-)
Actually you can pull a few tricks that partially hide data but
in practice most Python classes use the approach that we
are all consenting adults and should use the methods as
intended and not mess with data directly wherever possible.
(A naming convention of a leading underscore is often used
to suggest that the data should not be accessed directly)

More seriously, much of the data protection used in C++ is
due to the contraints of using a static, strictly typed data model.
Once you get used to doing OOP using dynamic typing the
need for that level of control becomes much lower. Again its
the C/C++ culture of absolute control of the data showing through.
Thats only really needed when you have to worry about byte
alignment and register usage etc etc.

> 3.    I guess this list will never end, so if you could just
> point me to some sort of reference guide to Python....

The language reference and other documentation is pretty good.

> But, ( talking  at a *very* high level), supposing i have to
> build an application that has to do some concurrent tasks
> ( each task is a diff process/thread ), and some sort of IPC
> is necessary(signals etc) ,

Multi threading and IPC are easily achieved using pipes,
sockets, XML/RPC and SOAP. There are also CORBA
compliant ORBs and other middleware exotica available

> performance profiling of each thread is necessary

I haven't tried profiling threads, but it may be possible. I'm
not sure how refined the profiling module is for threading.

> use Python just for some cosmetic UI applets that look
> and feel nice and are a pain to code in C/c++,  and do
> the *real* thing in C/C++,

The beauty of python is you can quickly prototype the whole
thing in Python then bit by bt replace the functions with
C/C++/Java whatever. The surprising thing is how little of
it you need to replace in most cases! But the old adage
of get it working before optimising it works here too.

> ( I read some *scary* comments about the multi-threading
> module of Python and the Global Interpreter Lock... )

I don't know of any foolproof threading scvheme, but python
works if you follow the rules. If you start trying to do "clever"
things outside those boundaries then scary things can start
to happen. But you rarely need to do that if you let the language
do the work and trust it to get it right. 99% of the time it does!

And for the fancy stuff some C and a SWIG wrapper can
soon make it available in python...

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld