code blocks in Python

[Hung Jung Lu]

Hi,

I know people have talked about it before, but I am still really
confused from reading the old messages.

When I talk about code blocks, I am not talking about Lisp/Ruby/Perl,
so I am not making comparisons.

If you have a file, in Python you could do:

code = compile(code_string, 'FileName.py', 'exec')

and obtain a code object, which later on you can execute. That's the
kind of code block I have in mind. That is, no parameters, no
specification of scopes, no nothing else. Just a plain block of code
lines compiled into a code object.

It's not too much work to write a code string like:

my_codeblock = '''
x = x + 1
y = y + 2
'''

and then use compile() to turn it into a code object. But it seems to
me that Python could perfectly allow this syntax directly into the
language, something like:

codeblock my_codeblock:
x = x + 1
y = y + 2

so that users won't need to explicitly call the compile() function.
The advantage is that the codeblock is compiled at compile time, not
at run time, even if the codeblock is defined inside something else (a
class, a function, etc.)

Is there something obvious that I am missing here? Why isn't codeblock
part of the language? It seems to be an important building element for
meta-programming. Not only that, it seems to be much more fundamental
than functions. So, why isn't it part of Python? Any intrinsic
difficulties?

regards,

Hung Jung

[John Roth]

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e*************************@posting.google.co m...

Hi,

I know people have talked about it before, but I am still really
confused from reading the old messages.

When I talk about code blocks, I am not talking about Lisp/Ruby/Perl,
so I am not making comparisons.

If you have a file, in Python you could do:

code = compile(code_string, 'FileName.py', 'exec')

and obtain a code object, which later on you can execute. That's the
kind of code block I have in mind. That is, no parameters, no
specification of scopes, no nothing else. Just a plain block of code
lines compiled into a code object.

It's not too much work to write a code string like:

my_codeblock = '''
x = x + 1
y = y + 2
'''

and then use compile() to turn it into a code object. But it seems to
me that Python could perfectly allow this syntax directly into the
language, something like:

codeblock my_codeblock:
x = x + 1
y = y + 2

so that users won't need to explicitly call the compile() function.
The advantage is that the codeblock is compiled at compile time, not
at run time, even if the codeblock is defined inside something else (a
class, a function, etc.)

Is there something obvious that I am missing here? Why isn't codeblock
part of the language? It seems to be an important building element for
meta-programming. Not only that, it seems to be much more fundamental
than functions. So, why isn't it part of Python? Any intrinsic
difficulties?
Just some random observations. First, I'm not at all clear on
what you want it to do. Some examples would be helpful. There
are entirely too many different ways I could interpret your reference
to metaprogramming for me to understand the usage you have in
mind.

If you want it as a replacement for the badly crippled lambda statement,
then I think there's quite a bit of interest. What's holding that up is
syntax, and an appropriate syntax isn't entirely obvious.

If you want it to do something else, like act like it was actually
compiled where it will be invoked, with identifier resolution
and all, then that's a completely different subject.

John Roth


regards,

Hung Jung

[Hung Jung Lu]

"John Roth" <ne********@jhrothjr.com> wrote in message news:<vr************@news.supernews.com>...

Just some random observations. First, I'm not at all clear on
what you want it to do. Some examples would be helpful. There
are entirely too many different ways I could interpret your reference
to metaprogramming for me to understand the usage you have in
mind.
codeblock A:
x = 1
y = 2

codeblock B:
z = x + y
print z

exec A
exec B

This will be equivalent to writing the program:

x = 1
y = 2
z = x + y
print z
If you want it as a replacement for the badly crippled lambda statement,
then I think there's quite a bit of interest. What's holding that up is
syntax, and an appropriate syntax isn't entirely obvious.

Lambda is a totally different thing. Lambda is an anonymous
*function*. I emphasize *function* because functions take parameters
and return values. Code blocks are, well, blocks of code. No
parameters, no nothing else. Simple and plain blocks of code. Once you
have codeblocks, you wire them anyway you want. Think of them as
macros in C++, only that in Python you can wire them dynamically
during runtime. Python already does that. It's just that you need the
compile() function, your code string is not compiled until the
compile() function is executed, and the resulting object type is
"Code" (which is a fine name, even if the new keyword were
"codeblock".) Have you tried the compile() function?

regards,

Hung Jung

[Bengt Richter]

On 22 Nov 2003 19:13:19 -0800, hu********@yahoo.com (Hung Jung Lu) wrote:

"John Roth" <ne********@jhrothjr.com> wrote in message news:<vr************@news.supernews.com>...

Just some random observations. First, I'm not at all clear on
what you want it to do. Some examples would be helpful. There
are entirely too many different ways I could interpret your reference
to metaprogramming for me to understand the usage you have in
mind.

codeblock A:
x = 1
y = 2

codeblock B:
z = x + y
print z

exec A
exec B

This will be equivalent to writing the program:

x = 1
y = 2
z = x + y
print z

If you want it as a replacement for the badly crippled lambda statement,
then I think there's quite a bit of interest. What's holding that up is
syntax, and an appropriate syntax isn't entirely obvious.

Lambda is a totally different thing. Lambda is an anonymous
*function*. I emphasize *function* because functions take parameters
and return values. Code blocks are, well, blocks of code. No
parameters, no nothing else. Simple and plain blocks of code. Once you
have codeblocks, you wire them anyway you want. Think of them as
macros in C++, only that in Python you can wire them dynamically
during runtime. Python already does that. It's just that you need the
compile() function, your code string is not compiled until the
compile() function is executed, and the resulting object type is
"Code" (which is a fine name, even if the new keyword were
"codeblock".) Have you tried the compile() function?

I note that:

compile('a=123','','single') <code object ? at 0090D5A0, file "", line 1> import dis
dis.dis(compile('a=123','','single')) 1 0 LOAD_CONST 0 (123)
3 STORE_NAME 0 (a)
6 LOAD_CONST 1 (None)
9 RETURN_VALUE def foo(): a=123 ... dis.dis(foo)

1 0 LOAD_CONST 1 (123)
3 STORE_FAST 0 (a)
6 LOAD_CONST 0 (None)
9 RETURN_VALUE

So which code will you want when the compiler compiles an in-context block?
Will you want it to be a first-class object? Should you be able to
pass the code-block name to an arbitrary function or bind it globally, like you can
with compile's output? Are you willing to forego the optimized local access? Or want to
exec it later from anywhere? What should happen? You could call for magic creation of special
closures so that an exported code block would still refer back to the local name space
(which BTW could be interesting for generators to yield, to give external access to their
internal state). And what should assigning a function local codeblock to a global mean?
Maybe creating a one-shot generator where the codeblock could be used to preset state for
a single ordinary function call that re-uses previous state. Or should it just die like a
weak reference?

IOW, there are some things to think about, because the semantics could get interesting ;-)
It would be nice to have efficient local blocks, so you could write exec(locals()[switcharg])
or perhaps some more efficient builtin switch/case thing using them. The efficiency of
a large jump table (dict or tuple/list based) vs a chain of elifs is a good motivation for some uses,
but I wonder how common/important they are.

Regards,
Bengt Richter

[Hung Jung Lu]

bo**@oz.net (Bengt Richter) wrote in message news:<bp**********@216.39.172.122>...

>>> compile('a=123','','single') <code object ? at 0090D5A0, file "", line 1> >>> import dis
>>> dis.dis(compile('a=123','','single')) 1 0 LOAD_CONST 0 (123)
3 STORE_NAME 0 (a)
6 LOAD_CONST 1 (None)
9 RETURN_VALUE >>> def foo(): a=123 ... >>> dis.dis(foo)

1 0 LOAD_CONST 1 (123)
3 STORE_FAST 0 (a)
6 LOAD_CONST 0 (None)
9 RETURN_VALUE

So which code will you want when the compiler compiles an in-context block?

Will you want it to be a first-class object?
Yes, absolutely.
with compile's output? Are you willing to forego the optimized local access?
I know there is a performance issue, since in normal, local, non-named
codeblocks, local variables are retrieved by indices instead of names.
There is a question as how to hook up named codeblocks efficiently in
the scope of the non-named codeblocks. But one is gotta start
somewhere. Optimization comes later.
You could call for magic creation of special
closures so that an exported code block would still refer back to the local name space
(which BTW could be interesting for generators to yield, to give external access to their
internal state).
Again, something simple to start with. Closures comes later, if at all
necessary. I am not sure whether closure-like codeblocks are
fundamental enough, since they could be emulated by other means. E.g.

class generic: pass

codeblock A:
print c.x
c.x = 3

c1 = generic()
c2 = generic()
c1.x = 4
c1.code = A
c2.x = 5
c2.code = A

c = c1
exec c.code

c = c2
exec c.code
And what should assigning a function local codeblock to a global mean?
Maybe creating a one-shot generator where the codeblock could be used to preset state for
a single ordinary function call that re-uses previous state. Or should it just die like a
weak reference?
I don't know exactly what you mean by "function local codeblock". If
you refer to the function's code, currently accessible as f.func_code,
I've tried that, but it seems to bind things to the locals dictionary
of the function itself. Which is no good. E.g.:

def f():
x = 1

def g(x):
exec f.func_code
print x

g(2)
x = 3
exec f.func_code in globals()
print x

will print 2 and 3. I tried using exec...in... with various
namespaces, but the same thing. That is, the func_code remembers its
own local scope and refuses access/modify other local scopes. This is
very different from:

code = compile('x=1\n', '<string>', 'exec')

def g(x):
exec code
print x

g(2)
x = 3
exec code
print x

which will print 1 and 1. That is, smart enough to take x from the
respective local and global dictionaries.

----------

If by "function local codeblock" you mean codeblocks define inside the
scope of a function, I really don't think they should receive any
special treatment for optimization, since a codeblock should be an
object that can be passed around, and should be independent of where
they are defined. It's like if you have the number 3, which is an
object, you can pass it around to anywhere, regardless where it was
first defined. No complications from nested-scopes, closures, etc.
Functions get complicated exactly because they carry all these extra
baggages.

----------

Well, all these are the kinds of things to think about. But named
codeblocks have well-defined meaning on their own right, independent
of implementation details. Theoretically, codeblocks don't know
whether the names inside them are local or global. It's a late-binding
object.
but I wonder how common/important they are.

I can't say in the case you have described. However, in general
codeblocks are extremely useful, right now they are not used as
widely, I think simply because the codestrings are not compiled and
checked at compile time: you need one extra step invoking the
compile() function. Named codeblocks will solve a barrage of nuisances
in today's programming world. They helps in (a) code re-use, (b) code
modularization. By (a) I mean that the same codeblock could be used in
a lot of places. By (b) I mean that you can isolate the effects of
codeblocks, and do code replacements a la AOP (Aspect-Oriented
Programming.)

It's just weird that Python has the compile() function, but has no
named codeblocks. I really can't understand why.

regards,

Hung Jung

[Hung Jung Lu]

hu********@yahoo.com (Hung Jung Lu) wrote in message >

codeblock A:
x = 1
y = 2

codeblock B:
z = x + y
print z

exec A
exec B

This will be equivalent to writing the program:

x = 1
y = 2
z = x + y
print z

It just occurred to me a better syntax:

def A:
x = 1
y = 2

def B:
z = x + y
print z

No new keyword needed, beside, it uses the same keyword as function
definition, so the purpose of the code block is clear: it's something
that you will invoke.

A proper name for this type of meta-programming is "Linear
Meta-programming". Just like in algebra you have linear algebra and
non-linear algebra, in meta-programming you have all sorts of
non-linear ways of taking code pieces and turn them into other code
pieces, these include e.g.: (a) compiling: turning a character string
into a binary code string, (b) encryption, (c) macro/token
substitution, (d) tweaking with the internals like meta-classes, etc.
Linear meta-programming is much more modest and well-organized. It's
like sequencing DNA bands. Each statement is like a DNA nucleotide,
each codeblock is like a DNA band. You just want to sequence the
codeblocks properly, and at times replace one block with some other
block, or insert additional blocks.

I still have yet to hear any difficulties/complaints.

I refuse to believe that Python developers have NEVER considered this
extension to the language. So, what's the problem?

Hung Jung

[Alexander Schmolck]

hu********@yahoo.com (Hung Jung Lu) writes:

I still have yet to hear any difficulties/complaints.

OK: 1. the semantics of your proposed extension remain somewhat nebulous
2. the extension appears pretty useless (AFAICT, given 1.)
3. you still haven't provided an example that would demonstrate otherwise
(i.e. something interesting that could be more easily written with
python + your extension than with python now).

'as

[Jeff Epler]

On Sun, Nov 23, 2003 at 04:34:39PM -0800, Hung Jung Lu wrote:

I still have yet to hear any difficulties/complaints.
Suppose I write this:

def C:
x = x + 1

def a():
x = 2
exec C
print x

def b():
exec C

how will the implementation of "code blocks" deal with the fact that in
a, x is a fastlocal with a particular index, but in b there's no local
x? (In cpython, "bare exec" has a significant negative impact of the
performance of a function, because all variable accesses happen though
LOAD_NAME instead of LOAD_GLOBAL / LOAD_FAST. Any new block-oriented
feature should be designed to avoid this problem)
I refuse to believe that Python developers have NEVER considered this
extension to the language. So, what's the problem?

Extensions along these lines have often been discussed. Consider reading
the archives. "Macros", "code blocks", "with blocks", and "closures" are
all terms you might consider using if you are searching for past messages.

Jeff

[Hung Jung Lu]

Jeff Epler <je****@unpythonic.net> wrote in message news:<ma*************************************@pyth on.org>...

def C:
x = x + 1

def a():
x = 2
exec C
print x

def b():
exec C

how will the implementation of "code blocks" deal with the fact that in
a, x is a fastlocal with a particular index, but in b there's no local
x? (In cpython, "bare exec" has a significant negative impact of the
performance of a function, because all variable accesses happen though
LOAD_NAME instead of LOAD_GLOBAL / LOAD_FAST. Any new block-oriented
feature should be designed to avoid this problem)

I agree that performance could be made better. But that's an issue for
later. If codeblock becomes a fundamental building block of a language
(say, Python 3.0), I am sure there are tricks beyond the current
global/local/builtin namespaces mechanisms
(LOAD_NAME/LOAD_FAST/LOAD_GLOBAL). But performance is an issue for
later. I would like to remind people that the compile() function
exists and works in Python. For whatever discussion on this subject,
the first thing to do is to replace the codeblock definition with the
compile function() and analyze from there on. In this case,
C=compile('x=x+1\n', '<string>', 'exec').

regards,

Hung Jung

[Skip Montanaro]

Jeff> how will the implementation of "code blocks" deal with the fact
Jeff> that in a, x is a fastlocal with a particular index, but in b
Jeff> there's no local x?

hjl> I agree that performance could be made better. But that's an issue
hjl> for later....

You ignored Jeff's primary questions. What are the semantics of a named
code block such as you propose? What if it's executed in a context which
doesn't contain the variables it uses? What expressive power does it give
to Python that Python doesn't currently have?

Skip

[JCM]

Hung Jung Lu <hu********@yahoo.com> wrote:
....

It just occurred to me a better syntax: def A:
x = 1
y = 2 def B:
z = x + y
print z No new keyword needed, beside, it uses the same keyword as function
definition, so the purpose of the code block is clear: it's something
that you will invoke.

I dislike this because it looks too much like function definition
(which I realize was your intent). The problem is that name-lookup in
function bodies is lexical, but the proposed semantics for name-lookup
in codeblocks is dynamic.

[JCM]

JCM <jo******************@myway.com> wrote:

Hung Jung Lu <hu********@yahoo.com> wrote:
...

It just occurred to me a better syntax: def A:
x = 1
y = 2 def B:
z = x + y
print z No new keyword needed, beside, it uses the same keyword as function
definition, so the purpose of the code block is clear: it's something
that you will invoke.

I dislike this because it looks too much like function definition
(which I realize was your intent). The problem is that name-lookup in
function bodies is lexical, but the proposed semantics for name-lookup
in codeblocks is dynamic.

Sorry, that was badly worded. Take 2:

The problem is that name-lookup in function bodies is lexical at the
point of definition, but the proposed semantics for name-lookup in
codeblocks is lexical at the point of use.

[Hung Jung Lu]

Skip Montanaro <sk**@pobox.com> wrote in message news:<ma*************************************@pyth on.org>...

You ignored Jeff's primary questions. What are the semantics of a named
code block such as you propose? What if it's executed in a context which
doesn't contain the variables it uses? What expressive power does it give
to Python that Python doesn't currently have?

And you ignored my reply. :)

I will repeat once more: the compile() function exists and works in
Python. Please try the compile() function first before posting. Thank
you very much! Please people, how many times do I have to say it???
Everything you want to know about the semantics, the what ifs (like:
"what if it's executed in a context which doesn't contain the
variables it uses?"), is already answered when you try to spend 30
seconds using the compile() function. If you can't spend 30 seconds
trying out the compile() function, then I am sorry I can't help you!
:)

As for the expressive power, it'll be part of PEP, if there is a PEP.
That part I don't worry. But first let us collect complaints and get
to know if there are previous attempts.

regards,

Hung Jung

[Skip Montanaro]

hjl> Skip Montanaro <sk**@pobox.com> wrote in message news:<ma*************************************@pyth on.org>...

You ignored Jeff's primary questions. What are the semantics of a
named code block such as you propose? What if it's executed in a
context which doesn't contain the variables it uses? What expressive
power does it give to Python that Python doesn't currently have?
hjl> And you ignored my reply. :)

hjl> I will repeat once more: the compile() function exists and works in
hjl> Python. Please try the compile() function first before
hjl> posting.

You should be able to express the desired semantics of your extension to the
language without requiring us to execute code. I have yet to see an
explanation of why you want

def c:
x += 1

added to the language. I can guess that it binds c to a "code block". How
do I use it? The above is illegal syntax in Python today. Am I supposed to
guess how to use it? That has nothing to do with compile(). Am I supposed
to run it with the exec statement or do you envision me just inserting

c

into my code?

hjl> Thank you very much! Please people, how many times do I have to say
hjl> it??? Everything you want to know about the semantics, the what
hjl> ifs (like: "what if it's executed in a context which doesn't
hjl> contain the variables it uses?"), is already answered when you try
hjl> to spend 30 seconds using the compile() function. If you can't
hjl> spend 30 seconds trying out the compile() function, then I am sorry
hjl> I can't help you! :)

Okay, so I ran compile():

compile("x += 1", "<string>", "exec") <code object ? at 0xb3d2e0, file "<string>", line 1>

Now what? Before you complain, I ran exec as well:
d = {'x': 1}
exec c in d
d['x']

2

What exactly have you given me that I couldn't have done with

x = 1
x += 1

? None of what you have said so far has provided me with any motivation why
this construct should be added to the language.

Skip

[Hung Jung Lu]

Skip Montanaro <sk**@pobox.com> wrote in message news:<ma*************************************@pyth on.org>...

You should be able to express the desired semantics of your extension to the
language without requiring us to execute code. I have yet to see an
explanation of why you want

def c:
x += 1

added to the language. I can guess that it binds c to a "code block". How
do I use it? The above is illegal syntax in Python today. Am I supposed to
guess how to use it? That has nothing to do with compile(). Am I supposed
to run it with the exec statement or do you envision me just inserting

c

into my code?
Skip: being you a Python old timer, I think you are just grumbling for
no good reason. :)

Before anything else, people are already jumping into implementation
details, optimization, syntax, etc. I am barely starting to look at
whether there have been previous existing efforts, and if so, why were
they discarded, etc.

What exactly have you given me that I couldn't have done with

x = 1
x += 1

I come back again to repeat it one more time: the compile() function
already exists and works in Python. Before you do your posting, please
think about the compile() function first. (Do I need to say it one
more time? I don't mind.)

So, let me try to pretend I am Skip Montanaro, and follow through with
the process.

(a) OK, I have been told that compile() function exists in
Python.
(b) I am complaining that I can do
x = 1
x += 1
without resorting to codeblocks. So there is no need for
codeblocks. Codeblocks are useless, good for nothing.
(c) OK, one more time, I have been told that compile() function
exists and works in Python. Everytime I talk about codeblocks,
I need to think about the compile() function first.
(d) Aha! So by analogy, there is no need for the compile()
function in Python. I get it now!
(e) Wait a second... searching through the Python newsgroup
archive I find hundreds if not thousands of messages
related to the usage of the compile() function. So the
compile() function can't be useless. Either thousands of
Python users are wrong, or I have not been careful in my
thinking process.
(f) Hmm... let me look at those messages and try to understand
how people are using the compile() function.
(g) Aha! The compile() function is not useless. I know how to
use it, now.
(h) Aha! Codeblocks are not useless.
(i) Aha! So codeblocks are analogous to the compile() function,
the only difference is that codeblocks are compiled at
compile time. The compile function compiles the code string
at runtime.
(j) Wait, I think Hung Jung has said everything before in his
messages.

Bingo! Now you get it.

Hung Jung

[John Roth]

"Hung Jung Lu" <hu********@yahoo.com> wrote in message
news:8e**************************@posting.google.c om...

Skip Montanaro <sk**@pobox.com> wrote in message

news:<ma*************************************@pyth on.org>...

I come back again to repeat it one more time: the compile() function
already exists and works in Python. Before you do your posting, please
think about the compile() function first. (Do I need to say it one
more time? I don't mind.)

So what?

Functionality is not added to Python simply because it looks like
a logical extension of something else that already exists. First,
you need to show a compelling use case.

So far, I've seen one thing in your proposal: dynamic binding
of free variables in a function, rather than static binding. All
questions of syntax aside, please show me why this matters,
bearing in mind that I've never programmed in a language
that has this, and am not going to be convinced by references
to such languages.

While I'm not *the* person that has to be convinced (that's Guido),
I'm probably representative. If you don't manage a compelling
case for why dynamic binding is a useful option, then you're not going
to get anywhere with this proposal.

By the way - if I understand the guts of the proposal, the compile
function has nothing to do with it, and wouldn't be used to implement
it in any case.

John Roth

[Greg Ewing (using news.cis.dfn.de)]

Hung Jung Lu wrote:

Is there something obvious that I am missing here? Why isn't codeblock
part of the language?

When code blocks are discussed, it's usually in the context of
user-defined control structures. For that, you need a way of
writing code blocks in-line where they're needed. You also
need a way of defining and using new control structures, and
some way of passing parameters to the code block would be
highly desirable. New syntax would be needed for all these.

Just having code blocks on their own without any of those
other things doesn't seem all that useful to me.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Skip Montanaro]

hjl> Skip: being you a Python old timer, I think you are just grumbling
hjl> for no good reason. :)

hjl> Before anything else, people are already jumping into
hjl> implementation details, optimization, syntax, etc. I am barely
hjl> starting to look at whether there have been previous existing
hjl> efforts, and if so, why were they discarded, etc.

I'm not asking about implementation details, optimization, syntax. All
you've told me is "the compile() function already exists and works in
Python". I understand that. I am completely missing the connection between
"I would like to see code blocks added to Python" and "the compile()
function already exists and works in Python". Just because you have one
doesn't mean you need the other.

Are you just looking for syntactic sugar for the compile() function? If so,
I'm going to have to vote against it. I've been using Python for about 10
years and can't ever remember using the builtin compile() function in my own
code. In fact, for the first year or two I programmed in Python I wasn't
even aware it existed and used to import the compile function from the old
regex module as "from regex import compile".

hjl> (d) Aha! So by analogy, there is no need for the compile() function
hjl> in Python. I get it now!

Fine with me. I've never used it. ;-)

hjl> (e) Wait a second... searching through the Python newsgroup archive
hjl> I find hundreds if not thousands of messages related to
hjl> the usage of the compile() function. So the compile() function
hjl> can't be useless. Either thousands of Python users are wrong,
hjl> or I have not been careful in my thinking process.

I think you're dreaming here.

hjl> Bingo! Now you get it.

I think you built your logic on a false premise: namely that lots of people
use the compile() builtin. If you google for something like "Python
compile", I'll wager almost every hit will be about:

1. compiling Python itself,

2. the Python byte code compiler (to which the compile() function is
only a rarely used interface), or

3. compiling regular expressions

and most of the hits which are actually about the compile() builtin will be
links to pages which document it.

Skip

[Hung Jung Lu]

"John Roth" <ne********@jhrothjr.com> wrote in message news:<vs************@news.supernews.com>...

I'm probably representative. If you don't manage a compelling
case for why dynamic binding is a useful option, then you're not going
to get anywhere with this proposal.

Wow, I did not even know there was a proposal. :)

I thought the purpose of my message was to find out whether there have
been previous attempts. I still have not gotten an answer, and I see
already lots of fire. For no good reason.

As I have said, I refuse to believe I am the first person to bring up
this topic. Because it seems such a simple issue, such a simple
feature. (Bear in mind that the compile() function exists since a long
long time ago.) So, I am prepared to listen to experts comment on why
everything is wrong and un-doable, and that the topic has been covered
many times before and is dead since a long time ago. So that I can
simply stop. Yet, I have heard none to the effect.

------------------

Like someone said once about metaclasses: if you need to ask if you
need to use metaclasses, the answer is "you don't". Same thing with
metaprogramming. If you need to ask whether you need metaprogramming,
the answer is: "you don't". People that get into metaclasses and
metaprogramming know what they want to do.

If you have really read and digested my comment about thinking first
on compile() function and post later, you wouldn't have posted your
message.

There are two issues here:

(1) The usefulness of meta-programming.
(2) Codeblock feature.

You are asking the question about (1), not (2). My impression is that
you have no experience using compile() function, nor general idea
about metaprogramming. (Feel free to correct me.) But you decide to
use it as an argument to attack (2) anyway, instead of (1). Your
firepower is misplaced, and causes only colateral damages.

Usefulness of meta-programming (in particular, linear
meta-programming) is a completely different subject. If you don't like
metaprogramming, you should have attacked Guido a long time ago, when
the compile() function and code object appeared in Python. That's what
I mean by you need to keep the compile() function in mind before you
make senseless comments about dynamic binding and linking it to (2).

You need to first make that distinction in mind. Your mistake and of
the others comes from your unfamiliarity with the usage of code
objects. Your questions are not regarding codeblock implementation.
Your questions are about metaprogramming in general.

Sure, I'm more than glad to discuss about linear metaprogramming,
despite of having discussed with tons of other Python regulars lots of
times before. But before that, I'd like to make sure about my original
point: has the idea of codeblock ever been discussed in Python? When
and where and the URL links. I am still waiting.

regards,

Hung Jung

[John Roth]

news:8e*************************@posting.google.co m...

"John Roth" <ne********@jhrothjr.com> wrote in message news:<vs************@news.supernews.com>...

I'm probably representative. If you don't manage a compelling
case for why dynamic binding is a useful option, then you're not going
to get anywhere with this proposal.

Wow, I did not even know there was a proposal. :)

I thought the purpose of my message was to find out whether there have
been previous attempts. I still have not gotten an answer, and I see
already lots of fire. For no good reason.

As I have said, I refuse to believe I am the first person to bring up
this topic. Because it seems such a simple issue, such a simple
feature. (Bear in mind that the compile() function exists since a long
long time ago.) So, I am prepared to listen to experts comment on why
everything is wrong and un-doable, and that the topic has been covered
many times before and is dead since a long time ago. So that I can
simply stop. Yet, I have heard none to the effect.

Try Google Groups.

------------------

Like someone said once about metaclasses: if you need to ask if you
need to use metaclasses, the answer is "you don't". Same thing with
metaprogramming. If you need to ask whether you need metaprogramming,
the answer is: "you don't". People that get into metaclasses and
metaprogramming know what they want to do.

If you have really read and digested my comment about thinking first
on compile() function and post later, you wouldn't have posted your
message.
Rudeness objection. You're mind reading. You have no
idea what I'm thinking, or what my background is.

There are two issues here:

(1) The usefulness of meta-programming.
(2) Codeblock feature.

You are asking the question about (1), not (2). My impression is that
you have no experience using compile() function, nor general idea
about metaprogramming. (Feel free to correct me.) But you decide to
use it as an argument to attack (2) anyway, instead of (1). Your
firepower is misplaced, and causes only colateral damages.

Rudeness objection. What I know or don't know isn't of issue.
Since you said you don't have a clear use case, my participation
in this discussion is ended.

John Roth

[Florian Reiser]

Hi folks,

I have read your thread about code blocks.
When reading it, a problem that I have came to my mind.
I have a module ZReportLab. This module defines a class for Zope
(http://www.zope.org) for using the reportlab library.
The actual code I want the object to execute is stored in three string
variables, compiled at change time with compile()
and executed, when the object is called. So I can use a different content
code for each object I have created in the object database
of Zope.
But no one programs without errors, so every time I've made an error, I get
a traceback holding the information that there's an error,
inside my code object.
It would be nice if I could debug it with pdb. But at the moment I have to
guess where the error is, or step towards it, through inserting
a raise and trying if it runs to the position of the raise. This is really
hard work.
How can I compile my code object, so that I can debug it when I do the exec
codeObject?

Regards
Florian Reiser

"Hung Jung Lu" <hu********@yahoo.com> schrieb im Newsbeitrag
news:8e*************************@posting.google.co m...

Hi,

I know people have talked about it before, but I am still really
confused from reading the old messages.

When I talk about code blocks, I am not talking about Lisp/Ruby/Perl,
so I am not making comparisons.

If you have a file, in Python you could do:

code = compile(code_string, 'FileName.py', 'exec')

and obtain a code object, which later on you can execute. That's the
kind of code block I have in mind. That is, no parameters, no
specification of scopes, no nothing else. Just a plain block of code
lines compiled into a code object.

It's not too much work to write a code string like:

my_codeblock = '''
x = x + 1
y = y + 2
'''

and then use compile() to turn it into a code object. But it seems to
me that Python could perfectly allow this syntax directly into the
language, something like:

codeblock my_codeblock:
x = x + 1
y = y + 2

so that users won't need to explicitly call the compile() function.
The advantage is that the codeblock is compiled at compile time, not
at run time, even if the codeblock is defined inside something else (a
class, a function, etc.)

Is there something obvious that I am missing here? Why isn't codeblock
part of the language? It seems to be an important building element for
meta-programming. Not only that, it seems to be much more fundamental
than functions. So, why isn't it part of Python? Any intrinsic
difficulties?

regards,

Hung Jung