why process doesn't join and doesn't run?

Question

i have a simple problem to solve(more or less)
if i watch python multiprocessing tutorials i see that a process should be started more or less like this:

from multiprocessing import *

def u(m):
    print(m)
    return

A=Process(target=u,args=(0,))
A.start()
A.join()

It should print a 0 but nothing gets printed. Instead it hangs forever at the A.join().

if i manually start the function u doing this

A.run()

it actually prints 0 on the shell but it doesn't work simultaneously
for example the output of following code:

from multiprocessing import *
from time import sleep

def u(m):
    sleep(1)
    print(m)
    return

A=Process(target=u,args=(1,))
A.start()
print(0)

should be
0
1

but actually is
0

and if i add before the last line

A.run()

then the output becomes
1
0

this seems confusing to me...

and if i try to join the process it waits forever.

however,if it can help giving me an answer
my OS is Mac os x 10.6.8
python versions used are 3.1 and 3.3
my computer has 1 intel core i3 processor

--Update--
I have noticed that this strange behaviour is present only when launching the program from IDLE ,if i run the program from the terminal everything works as it is supposed to,so this problem must be connected to some IDLE bug.
But runnung programs from terminal is even weirder: using something like range(100000000) activates all my computer's ram until the end of the program; if i remember well this shouldn't happen in python 3,only in older python versions. I hope these new informations will help you giving an answer

--Update 2--
the bug occurs even if i don't perform output from my process,because setting this:

def u():
    return

as the target of the process and then starting it , if i try to join the process,idle waits forever

Answer 1

As suggested here and here, the problem is that IDLE overrides sys.stdin and sys.stdout in some weird ways, which do not propagate cleanly to processes you spawn from it (they are not real filehandles).

The first link also indicates it's unlikely to be fixed any time soon ("may be a 'cannot fix' issue", they say).

So unfortunately the only solution I can suggest is not to use IDLE for this script...