UnboundLocalError: local variable 'bypass' referenced before assignment

When using requests with GAE dev_appserver sandbox, this variable gets referenced before assignment when making requests to the FB graph API

UnboundLocalError: local variable 'bypass' referenced before assignment
https://github.com/requests/requests/blob/master/requests/utils.py#L680

Uh...this bug appears to be fixed in the current release, if it was present at all. There is no way to that code unless `set_environ` does something absolutely horrifying in GAE, such as swallowing exceptions it hits in` __enter__`.

Using requests==2.17.3, oddly enough this works fine for making requests to numerous other services, only get this error when making requests to https://graph.facebook.com

I have to agree with @Lukasa. `bypass` is defined either in the `try` or `except` block prior to our usage of that. I think we should ping @jonparrott because this doesn't seem like a Requests issue but one can never be certain.

Also, @jonparrott I don't think there's a rush here and I know you spend most of your F/OSS time on Warehouse these days.

I am getting the same error in Python 3.5, Python 3.6 on OS X.
Not getting it on Python 2.7.

I'm doing a post with a URL along the lines of https://apikey:password@hostname/path

An exception is raised in line 2502 of request.py - `hostIP = socket.gethostbyname(hostonly)`

The exception is:
`UnicodeError`,
`encoding with 'idna' codec failed (UnicodeError: label empty or too long)`

I have no proxies set up.


@jbasko Wait, what? Can you print all your traceback output please?

So it *looks like* `set_environ` may be swallowing all exceptions in this [try/finally block](https://github.com/requests/requests/blob/500fe3ee0373c5c0b0e6d80c0fd57142771f89cb/requests/utils.py#L618-L626). If something is raised outside of the two exceptions we're catching, it doesn't surface outside of the context manager and `bypass` isn't set.

```python
from requests.utils import set_environ

with set_environ('no_proxy', None):
    raise AssertionError
```

Yeah, that code seems weird. What's with the `return` statement inside the `finally` block? What, exactly, were we thinking when we merged that?

Apologies, I didn't realise that was urllib request.py, not requests code.

Yes, as @nateprewitt says.

The actual traceback I get is useless as it is just about that bypass being referenced before assignment.

I got the underlying exception by adding another except clause in the code mentioned and then inspecting exception with a debugger.

Ok cool so the actual bug is as @nateprewitt identified. Want to lead getting this fixed Nate?

@Lukasa, sure thing. I'll throw something together later today unless someone else would like to pick this up. It looks like it should be a quick fix.

Is this one also not my fault? You guys can feel free to keep pinging me on bugs that end up not being my fault. :)

(In all seriousness let me know if there's anything I can do to help here)

@jonparrott I think you're in the clear here, this is just bad exception handling on our part 😅.

This change seems to get me past the variable assignment issue(and except the actual error), let me know if you want this in a PR

```
@contextlib.contextmanager
def set_environ(env_name, value):
    """Set the environment variable 'env_name' to 'value'

    Save previous value, yield, and then restore the previous value stored in
    the environment variable 'env_name'.

    If 'value' is None, do nothing"""
    if value is None:
        yield
    else:
        old_value = os.environ.get(env_name)
        os.environ[env_name] = value
        try:
            yield
        finally:
            if old_value is None:
                del os.environ[env_name]
            else:
                os.environ[env_name] = old_value
```

@mlcrazy, this is definitely a workable approach. My initial pass was the inverse of this, so we yield in the else and match the docstring. I'm not terribly excited about the additional level of nesting, but I'm not sure it's avoidable here.

Feel free to open the PR and we'll see if any of the other maintainers have thoughts.