code blocks in Python

Discussion in 'Python' started by Hung Jung Lu, Nov 22, 2003.

  1. Hung Jung Lu

    Hung Jung Lu Guest

    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
    Hung Jung Lu, Nov 22, 2003
    #1
    1. Advertising

  2. Hung Jung Lu

    John Roth Guest

    "Hung Jung Lu" <> wrote in message
    news:...
    > 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
    John Roth, Nov 22, 2003
    #2
    1. Advertising

  3. Hung Jung Lu

    Hung Jung Lu Guest

    "John Roth" <> wrote in message news:<>...
    > 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
    Hung Jung Lu, Nov 23, 2003
    #3
  4. On 22 Nov 2003 19:13:19 -0800, (Hung Jung Lu) wrote:

    >"John Roth" <> wrote in message news:<>...
    >> 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
    Bengt Richter, Nov 23, 2003
    #4
  5. Hung Jung Lu

    Hung Jung Lu Guest

    (Bengt Richter) wrote in message news:<bppdph$s4u$0@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, Nov 23, 2003
    #5
  6. Hung Jung Lu

    Hung Jung Lu Guest

    (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
    Hung Jung Lu, Nov 24, 2003
    #6
  7. (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
    Alexander Schmolck, Nov 24, 2003
    #7
  8. Hung Jung Lu

    Jeff Epler Guest

    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
    Jeff Epler, Nov 24, 2003
    #8
  9. Hung Jung Lu

    Hung Jung Lu Guest

    Jeff Epler <> wrote in message news:<>...
    > 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
    Hung Jung Lu, Nov 24, 2003
    #9
  10. 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
    Skip Montanaro, Nov 24, 2003
    #10
  11. Hung Jung Lu

    JCM Guest

    Hung Jung Lu <> 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, Nov 24, 2003
    #11
  12. Hung Jung Lu

    JCM Guest

    JCM <> wrote:
    > Hung Jung Lu <> 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.
    JCM, Nov 24, 2003
    #12
  13. Hung Jung Lu

    Hung Jung Lu Guest

    Skip Montanaro <> wrote in message news:<>...
    > 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
    Hung Jung Lu, Nov 24, 2003
    #13
  14. hjl> Skip Montanaro <> wrote in message news:<>...

    >> 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
    Skip Montanaro, Nov 24, 2003
    #14
  15. Hung Jung Lu

    Hung Jung Lu Guest

    Skip Montanaro <> wrote in message news:<>...
    >
    > 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
    Hung Jung Lu, Nov 24, 2003
    #15
  16. Hung Jung Lu

    John Roth Guest

    "Hung Jung Lu" <> wrote in message
    news:...
    > Skip Montanaro <> wrote in message

    news:<>...
    > >

    > 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
    John Roth, Nov 24, 2003
    #16
  17. 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
    Greg Ewing (using news.cis.dfn.de), Nov 25, 2003
    #17
  18. 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
    Skip Montanaro, Nov 25, 2003
    #18
  19. Hung Jung Lu

    Hung Jung Lu Guest

    "John Roth" <> wrote in message news:<>...
    > 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
    Hung Jung Lu, Nov 25, 2003
    #19
  20. Hung Jung Lu

    John Roth Guest

    news:...
    > "John Roth" <> wrote in message

    news:<>...
    > > 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
    John Roth, Nov 25, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Arjen
    Replies:
    3
    Views:
    424
    Scott Allen
    Feb 27, 2005
  2. root

    Re: code blocks in Python

    root, Nov 25, 2003, in forum: Python
    Replies:
    0
    Views:
    533
  3. Microsoft

    Controls that contain code: Code Blocks Not Supported

    Microsoft, Dec 14, 2005, in forum: ASP .Net Building Controls
    Replies:
    1
    Views:
    400
    Anthony Williams
    Dec 14, 2005
  4. matt
    Replies:
    1
    Views:
    238
    George Ogata
    Aug 6, 2004
  5. Steven Taylor
    Replies:
    9
    Views:
    235
    Brian Candler
    Apr 27, 2009
Loading...

Share This Page