Text of the answer:

does sys.getdefaultencoding() returning the 'right' value ?

then you can try this

reader = codecs.getreader(sys.getdefaultencoding()) 
sys.stdin = reader(sys.stdin)

but ...

maybe it is not a good idea

Text of the comments:

Sounds like a dirty hack ;-) ...I tried it and interestingly, sys.getdefaultencoding() does return the "right" value in PyDev/Jython. Unfortunately, this didn't have any influence on the value of sys.stdin.encoding. I am suspecting the python-gnupg code to use that to communicate with the binary... anyway, doesn't your hack also means that the encoding is not stored with the stream/reader objects??? – Christian Gelinek Mar 13 at 11:27

I meant to say: Since changing the sys.stdin reference to a manually created reader object with its encoding configured doesn't change the sys.stdin's encoding (which I assume to be the reader object's), then the encoding doesn't seem to be "remembered" by your reader. Or did I miss something? – Christian Gelinek Mar 13 at 11:38

PyDev creates special sys.stdin and sys.stdout objects for Eclipse console window? – Mikko Ohtamaa Mar 14 at 4:58

I guess so, how otherwise would it get the output into it's Console window and let the user type into that window for input purposes? I'm not sure though if the problem is indeed related to those objects, because I think python-gnupg tries to find out about the encoding for communicating with the gpg executable. – Christian Gelinek Mar 14 at 7:04

ok, ok this wasn't helpfull, .. but deleting it will kill the comments ? / starting a bounty – Blauohr Mar 14 at 8:23

Full Text of the answer:

does sys.getdefaultencoding() returning the 'right' value ?

then you can try this

reader = codecs.getreader(sys.getdefaultencoding()) 

sys.stdin = reader(sys.stdin)

but ...

maybe it is not a good idea

Text of the comments:

Sounds like a dirty hack ;-) ...I tried it and interestingly, sys.getdefaultencoding() does return the "right" value in PyDev/Jython. Unfortunately, this didn't have any influence on the value of sys.stdin.encoding. I am suspecting the python-gnupg code to use that to communicate with the binary... anyway, doesn't your hack also means that the encoding is not stored with the stream/reader objects???
– Christian Gelinek Mar 13 at 11:27

I meant to say: Since changing the sys.stdin reference to a manually created reader object with its encoding configured doesn't change the sys.stdin's encoding (which I assume to be the reader object's), then the encoding doesn't seem to be "remembered" by your reader. Or did I miss something?
– Christian Gelinek Mar 13 at 11:38

PyDev creates special sys.stdin and sys.stdout objects for Eclipse console window?
– Mikko Ohtamaa Mar 14 at 4:58

I guess so, how otherwise would it get the output into it's Console window and let the user type into that window for input purposes? I'm not sure though if the problem is indeed related to those objects, because I think python-gnupg tries to find out about the encoding for communicating with the gpg executable.
– Christian Gelinek Mar 14 at 7:04

ok, ok this wasn't helpfull, .. but deleting it will kill the comments ? / starting a bounty
– Blauohr Mar 14 at 8:23