translating Python to Assembler
My expertise, if any, is in assembler. I'm trying to understand Python scripts and modules by examining them after they have been disassembled in a Windows environment. I'm wondering if a Python symbols file is available. In the Windows environment, a symbol file normally has a PDB extension. It's a little unfortunate that Python also uses PDB for its debugger. Google, for whatever reason, wont accept queries with dots, hyphens, etc., in the query line. For example a Google for "python.pdb" returns +python +pdb, so I get a ridiculous number of returns referring to the python debugger. I have mentioned this to Google several times, but I guess logic isn't one of their strong points. :-) -- http://mail.python.org/mailman/listinfo/python-list
Anyone into Paimei?? Need some help.
Hi. I have been trying to get Paimei running on Windoze but find it very inconsistent. It works on certain apps really well, like Notepad, but fails on other apps, especially those written in languages like Delphi. There isn't a lot out there on Paimei and the author's site is very terse on the app. -- http://mail.python.org/mailman/listinfo/python-list
translating Python to Assembler
My expertise, if any, is in assembler. I'm trying to understand Python scripts and modules by examining them after they have been disassembled in a Windows environment. I'm wondering if a Python symbols file is available. In the Windows environment, a symbol file normally has a PDB extension. It's a little unfortunate that Python also uses PDB for its debugger. Google, for whatever reason, wont accept queries with dots, hyphens, etc., in the query line. For example a Google for "python.pdb" returns +python +pdb, so I get a ridiculous number of returns referring to the python debugger. I have mentioned this to Google several times, but I guess logic isn't one of their strong points. :-) -- http://mail.python.org/mailman/listinfo/python-list
translating Python to Assembler...sorry if this is duplicated...it's unintentional
My expertise, if any, is in assembler. I'm trying to understand Python scripts and modules by examining them after they have been disassembled in a Windows environment. I'm wondering if a Python symbols file is available. In the Windows environment, a symbol file normally has a PDB extension. It's a little unfortunate that Python also uses PDB for its debugger. Google, for whatever reason, wont accept queries with dots, hyphens, etc., in the query line. For example a Google for "python.pdb" returns +python +pdb, so I get a ridiculous number of returns referring to the python debugger. I have mentioned this to Google several times, but I guess logic isn't one of their strong points. :-) If there's dupicates of this post it's because it wouldn't send for some reason. -- http://mail.python.org/mailman/listinfo/python-list
python24 symbol file...pyhon24.pdb
I've seen a few references on the net to a python24.pdb file. I assume it's a symbol file along the lines of the pdb files issued by microsoft for their products. Maybe I'm wrong. Has anyone seen such an animal? Also, is there source code available for python24 for Windoze? I have seen reference to source code but not in a package for Windows. thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: python24 symbol file...pyhon24.pdb
On Wed, 23 Jan 2008 08:54:19 +0100, Christian Heimes <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] wrote: >> I've seen a few references on the net to a python24.pdb file. I assume >> it's a symbol file along the lines of the pdb files issued by >> microsoft for their products. Maybe I'm wrong. > >.pdb files (program database) are created by MS' compiler, see >http://en.wikipedia.org/wiki/Program_database. Python doesn't ship the >files. You have to compile Python yourself to get the pdb files. > >Christian thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: python24 symbol file...pyhon24.pdb
>I don't get why you care so much about that file. It's useful to debug a >crash in python.exe, but I can't see any other useful purpose (if you only >have the python executable and the .pdb available). I'm trying to use Paimei, the Python-based debugger put out by Pedram Amini. I can get Paimei to run certain apps, like Notepad, but it gets hung up on other apps that are more complex. I'm trying to find the bottleneck, so to speak, on apps that fail, so I'm using a Windows debugger to follow the Paimei app as it is interpretted by python. It is very helpful when tracing assembler code to have symbols available in the disassembly of the debugger. So far, I can follow the code from the Paimei wxPython windows into pythonw and python. It was difficult due to the lack of signposts. With a pdb symbol file loaded, the disassembly has names on the functions, like kernel32, etc. > >> Also, is there source code available for python24 for Windoze? I have >> seen reference to source code but not in a package for Windows. > >There is a single source package shared by all platforms. You can download >and compile it, and you'll get your own version of python.pdb if you like. thanks for the info. -- http://mail.python.org/mailman/listinfo/python-list
Re: python24 symbol file...pyhon24.pdb
On Wed, 23 Jan 2008 10:19:28 +0100, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Also, is there source code available for python24 for Windoze? I have >> seen reference to source code but not in a package for Windows. > >It's available from > >http://www.python.org/ftp/python/2.4/Python-2.4.tgz > >Regards, >Martin thanks you kindly. -- http://mail.python.org/mailman/listinfo/python-list
Re: translating Python to Assembler
On Thu, 24 Jan 2008 08:02:06 GMT, Tim Roberts <[EMAIL PROTECTED]> wrote: >Bjoern Schliessmann <[EMAIL PROTECTED]> wrote: > >>Grant Edwards wrote: >> >>> Trying to find assembly language stuff to look at is futile. >>> Python doesn't get compiled into assembly language. >> >>So, how do processors execute Python scripts? :) > >Is that a rhetorical question? Grant is quite correct; Python scripts (in >the canonical CPython) are NOT compiled into assembly language. Scripts >are compiled to an intermediate language. Processors execute Python >scripts when the interpreter, written in a high-level language and compiled >to assembly, interprets the intermediate language created by the Python >"compiler". Intel processors can only process machine language, which is essentially binary 1's and 0's. All a processor understands is voltages, either 0 Volts or 5 volts on older systems, or 3.3 volts and less on newer systems. Generally, a positive voltage is a logical 1 and 0 volts is a logical 0. There's no way for a processor to understand any higher level language, even assembler, since it is written with hexadecimal codes and basic instructions like MOV, JMP, etc. The assembler compiler can convert an assembler file to a binary executable, which the processor can understand. If you look at the Python interpreter, Python.exe, or Pythonw, the Windows interface, or the Python24.dll, the main library for python, you will see they are normal 32 bit PE files. That means they are stored on disk in codes of 1's and 0's, and decompile into assembler. You can't decompile them into Python directly, although I'm sure someone is trying. No compiled file can be decompiled into it's original format easily or automatically, although there are decompilers that will convert them to a reasonable assembler decompilation. If a Python script was understood directly by the processor, no interpreter would be necessary. Ask yourself what the interpreter is doing. It's taking the scripting language and converting to the language of the operating system. However, it's the processor that dictates how programs are written, not the OS. That's why a Linux OS will run on an Intel machine, as a Windows OS does. Both Linux and Windows compile down to binary files, which are essentially 1's and 0's arranged in codes that are meaningful to the processor. Once a python py file is compiled into a pyc file, I can disassemble it into assembler. Assembler is nothing but codes, which are combinations of 1's and 0's. You can't read a pyc file in a hex editor, but you can read it in a disassembler. It doesn't make a lot of sense to me right now, but if I was trying to trace through it with a debugger, the debugger would disassemble it into assembler, not python. -- http://mail.python.org/mailman/listinfo/python-list
Re: translating Python to Assembler
On Fri, 25 Jan 2008 17:36:06 -0800 (PST), ajaksu <[EMAIL PROTECTED]> wrote: >On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote: >> Once a python py file is compiled into a pyc file, I can disassemble >> it into assembler. Assembler is nothing but codes, which are >> combinations of 1's and 0's. You can't read a pyc file in a hex >> editor, but you can read it in a disassembler. It doesn't make a lot >> of sense to me right now, but if I was trying to trace through it with >> a debugger, the debugger would disassemble it into assembler, not >> python. > > >Please, tell me you're kidding... hehe...which part am I kidding about? The explanation was for someone who thought python scripts were translated directly by the processor. I had no idea how much he knew, so I kept it basic (no pun intended). Or...do you disagree with what I'm saying? You didn't say much. I have already disassembled a pyc file as a binary file. Maybe I was using the term assembler too broadly. A binary compiled from an assembler source would look similar in parts to what I disassembled. That's not the point, however. I'm trying to say that a processor cannot read a Python script, and since the Python interpreter as stored on disk is essentially an assembler file, any Python script must be sooner or later be converted to assembler form in order to be read by its own interpreter. Whatever is typed in a Python script must be converted to binary code. -- http://mail.python.org/mailman/listinfo/python-list
Re: translating Python to Assembler
On Fri, 25 Jan 2008 17:44:07 -0800 (PST), ajaksu <[EMAIL PROTECTED]> wrote: >On Jan 25, 11:36 pm, ajaksu <[EMAIL PROTECTED]> wrote: >> On Jan 25, 11:10 pm, [EMAIL PROTECTED] wrote: >[...] > >Gaah, is this what's going on? > >[EMAIL PROTECTED]:~$ cat error.txt >This is not assembler... > >[EMAIL PROTECTED]:~$ ndisasm error.txt > 54push sp >0001 686973push word 0x7369 >0004 206973and [bx+di+0x73],ch >0007 206E6Fand [bp+0x6f],ch >000A 7420 jz 0x2c >000C 61popa >000D 7373 jnc 0x82 >000F 656D gs insw >0011 626C65bound bp,[si+0x65] >0014 722E jc 0x44 >0016 2Edb 0x2E >0017 2Edb 0x2E >0018 0Adb 0x0A > >:/ not sure what you're saying. Sure looks like assembler to me. Take the '54 push sp'. The 54 is an assembler opcode for push and the sp is the stack pointer, on which it is operating. -- http://mail.python.org/mailman/listinfo/python-list
Re: translating Python to Assembler
On Sat, 26 Jan 2008 14:47:50 +0100, Bjoern Schliessmann <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] wrote: > >> Intel processors can only process machine language[...] There's no >> way for a processor to understand any higher level language, even >> assembler, since it is written with hexadecimal codes and basic >> instructions like MOV, JMP, etc. The assembler compiler can >> convert an assembler file to a binary executable, which the >> processor can understand. > >This may be true, but I think it's not bad to assume that machine >language and assembler are "almost the same" in this context, since >the translation between them is non-ambiguous (It's >just "recoding"; this is not the case with HLLs). I have no problem with your explanation. It's nearly impossible to program in machine code, which is all 1's and 0's. Assembler makes it infinitely easier by converting the machine 1's and 0's to their hexadecimal equivalent and assigning an opcode name to them, like PUSH, MOV, CALL, etc. Still, the older machine-programmable processors used switches to set the 1's and 0's. Or, the machine code was fed in on perforated cards or tapes that were read. The computer read the switches, cards or tapes, and set voltages according to what it scanned. the difference is that machine code can be read directly, whereas assembler has to be compiled in order to convert the opcodes to binary data. > >> Both Linux and Windows compile down to binary files, which are >> essentially 1's and 0's arranged in codes that are meaningful to >> the processor. > >(Not really -- object code files are composed of header data and >different segments, data and code, and only the code segments are >really meaningful to the processor.) I agree that the code segments, and the data, are all that's meaningful to the processor. There are a few others, like interrupts that affect the processor directly. I understand what you're saying but I'm refering to an executable file ready to be loaded into memory. It's stored on disk in a series of 1's and 0's. As you say, there are also control codes on disk to separate each byte along with CRC codes, timing codes, etc. However, that is all stripped off by the hard drive electronics. The actual file on disk is in a certain format that only the operating system understands. But once the code is read in, it goes into memory locations which hold individual arrays of bits. Each memory location holds a precise number of bits corresponding to the particular code it represents. For example, the ret instruction you mention below is represent by hex C3 (0xC3), which represents the bits 1111. That's a machine code, since starting at to , you have 256 different codes available. When those 1's and 0's are converted to volatges, the computer can analyze them and set circuits in action which will bring about the desired operation. Since Linux is written in C, it must convert down to machine code, just as Windows must. > >> Once a python py file is compiled into a pyc file, I can >> disassemble it into assembler. > >But you _do_ know that pyc files are Python byte code, and you could >only directly disassemble them to Python byte code directly? that's the part I did not understand, so thanks for pointing that out. What I disassembled did not make sense. I was looking for assembler code, but I do understand a little bit about how the interpreter reads them. For example, from os.py, here's part of the script: # Note: more names are added to __all__ later. __all__ = ["altsep", "curdir", "pardir", "sep", "pathsep", "linesep", "defpath", "name", "path", "devnull"] here's the disassembly from os.pyc: 0C0406 00 00 00 dd 6 0C0861 6C 74 73 65 70 74 db 'altsept' 0C0F06 00 00 00 dd 6 0C1363 75 72 64 69 72 74db 'curdirt' 0C1A06 00 00 00 dd 6 0C1E70 61 72 64 69 72 74 db 'pardirt' 0C2503 00 00 00 dd 3 0C2973 65 70db 'sep' 0C2C74 07 00 00 dd 774h 0C3000 db0 0C3170 61 74 68 73 65 70db 'pathsep' 0C3874 07 00 00 dd 774h 0C3C00 db0 0C3D6C 69 6E 65 73 65 70db 'linesep' 0C4474 07 00 00 dd 774h 0C4800 db0 0C4964 65 66 70 61 74 68db 'defpath' 0C5074 04 00 00 dd offset unk_474 0C5400 db0 0C556E 61 6D 65 db 'name' 0C5974 04 00 00 dd offset unk_474 0C5D00 db0
Re: translating Python to Assembler
> >> That's not the point, however. I'm trying to say that a processor >> cannot read a Python script, and since the Python interpreter as >> stored on disk is essentially an assembler file, > >It isn't; it's an executable. I appreciated the intelligent response I received from you earlier, now we're splitting hairs. :-) Assembler, like any other higher level language is written as a source file and is compiled to a binary. An executable is one form of a binary, as is a dll. When you view the disassembly of a binary, there is a distinct difference between C, C++, Delphi, Visual Basic, DOS, or even between the different file types like PE, NE, MZ, etc. But they all decompile to assembler. While they are in the binary format, they are exactly that...binary. Who would want to interpret a long string of 1's and 0's. Binaries are not stored in hexadecimal on disk nor are they in hexadecimal in memory. But, all the 1's and 0's are in codes when they are instructions or ASCII strings. No other high level language has the one to one relationship that assembler has to machine code, the actual language of the computer. Dissassemblers can easily convert a binary to assembler due to the one to one relationship between them. That can't be said for any other higher level language. Converting back to C or Python would be a nightmare, although it's becoming a reality. Converting a compiled binary back to hexadecimal is basically a matter of converting the binary to hexadecimal, as in a hex editor. There are exceptions to that, of course, especially with compound assembler statements that use extensions to differentiate between registers. > >> any Python script must be sooner or later be converted to >> assembler form in order to be read by its own interpreter. > >This "assembler form" is commonly referred to as "Python byte code". > thanks for pointing that out. It lead me to this page: http://docs.python.org/lib/module-dis.html where it is explained that the opcodes are in Include/opcode.h. I'll take a look at that. The light goes on. From opcode.h: #define PRINT_NEWLINE_TO 74 All the ASCIi strings end with 0x74 in the disassembly. I have noted that Python uses a newline as a line feed/carriage return. Now I'm getting it. It could all be disassembled with a hex editor, but a disassembler is better for getting things in order. OK. So the pyc files use those defs...that's cool. -- http://mail.python.org/mailman/listinfo/python-list
Programming Games with python, I know this subject was disccused need help
HI I would like to start to program games, with python, where to start? What packages I need,? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming Games with python, I know this subject was disccused need help
Goalie_Ca wrote: > Well, with these libraries you won't need much else. > > http://www.pygame.org/news.html > and > http://sourceforge.net/projects/pyallegro/ > > > Over G wrote: > > HI > > > > I would like to start to program games, with python, where to start? > > > > What packages I need,? > > > > Thanks. Thanks ofr the very quick answer! Still can you shad more light on the second link, what is project allegro ? thanks/ -- http://mail.python.org/mailman/listinfo/python-list
