text: "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