Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: What makes functions special?

Reply
Thread Tools

Re: What makes functions special?

 
 
Eric Snow
Guest
Posts: n/a
 
      07-10-2011
On Sat, Jul 9, 2011 at 6:21 PM, Terry Reedy <(E-Mail Removed)> wrote:
> On 7/9/2011 2:28 PM, Eric Snow wrote:
>>
>> A tracker issue [1] recently got me thinking about what makes
>> functions special. *The discussion there was regarding the distinction
>> between compile time (generation of .pyc files for modules and
>> execution of code blocks), [function] definition time, and [function]
>> execution time. *Definition time actually happens during compile time,

>
> Not true. For main modules, execution of each statement immediately follows
> compilation, but not for other modules, where compilation and caching of
> code objects may happen years before the function object is created.
>


So for non-main modules the function definition happens during module
compilation, and for all other code blocks (__main__, exec, etc.) it
happens during execution of the code block?

>> Functions are a special case in Python for providing a more optimized
>> execution of a code block in pure Python code. *And how is that? *When
>> the function is defined, a code object is generated for the function
>> body along with a few "static" details that will be used during
>> execution. *No other objects have code objects. *No other objects in
>> Python have this special optimization.

>
> A .pyc file is a serialized code object for a module.
>


I hadn't thought of it like that. Nice insight. In that case, do
[non-main] module definition and execution time have the same logical
separation as function phases do?

> As for the rest, I am not sure what you are asking.
>


Yeah, I have a real knack for communicating. Mostly I am just
trying to put together more pieces of the Python puzzle. In this case
I was trying to find out if the optimized execution of code objects
for functions is a part of the language or just an implementation
detail.

-eric

> Terry Reedy
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      07-10-2011
Eric Snow wrote:

> Mostly I am just
> trying to put together more pieces of the Python puzzle. In this case
> I was trying to find out if the optimized execution of code objects
> for functions is a part of the language or just an implementation
> detail.


You keep using that phrase, "optimized execution of code objects for
functions", but I have no idea what that means.

The best I can think of is that you are thinking along these lines...

"Suppose we have the source code to a function:

def spam(n):
return "SPAM"*n

To execute this, Python currently compiles the function into a code block,
and then when you call spam(n) elsewhere, Python executes the already
compiled code block.

Suppose instead an implementation of Python did not pre-compile the
function. Each time you called spam(n), the implementation would have to
locate the source code and interpret it on the spot. Would that be
allowed?"

If that's your question, then I would call that a Python interpreter using
c.1960 technology (as opposed to a byte-code compiler, which all the main
implementations currently are).

If that were the *only* difference, then I see no reason why it wouldn't be
allowed as an implementation of Python. A horribly slow implementation, but
still an implementation.

However, I doubt that would be the only difference. Given such a
simple-minded Python interpreter, it would be hard to provide expected
Python language features such as compiled code objects, closures, etc. You
would have to fake them somehow. Provided you could fake them sufficiently
well, then the lack of a byte-code compiler is just a quality of
implementation issue.

If that's *not* your question, them I'm stumped.




--
Steven

 
Reply With Quote
 
 
 
 
Eric Snow
Guest
Posts: n/a
 
      07-10-2011
On Sat, Jul 9, 2011 at 7:34 PM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> Eric Snow wrote:
>
>> Mostly I am just
>> trying to put together more pieces of the Python puzzle. *In this case
>> I was trying to find out if the optimized execution of code objects
>> for functions is a part of the language or just an implementation
>> detail.

>
> You keep using that phrase, "optimized execution of code objects for
> functions", but I have no idea what that means.
>
> The best I can think of is that you are thinking along these lines...
>
> "Suppose we have the source code to a function:
>
> def spam(n):
> * *return "SPAM"*n
>
> To execute this, Python currently compiles the function into a code block,
> and then when you call spam(n) elsewhere, Python executes the already
> compiled code block.
>


Yeah, that's pretty much it. Is that all there is to it? I was
saying optimized, but I guess there isn't much special optimization
going on then. Thanks for taking the time.

-eric

> Suppose instead an implementation of Python did not pre-compile the
> function. Each time you called spam(n), the implementation would have to
> locate the source code and interpret it on the spot. Would that be
> allowed?"
>
> If that's your question, then I would call that a Python interpreter using
> c.1960 technology (as opposed to a byte-code compiler, which all the main
> implementations currently are).
>
> If that were the *only* difference, then I see no reason why it wouldn't be
> allowed as an implementation of Python. A horribly slow implementation, but
> still an implementation.
>
> However, I doubt that would be the only difference. Given such a
> simple-minded Python interpreter, it would be hard to provide expected
> Python language features such as compiled code objects, closures, etc. You
> would have to fake them somehow. Provided you could fake them sufficiently
> well, then the lack of a byte-code compiler is just a quality of
> implementation issue.
>
> If that's *not* your question, them I'm stumped.
>
>
>
>
> --
> Steven
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      07-10-2011
On 7/9/2011 6:34 PM, Steven D'Aprano wrote:

> Suppose instead an implementation of Python did not pre-compile the
> function. Each time you called spam(n), the implementatio n would have to
> locate the source code and interpret it on the spot. Would that be
> allowed?"
>
> If that's your question, then I would call that a Python interpreter using
> c.1960 technology (as opposed to a byte-code compiler, which all the main
> implementations currently are).
>
> If that were the *only* difference, then I see no reason why it wouldn't be
> allowed as an implementation of Python. A horribly slow implementation, but
> still an implementation.


while and for loops would also be terribly slow if their bodies were not
compiled but were reinterpreted at the source code level for each loop.
Having to reinterpred the compiled byte code for each loop does make
them slower than compiled to native code C. Same as for functions.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What makes functions special? Eric Snow Python 2 07-10-2011 01:28 AM
Shared functions vs Non-Shared Functions tshad ASP .Net 11 05-27-2005 05:53 PM
please help me in distinguish redefining functions, overloading functions and overriding functions. Xiangliang Meng C++ 1 06-21-2004 03:11 AM
Help! Passing Templates functions to template functions ILLOGIC C++ 1 06-01-2004 10:51 PM
Exportable class functions as stand alone functions to .DLL or .SO Timothy Wong C++ 3 05-20-2004 01:44 PM



Advertisments