On 28/05/13 21:15, Jim Mooney wrote:
I think authors miss a didactic opportunity by not using bytecode as a
teaching tool now and then, since it's easily explained, at least for
basic statements.
Assuming you mean the assembler statements then it may be true.
Looking at Bytecode is just an exe
On 28 May 2013 04:18, Dave Angel wrote:
> On 05/28/2013 07:02 AM, Jim Mooney wrote:
> Alan and Devin already gave more specifics, but to repeat,
>
> import dis
>
> dis.dis(myfunction)
>
> will disassemble one function.
I think authors miss a didactic opportunity by not using bytecode as a
teachi
On Tue, May 28, 2013 at 1:58 PM, Oscar Benjamin
wrote:
>
> So what happens to the code object for the top-level code in the
> module itself when it is imported in the normal way? Is it just
> discarded once import is complete? Is it temporarily accessible during
> import?
Normally, nothing holds
On 28 May 2013 18:24, eryksun wrote:
> On Tue, May 28, 2013 at 1:12 PM, Oscar Benjamin
> wrote:
>> On 28 May 2013 17:48, eryksun wrote:
>>>
>>> The argument for dis.dis() can be a module, class, function or code
>>> object. It disassembles all the top-level code objects that it finds,
>>> but it
On Tue, May 28, 2013 at 1:12 PM, Oscar Benjamin
wrote:
> On 28 May 2013 17:48, eryksun wrote:
>>
>> The argument for dis.dis() can be a module, class, function or code
>> object. It disassembles all the top-level code objects that it finds,
>> but it doesn't recursively disassemble code objects t
On 28 May 2013 17:48, eryksun wrote:
> On Tue, May 28, 2013 at 7:18 AM, Dave Angel wrote:
>>
>> dis.dis(myfunction)
>>
>> will disassemble one function.
>>
>> That's not all that's in the byte-code file, but this is 98% of what you
>> probably want out of it. And you can do it in the debugger wi
On Tue, May 28, 2013 at 7:18 AM, Dave Angel wrote:
>
> dis.dis(myfunction)
>
> will disassemble one function.
>
> That's not all that's in the byte-code file, but this is 98% of what you
> probably want out of it. And you can do it in the debugger with just the
> standard library.
The argument f
On 05/28/2013 07:02 AM, Jim Mooney wrote:
On 27 May 2013 16:20, Alan Gauld wrote:
To me, the bytecodes are the literal hex values corresponding
to the Python "assembler" statements. Are you sure you need the bytecodes?
You can use the standard library to generate the
assembler listing from th
On 27 May 2013 16:32, Steven D'Aprano wrote:
> On 28/05/13 06:01, Jim Mooney wrote:
> Shall we guess what package that is? I love guessing games!
>
> Ah, who am I kidding. No I don't.
>
Well, I would hate to keep you guessing ;') It's called decompyle -
pip couldn't find it, though, and it requi
On 27 May 2013 16:20, Alan Gauld wrote:
>
> To me, the bytecodes are the literal hex values corresponding
> to the Python "assembler" statements. Are you sure you need the bytecodes?
> You can use the standard library to generate the
> assembler listing from the Python code.
Ah good, how do I do
On Mon, May 27, 2013 at 4:01 PM, Jim Mooney wrote:
> I was looking at the bytecode doc page as a break from the Lutz book,
> since I like Assembler-type code due to its total non-ambiguity, but
> the page doesn't say much. Is there a doc somewhere that corresponds
> some of the bytecode to Python
On 05/27/2013 07:56 PM, ALAN GAULD wrote:
I can't speak for Jim, but I have used the dis module in the past to
quickly check how python parsed an expression (e.g. not x is y).
Yes, I've done that too. But that's not the bytecodes (at least not what
I understand as bytecodes) that's the dis-asse
On 28/05/2013 00:32, Steven D'Aprano wrote:
On 28/05/13 06:01, Jim Mooney wrote:
Another question. I tried installing a package that back-compiles (in
win 7), so I could see things that way, and got the error
"Unable to find vcvarsall.bat"
Shall we guess what package that is? I love guessing g
I can't speak for Jim, but I have used the dis module in the past to
>quickly check how python parsed an expression (e.g. not x is y).
>Yes, I've done that too. But that's not the bytecodes (at least not what
I understand as bytecodes) that's the dis-assembly listing which is
usually far more use
On 28/05/13 06:01, Jim Mooney wrote:
I was looking at the bytecode doc page as a break from the Lutz book,
since I like Assembler-type code due to its total non-ambiguity, but
the page doesn't say much. Is there a doc somewhere that corresponds
some of the bytecode to Python source? I thought rot
On Mon, May 27, 2013 at 7:20 PM, Alan Gauld wrote:
> Can you give a use case of how you think you could use them?
> There may be another way to do what you want.
I can't speak for Jim, but I have used the dis module in the past to
quickly check how python parsed an expression (e.g. not x is y).
On 27/05/13 21:21, Jim Mooney wrote:
Oscar Benjamin
What do you want these for? I've never needed to know what the
interpreter's bytecodes are.
I programmed A86 Assembler years ago, and just find the bytecode has a
comfortable clarity as a learning tool,
To me, the bytecodes are the litera
Oscar Benjamin
> What do you want these for? I've never needed to know what the
> interpreter's bytecodes are.
I programmed A86 Assembler years ago, and just find the bytecode has a
comfortable clarity as a learning tool, at least for me. When an
author vaguely tried to explain that a Name in Py
On 27 May 2013 21:01, Jim Mooney wrote:
>
> I was looking at the bytecode doc page as a break from the Lutz book,
> since I like Assembler-type code due to its total non-ambiguity, but
> the page doesn't say much. Is there a doc somewhere that corresponds
> some of the bytecode to Python source? I
I was looking at the bytecode doc page as a break from the Lutz book,
since I like Assembler-type code due to its total non-ambiguity, but
the page doesn't say much. Is there a doc somewhere that corresponds
some of the bytecode to Python source? I thought rot_1, 2, 3, and 4
looked useful, but it w
20 matches
Mail list logo
