lambda in list comprehension acting funny

[Chris Angelico]

Not necessarily *compile* time, but the distinction is between when the
function is defined (which may at compile time, or it may be at run time)
versus when the function is called.

I'd treat the def/lambda statement as "compile time" and the ()
operator as "run time".

ChrisA

 

[Steven D'Aprano]

I'd treat the def/lambda statement as "compile time" and the () operator
as "run time".

But function definitions occur at run time, not compile time -- they are
executable statements, not instructions to the compiler to define a
function.

For example:

py> dis("def f(x): return x+1") # Python 3.2
1 0 LOAD_CONST 0 (<code object f at 0xb7b57de0,
file "<dis>", line 1>)
3 MAKE_FUNCTION 0
6 STORE_NAME 0 (f)
9 LOAD_CONST 1 (None)
12 RETURN_VALUE

The code object is pre-compiled at compile time, but the function and
name-binding (the "def") doesn't occur until runtime.

At compile time, Python parses the source code and turns it into byte-
code. Class and function definitions are executed at run time, the same
as any other statement.

I'm not sure if this is a difference that makes a difference or not; I
think it is, but don't know enough about how closures and scoping rules
work in other languages to be sure that it does make a difference.

 

[Chris Angelico]

At compile time, Python parses the source code and turns it into byte-
code. Class and function definitions are executed at run time, the same
as any other statement.

Between the parse step and the 'def' execution, a code object is
created. When you call it, that code object already exists. Nothing
else really matters, unless there's a bug in the Python optimizer or
something weird like that. The nearest thing Python _has_ to a
"compile time" is the execution of def.

ChrisA

 

[Terry Reedy]

But function definitions occur at run time, not compile time -- they are
executable statements, not instructions to the compiler to define a
function.

The () operator is 'call time'. The main points are
a) the execution of def statements and lambda expressions and the
execution of calls happen at different run times.
b) default arg objects are calculated at def/lambda time.
c) names in def bodies and lambda expressions are resolved at call time.
and
d) people more often forget c) when thinking about lambda expressions
that for def statements.

 

[Hans Mulder]

Between the parse step and the 'def' execution, a code object is
created. When you call it, that code object already exists. Nothing
else really matters, unless there's a bug in the Python optimizer or
something weird like that. The nearest thing Python _has_ to a
"compile time" is the execution of def.

ChrisA

"Compile time" is the phase when your Python code is turned into byte
code, or a SyntaxError is raised. In this phase, a "code object" is
created for the function.

"Function definition time" is when the "def" command is executed.
In this phase, default arguments are computed, and a "function object"
is created. Among the attributes of the function object are the code
object, and "cell" objects containing the bindings for its non-local
variables. These bindings are used to read the variable's current
value at the time the function uses the variable.


-- HansM

 

[Robert Miles]

Arithmetic/Logic Unit

http://en.wikipedia.org/wiki/Arithmetic_logic_unit
http://en.wikipedia.org/wiki/74181
{diversion: http://en.wikipedia.org/wiki/VAX-11/780 -- incredible...
that used to be considered a "super-mini" when I worked on them; and now
would be shamed by most laptops except for the ability to support so
many users concurrently (let me know when a Windows laptop supports 32
VT-100 class connections <G>)}

Installing Cygwin (a Linux emulation) under Windows appears to add some
VT-100 support but without an easy way to find documentation on whether
it can support 32 of them or not.

I used to work on a VAX 11/780 and also a VAX 8600.

Cygwin has a version of Python available, in case you're interested.

Robert Miles