fix debug issue for python3

[dorperetz]

When running python code which uses pyGLFW in debug mode the error attached in the image is shown.

it happens since the code in version_checker_source cant even compile in python3, the keyword raw_input does not exists.

i added code which plants the right keyword according to the python version

[FlorianRhiem]

The NameError shown in the screenshot should be caught by the line just below. By trying first raw_input and then input if an error is raised, the Python 2/3 detection should work well.

it happens since the code in version_checker_source cant even compile in python3, the keyword raw_input does not exists.

I don't understand what you mean by this, as your screenshot shows that it ran without any issues and raised the NameError exception just as expected. Also, raw_input should not be a keyword there, but just a variable name.

[dorperetz]

i'll be more verbose and do my best to explain:

Recreation of issue:

simply debug a python file which only doesimport glfw in pycharm, and have the debug option Attach to subprocess automatically while debugging turned on.

it will output the following error :

 Traceback (most recent call last):
  File "<string>", line 25, in <module>
NameError: name 'raw_input' is not defined 

The minimal code section from glfw which recreates it:

import subprocess
import sys
import textwrap

version_checker_source = '''
    import sys

    try:
        input_func = raw_input
    except NameError:
        input_func = input

'''

args = [sys.executable, '-c', textwrap.dedent(version_checker_source)]
process = subprocess.Popen(args, universal_newlines=True, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
process.communicate('')

run this code section in debug, and you'll get the same error.

Fix and conclusions : you we're right about the fact that it supports both python 2&3, the real issue was that the subprocess was missing stderr. i updated the PR code and tested it.

please let me know if something is unclear

[FlorianRhiem]

I can only reproduce this issue when setting the Pything Exception Breakpoint Activation Policy to "On raise", which would then be perfectly correct behavior. The default "on termination" behavior doesn't cause PyCharm to stop there. Do you perhaps have the Activation Policy set to "On raise"?

I also do not see any relation between the NameError being raised and caught correctly and having a pipe for stderr, in particular because there is nothing being printed to stderr. Could you try to explain why stderr needs to be a pipe if nothing is written to it?

Also, please squash your commits, as the second one includes a full revert of the first one.