[Tutor] What all technologies should a python developer know?

[Dave Angel]

On 07/17/2013 11:09 AM, wolfrage8765 at gmail.com wrote:
> On Wed, Jul 17, 2013 at 8:42 AM, Dave Angel <davea at davea.name> wrote:

      <SNIP>

>> I could continue, randomly attacking other aspects of a development
>> environment.  The point is that there are traps everywhere, and beautiful
>> symmetries everywhere.  Learn how to recognize the former, and learn to
>> appreciate the latter.  Learn what to do when the docs fall short (eg. drop
>> to assembler to see what the language construct is really doing, reverse
>> engineer a file format, write some code to "do it by hand,"  etc.).

> Dave, how do I "drop down to assembler" with Python?  Can you expand
> on this?  Also do you think it is still of value to learn Assembly
> Language, and if so which variant, as I understand it, there is a
> unique set for each architecture, although they are usually similiar.

There aren't many places where it's worth your time to explicitly code 
in assembler these days.  But that's very different from whether it's 
worth studying and understanding.  That is VERY useful, and IMHO will 
always be.

Having said that, I've never bothered with CPython, as CPython is two 
levels removed from assembler.  I did with Java, so CPython probably 
wouldn't be any worse.

CPython is compiled into byte code, and that byte code is its assembly 
language, for most purposes.  You should get familiar with that 
language, either by using dis.dis, or by reverse engineering the byte 
code files.  It can be very informative to see how a particular 
expression or statement gets transformed into the VM.

I'd love to find a debugger that let you step into the byte-code 
instructions the way a good C debugger lets you switch to assembly mode. 
  So far, I've only statically looked at (disassembled and examined) 
selected parts of the code to understand why certain constructs work 
more efficiently or just differently than others.


As for "real" machine language, like the Pentium 32 bit architecture, 
that's useful for understanding a traditional compiled language like C. 
  Notice that you usually have to turn off the compiler optimizations, 
as the optimized code gets totally convoluted, and very hard to 
understand.  Again, you can use the shortcut provided by most compilers 
where you ask it for a listing of mixed C and assembly code.  That's 
analogous to the dis.dis approach in CPython.

Nowhere am I recommending that everyone should WRITE in assembler.  Gain 
a reading knowledge of it, and it'll stand you in good stead.  Step into 
such code with a good debugger, and see where registers are pointing, 
and try to figure out why.  For example, in Microsoft's MSC compiler in 
C++ mode (32bit), the 'this' pointer of C++ is almost always in EBX 
register.  And a call to a virtual function is done with a strange 
addressing mode on that register where the machine takes the register 
value, adds a constant offset to it, dereferences 32bits from ram at 
that location, and does a call to that final location.  And if the class 
involved is virtually derived from another, there will be another 
indirection or two.



-- 
DaveA