function prototyping?

[Burton Samograd]

Hi,

Is there any way to 'prototype' functions in python, as you would in
C? Would that be what the 'global' keyword is for, or is there a more
elegant or 'pythonic' way of doing forward references?

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com

[Duncan Booth]

Burton Samograd wrote:

Is there any way to 'prototype' functions in python, as you would in
C? Would that be what the 'global' keyword is for, or is there a more
elegant or 'pythonic' way of doing forward references?

There isn't really such a thing as a forward reference in Python. Always
remember that 'def' and 'class' are executable statements:

def a():
b()

def b():
print "b called"

a()

So long as you have executed both def statements before you call the first
function it will find the second one. In the example above, if you called
a() before executing 'def b()' the function 'b' wouldn't exist so you
couldn't call it.

[Burton Samograd]

Duncan Booth <du**********@invalid.invalid> writes:

Burton Samograd wrote:

Is there any way to 'prototype' functions in python, as you would in
C? Would that be what the 'global' keyword is for, or is there a more
elegant or 'pythonic' way of doing forward references?

There isn't really such a thing as a forward reference in Python. Always
remember that 'def' and 'class' are executable statements:

Ok, we'll here's what I'm trying to do. I have a dictionary that I
would like to initialize in a module file config.py:

-- config.py -------------------------
global a_fun, b_fun
dict = {
'a': a_fun,
'b': b_fun
}
--------------------------------------

where a_fun and b_fun are in fun.py:

-- fun.py ----------------------------
def a_fun(): pass
def b_fun(): pass

import config
def main():
config.dict['a']()
config.dict['b']()
main()
--------------------------------------

I like having the module/namespace seperation with the configuration
variables but I would like to make them easily (re)defined in the
configuration file by the user. Does python have the idea of a 'weak'
reference or lazy style evaluation for the definition of the dict in
the config file above so I can achive what i'm tryin to do?
--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com

[bruno at modulix]

Burton Samograd wrote:

Duncan Booth <du**********@invalid.invalid> writes:

Burton Samograd wrote:

Is there any way to 'prototype' functions in python, as you would in
C? Would that be what the 'global' keyword is for, or is there a more
elegant or 'pythonic' way of doing forward references?

There isn't really such a thing as a forward reference in Python. Always
remember that 'def' and 'class' are executable statements:

Ok, we'll here's what I'm trying to do. I have a dictionary that I
would like to initialize in a module file config.py:

-- config.py -------------------------
global a_fun, b_fun
dict = {

dont use 'dict' as an identifier, it shadows the builtin dict type.
'a': a_fun,
'b': b_fun
}
--------------------------------------

where a_fun and b_fun are in fun.py:

-- fun.py ----------------------------
def a_fun(): pass
def b_fun(): pass
Until this point, everything is (almost) fine. You'd just need to
rewrite config.py so it imports a_fun and b_fun from fun.py:

#-- config.py -------------------------
import fun
conf = {
'a': fun.a_fun,
'b': fun.b_fun
}
# --------------------------------------

But then, we have this :
import config
And then we have a circular import...

*But* is it necessary to have the main() in the same file that defines
a_fun and b_fun ? It's quite common (and not only in Python) to use a
distinct file for the main(). So you can easily solve your problem by
splitting fun.py into fun.py and main.py:

#-- main.py -------------------------
import config
def main(*args):
config.dict['a']()
config.dict['b']()

# here we have a python trick:
if __name__ == '__main__':
import sys
sys.exit(main(*sys.argv[1:])
# --------------------------------------

I like having the module/namespace seperation with the configuration
variables but I would like to make them easily (re)defined in the
configuration file by the user.
You may want to look at one of the existing configuration modules.
Does python have the idea of a 'weak'
reference

Yes, but that's something totally different.

(snip)

HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[infidel]

If you want the user to be able to (re)define them in config.py, why
not just define them there in the first place? I may be wrong, but I
think "global" means "module level" rather than "interpreter level".

[Burton Samograd]

"infidel" <sa***********@gmail.com> writes:

If you want the user to be able to (re)define them in config.py, why
not just define them there in the first place? I may be wrong, but I
think "global" means "module level" rather than "interpreter level".

That's what I'm trying to do but I'm running into problems with
the function values, since they haven't been defined yet.

I'm a C programmer, so I'm doing it in a bit of a C like way;
prototype the function, initalize the array using the prototypes, have
the functions defined somewhere else and then let the linker work it
all out for me. I was hoping that python had some sort of lazy
evaluation scheme for this type of behaviour so that you could defer
linkage (or variable evalutation) until runtime, or at least variable
reference (through the use of thunks or some sort). Maybe I was
hoping for too much :)

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com

[Burton Samograd]

bruno at modulix <on***@xiludom.gro> writes:

Burton Samograd wrote:

Duncan Booth <du**********@invalid.invalid> writes:

dont use 'dict' as an identifier, it shadows the builtin dict type.

just an example i jotted down, not real code.

'a': a_fun,
'b': b_fun
}
--------------------------------------

where a_fun and b_fun are in fun.py:

-- fun.py ----------------------------
def a_fun(): pass
def b_fun(): pass

Until this point, everything is (almost) fine. You'd just need to
rewrite config.py so it imports a_fun and b_fun from fun.py:

#-- config.py -------------------------
import fun
conf = {
'a': fun.a_fun,
'b': fun.b_fun
}
# --------------------------------------

But then, we have this :

import config

And then we have a circular import...

*But* is it necessary to have the main() in the same file that defines
a_fun and b_fun ? It's quite common (and not only in Python) to use a
distinct file for the main(). So you can easily solve your problem by
splitting fun.py into fun.py and main.py:

ah yes, that might be a good idea. I'm just hacking together a
prototype right now and I'm thinking in C'isms still, so maybe I'll
modularize it a bit more to see if that could solve the problem.

I like having the module/namespace seperation with the configuration
variables but I would like to make them easily (re)defined in the
configuration file by the user.

You may want to look at one of the existing configuration modules.

I like the idea of using python as the configuration system, plus this
is giving me a good exercise with learning more of the language so I'm
going to stick with it for a bit, at least until my questions get too
annoying ;-)

Does python have the idea of a 'weak'
reference

Yes, but that's something totally different.

Care to describe?

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com

[bruno at modulix]

Burton Samograd wrote:

bruno at modulix <on***@xiludom.gro> writes:
(snip)

*But* is it necessary to have the main() in the same file that defines
a_fun and b_fun ? It's quite common (and not only in Python) to use a
distinct file for the main(). So you can easily solve your problem by
splitting fun.py into fun.py and main.py:

ah yes, that might be a good idea. I'm just hacking together a
prototype right now and I'm thinking in C'isms still,

Yeps. Python is easy to get started with, but when it comes to idioms,
it's definitively not C.

(snip)

Does python have the idea of a 'weak'
reference

Yes, but that's something totally different.

Care to describe?

This is in the fine manual. Look for weakref.

Enjoy
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on***@xiludom.gro'.split('@')])"

[bruno at modulix]

Burton Samograd wrote:

"infidel" <sa***********@gmail.com> writes:

If you want the user to be able to (re)define them in config.py, why
not just define them there in the first place? I may be wrong, but I
think "global" means "module level" rather than "interpreter level".

That's what I'm trying to do but I'm running into problems with
the function values, since they haven't been defined yet.

I'm a C programmer, so I'm doing it in a bit of a C like way;
prototype the function, initalize the array using the prototypes, have
the functions defined somewhere else and then let the linker work it
all out for me. I was hoping that python had some sort of lazy
evaluation scheme for this type of behaviour so that you could defer
linkage (or variable evalutation) until runtime, or at least variable
reference (through the use of thunks or some sort). Maybe I was
hoping for too much :)

It's not a problem of "hoping for too much", but a problem of paradigm
shift. You're actually *thinking* in C, and Python is a *completely
different* language. You just can't directly transpose C idioms in
Python - nor could you transpose much Python idioms in C. So you need to
'go down a level' and consider the real problem and how to solve it the
Python way - not how to implement the C-ish solution in Python.
My 2 cents
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"

[Peter Otten]

Burton Samograd wrote:

Duncan Booth <du**********@invalid.invalid> writes:

Burton Samograd wrote:

> Is there any way to 'prototype' functions in python, as you would in
> C? Would that be what the 'global' keyword is for, or is there a more
> elegant or 'pythonic' way of doing forward references?
>

There isn't really such a thing as a forward reference in Python. Always
remember that 'def' and 'class' are executable statements:

Ok, we'll here's what I'm trying to do. I have a dictionary that I
would like to initialize in a module file config.py:

-- config.py -------------------------
global a_fun, b_fun
dict = {
'a': a_fun,
'b': b_fun
}
--------------------------------------

where a_fun and b_fun are in fun.py:

-- fun.py ----------------------------
def a_fun(): pass
def b_fun(): pass

import config
def main():
config.dict['a']()
config.dict['b']()
main()
--------------------------------------

I like having the module/namespace seperation with the configuration
variables but I would like to make them easily (re)defined in the
configuration file by the user. Does python have the idea of a 'weak'
reference or lazy style evaluation for the definition of the dict in
the config file above so I can achive what i'm tryin to do?

I'd say Python has *only* that idea, but as a practical approach the
following might be easiest:

-- config.py --
a = a_fun # As a_fun is nowhere defined, config.py cannot be
# used stand-alone and may be hard to test.
b = b_fun
def c():
print "c-fun"

-- fun.py --
def a_fun(): print "a-fun"
def b_fun(): print "b-fun"

execfile("config.py") # Think #include <config.py>

def main():
a()
b()
c()

if __name__ == "__main__":
main()

A slightly stricter variant avoids cycles by using three modules:

-- fun.py --
def a_fun(): print "a-fun"
def b_fun(): print "b-fun"

-- config.py --
import fun

a = fun.a_fun
b = fun.b_fun

-- main.py --
import config

def main():
config.a()
config.b()

if __name__ == "__main__":
main()

Thanks to the if... guard you could put the main.py code into fun.py, too,
but I suppose it's easier to understand with three files.

Peter

[Burton Samograd]

bruno at modulix <on***@xiludom.gro> writes:

Burton Samograd wrote:

"infidel" <sa***********@gmail.com> writes:
I'm a C programmer, so I'm doing it in a bit of a C like way;
prototype the function, initalize the array using the prototypes, have
the functions defined somewhere else and then let the linker work it
all out for me. I was hoping that python had some sort of lazy
evaluation scheme for this type of behaviour so that you could defer
linkage (or variable evalutation) until runtime, or at least variable
reference (through the use of thunks or some sort). Maybe I was
hoping for too much :)

It's not a problem of "hoping for too much", but a problem of paradigm
shift. You're actually *thinking* in C, and Python is a *completely
different* language. You just can't directly transpose C idioms in
Python - nor could you transpose much Python idioms in C. So you need to
'go down a level' and consider the real problem and how to solve it the
Python way - not how to implement the C-ish solution in Python.

To be honest, I'm trying to do it in a more 'lispish' way (as in emacs
lisp) where the configuration file is written in the implementation
langugage. Just an interesting experiement really to see if it would
work. It's been a year and a half since I really used python last so
I'm just getting back up to speed with the idioms so I expect to make
a few mistakes along the way.

Thanks for the help.

--
burton samograd kruhft .at. gmail
kruhft.blogspot.com www.myspace.com/kruhft metashell.blogspot.com