471,350 Members | 1,723 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,350 software developers and data experts.

about functions question

I try it:

def b():
...
a()
...

def a():
...
b()
...

b()
it's not work.

Is it possible pre-define function like in c++ or place functions code
after main block?

int a();
int b();

int main ()
{
....
a();
....
}

int a()
{
....
b();
....
}

int b()
{
....
a();
....
}

=) sorry for my eng;)

Oct 25 '07 #1
12 1118
NoName schrieb:
I try it:

def b():
...
a()
...

def a():
...
b()
...

b()
it's not work.
It works.
def a():
print "a"
b()
def b():
print "b"
print a # not calling!
b()

But if you really call a in b, you create an endless loop. In all
programming languages, btw.

Is it possible pre-define function like in c++
No.
or place functions code
after main block?
Yes.
Oct 25 '07 #2
On Oct 25, 2:28 am, NoName <zaz...@gmail.comwrote:
I try it:

def b():
...
a()
...

def a():
...
b()
...

b()
it's not work.
It sure does. Please post full code and error message, something else
is wrong, not the cyclic reference.

George

Oct 25 '07 #3
On Thu, 25 Oct 2007 06:28:16 +0000, NoName wrote:
I try it:

def b():
...
a()
...

def a():
...
b()
...

b()
it's not work.
What do you mean by not working? At the time `b()` is called, both
functions are defined so it should working. Or at least it's not the
problem you think it is. The code above, the dots replaced with nothing,
will of course run "forever" until the stack limit is reached.

Ciao,
Marc 'BlackJack' Rintsch
Oct 25 '07 #4
On Oct 25, 7:28 am, NoName <zaz...@gmail.comwrote:
I try it:

def b():
...
a()
...

def a():
...
b()
...

b()
it's not work.
Probably all those dots!
Is it possible pre-define function like in c++ or place functions code
after main block?
Python binds names to objects dynamically: this means that when a() is
compiled, the "b()" line in its definition is compiled to something
that says "look for the object currently bound to the name 'b' in the
global dictionary, and execute the __call__ method of that object with
no arguments". It doesn't make any difference what object 'b' is
bound to at this time.

HTH

--
Arnaud
Oct 25 '07 #5
On Oct 25, 10:30 am, Arnaud Delobelle <arno...@googlemail.comwrote:
[...]
"look for the object currently bound to the name 'b' in the
global dictionary, and execute the __call__ method of that object with
no arguments"
This is what happens at runtime. Rereading, I thought I hadn't made
it clear.

--
Arnaud
Oct 25 '07 #6
sorry! Yes it's work.
What about 2 question?
Can i put function after main block?

print qq()

def qq():
return 'hello'

Traceback (most recent call last):
File "C:\Python25\projects\indexer\test.py", line 1, in <module>
print qq()
NameError: name 'qq' is not defined
Or onli possible:

def main():
print qq()

def qq():
return 'hello'

main()

Oct 25 '07 #7
NoName wrote:
sorry! Yes it's work.
What about 2 question?
Can i put function after main block?
print qq()

def qq():
return 'hello'
You can't call a thing before it is defined.
Traceback (most recent call last):
File "C:\Python25\projects\indexer\test.py", line 1, in <module>
print qq()
NameError: name 'qq' is not defined
Or onli possible:

def main():
print qq()

def qq():
return 'hello'

main()
Yes. That's the way to go.

Diez
Oct 25 '07 #8
NoName a écrit :
sorry! Yes it's work.
What about 2 question?
Can i put function after main block?

print qq()

def qq():
return 'hello'
Where's your "main block" here ?
Traceback (most recent call last):
File "C:\Python25\projects\indexer\test.py", line 1, in <module>
print qq()
NameError: name 'qq' is not defined
Indeed. When the code is loaded in the interpreter (that is, when passed
as a script or when imported as a module), all top-level statements are
executed sequentially. This creates all the function and class objects
and populate the module's namespace accordingly.
>
Or onli possible:

def main():
print qq()

def qq():
return 'hello'

main()
The canonical case for small scripts is to have first all functions and
globals defined, then the main code protected by a guard, ie:

import something

SOME_CONST = 42

def do_something():
pass

def try_something_else():
pass

if __name__ == '__main__':
print SOME_CONST
if not do_something():
try_somethin_else()
For bigger apps, you usually define all functions and classes in
modules, so the 'main' script doesn't define much - just do the needed
imports, and call the appropriate function or class.
Oct 25 '07 #9
On 2007-10-25, Bruno Desthuilliers
<br********************@wtf.websiteburo.oops.comwr ote:
The canonical case for small scripts is to have first all
functions and globals defined, then the main code protected by
a guard, ie:
There's no reason to "protect" your main code in a small script.
if __name__ == '__main__':
print SOME_CONST
if not do_something():
try_somethin_else()
That idiom is useful in modules for launching tests or examples
that should not be run when the module is imported.

--
Neil Cerutti
Oct 25 '07 #10
On 10/25/07, Neil Cerutti <ho*****@yahoo.comwrote:
On 2007-10-25, Bruno Desthuilliers
<br********************@wtf.websiteburo.oops.comwr ote:
The canonical case for small scripts is to have first all
functions and globals defined, then the main code protected by
a guard, ie:

There's no reason to "protect" your main code in a small script.
There's also not much reason not to, and it prevents disaster or at
least unwanted side effects when you accidentally run pychecker or
pydoc over it.

Also, debugging scripts is a lot easier when you can import them into a shell.
if __name__ == '__main__':
print SOME_CONST
if not do_something():
try_somethin_else()

That idiom is useful in modules for launching tests or examples
that should not be run when the module is imported.
I use it whenever there's any code I don't want run unless I'm
explicitly trying to do so.
Oct 25 '07 #11
Neil Cerutti a écrit :
On 2007-10-25, Bruno Desthuilliers
<br********************@wtf.websiteburo.oops.comwr ote:
>The canonical case for small scripts is to have first all
functions and globals defined, then the main code protected by
a guard, ie:

There's no reason to "protect" your main code in a small script.
I actually have at least one: it allow me to execute all the top-level
definitions in Emacs' Python sub-interpreter buffer for testing, without
actually executing the 'main' code.
>if __name__ == '__main__':
print SOME_CONST
if not do_something():
try_somethin_else()

That idiom is
<insert>also</insert>
useful in modules for launching tests or examples
that should not be run when the module is imported.
Indeed.
Oct 26 '07 #12
On 2007-10-26, Bruno Desthuilliers <br********************@wtf.websiteburo.oops.comwr ote:
Neil Cerutti a écrit :
>On 2007-10-25, Bruno Desthuilliers
<br********************@wtf.websiteburo.oops.comw rote:
>>The canonical case for small scripts is to have first all
functions and globals defined, then the main code protected by
a guard, ie:

There's no reason to "protect" your main code in a small
script.

I actually have at least one: it allow me to execute all the
top-level definitions in Emacs' Python sub-interpreter buffer
for testing, without actually executing the 'main' code.
>>if __name__ == '__main__':
print SOME_CONST
if not do_something():
try_somethin_else()

That idiom is

<insert>also</insert>
>useful in modules for launching tests or examples
that should not be run when the module is imported.
Indeed.
Thanks to you and Chris for giving me the tool-related
applications of that idiom. I haven't used the associated tools.

--
Neil Cerutti
Ushers will eat latecomers. --Church Bulletin Blooper
Oct 26 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

220 posts views Thread by Brandon J. Van Every | last post: by
54 posts views Thread by Brandon J. Van Every | last post: by
28 posts views Thread by David MacQuigg | last post: by
51 posts views Thread by Casper Bang | last post: by
4 posts views Thread by Tony Johansson | last post: by
14 posts views Thread by Alan Silver | last post: by
4 posts views Thread by cwc5w | last post: by
2 posts views Thread by developer.new | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.