expunge PYTHONDONTWRITEBYTECODE

See #889 for motivation.

My understanding is that this was added in order to fix tests, which were trying to POST `__file__` and failing on the second run, once `__file__` began to refer to a .pyc instead of a .py?

It looks like postbin/httpbin no longer choke on .pyc files, so we should be able to omit this.

cc @sigmavirus24


Ah, bad time, the `develop` build is red. Although, I do have a unique error message for this pull request:

```
Executing your 3 (export TRAVIS_PYTHON_VERSION=2.6) took longer than 0 minutes and was terminated.
```


`longer than 0 minutes` sounds almost like eternity...


This wasn't exactly my decision/idea but yeah, I don't think the problem was solely with HTTPbin. I don't remember exactly since it was happening in July/early August, but I was seeing it with Amazon S3 if I remember correctly (I was using it via the GitHub Downloads API). But my memory is too hazy to be 100% certain. _shrug_ It's @kennethreitz's call anyway. I'm swamped with other stuff at the moment (I'm not even working on my own projects).


That has nothing to do with it — this prevents syntax errors upon installation for python 2.


Sorry, could you clarify? Using the branch from this pull request, I can successfully build and install on my 2.7 and 3.2 systems.


bytecode compilation causes warnings at install time.


But `PYTHONDONTWRITEBYTECODE` is about writing already compiled bytecode to disk not about switching compilation on or off, isn't it?


At install time, setuptools goes out of its way to byte-compile code unnecessarily. It skips this if that env var is set.

Ugly, I know. but currently necessary.


The line your have to use to adhere to the Arch Linux [Python Package Guidelines](https://wiki.archlinux.org/index.php/Python_Package_Guidelines):

``` bash
python2 setup.py install --root="$pkgdir" --optimize=1
```

The output from this line in the build script:

``` bash
byte-compiling /home/etherealite/projects/requests.1.14.2/pkg/usr/lib/python2.7/site-packages/requests/safe_mode.py to safe_mode.pyc
writing byte-compilation script '/tmp/tmpfrjizz.py'
/usr/bin/python2 -O /tmp/tmpfrjizz.py
Traceback (most recent call last):
  File "/tmp/tmpfrjizz.py", line 122, in <module>
    direct=1)
  File "/usr/lib/python2.7/distutils/util.py", line 458, in byte_compile
    raise DistutilsByteCompileError('byte-compiling is disabled.')
distutils.errors.DistutilsByteCompileError: byte-compiling is disabled.
error: command '/usr/bin/python2' failed with exit status 1
```

I would rather my package manager is able be able to clean up the byte code generated by the library,  rather than to have have setup.py run a few seconds faster.


that is not why this was added.


It's not about running faster if I remember correctly


I"m assuming this is the reason:

> bytecode compilation causes warnings at install time.

If that's the case, cant you put in some checks so that it only gets invoked where in the environments where it causes problems. I don't get any warnings when installing it without `PYTHONDONTWRITEBYTECODE` flag.


@etherealite do you realize how many different kinds of environments exist right? Do you realize the amount of work:;

A) to find all of them
B) to support all of them
C) to track all of them

On top of that, why are you bothering with Arch's package repository and not using pip? In fact, why does anyone bother with that?


Both the `README` and the docs are very clear on this front: Requests expects to be installed with `pip` and `easy_install`. I strongly, strongly, _strongly_ encourage you not to use or create a Pacman package of Requests. Such a package would not be being maintained by the project and so would at best be out of sync with Requests, and at worst be totally out of date.


@Lukasa ironic you say that given how many people's Arch installs get fubarred because of the rolling release model that has notoriously had all sorts of problems.


I wouldn't advise anyone not to build native system package out of Python package if he wants to do that. If there's problem doing that it means something is wrong with the Python package (assuming other packages don't have the same problems which points to problem with Python package format or similar issues).


@piotr-dobrogost in this case there seems to be one HUGE issue with Arch's python package requirement: **they only support python3** Look at the command they **require** you to use for an Arch package, it explicitly requires python2. What if you want to install under python3? Also, when would a system package every be preferable to using pip, especially across multiple versions?
- System packages cannot be used under virtualenvs so they're useless there.
- Arch seems to only support python 2, so much for all the work that goes into compatibility towards python 3
- Package maintainers occasionally make their own changes without reporting them upstream
  - this begs the question, why should we support a decision we didn't make?
- Package maintainers are occasionally required to use options, e.g., `--optimize=1`, that put the pressure on us to revert explicit design decisions
  - Following arbitrary guidelines will only lead to insanity, tracking them to further insanity.
  - Why follow arbitrarily decided guidelines when we have a package manager that works perfectly for us?


Let's put this another way.

If you want to package Requests for anything other than `pip` or `easy_install`, you're essentially forking it. Great, that's brilliant, best of luck to you! However, that means that anything we do here that breaks your fork is totally your problem, not ours.

In this case, the fix is quite literally one line in the downstream version. You won't even have merge conflicts when you pull in new changes. =D


@Lukasa that's a much better explanation than I wrote. +1 good sir


Personally I am sympathetic towards the creation of "native" packages for Requests. On my own machines, I use the Fedora distribution's RPMs of Requests (courtesy of @sagarun), not pip or easy_install.

However:
1. An unavoidable aspect of packaging is maintaining a (hopefully small) set of downstream patches
2. Requests does not have an obligation to interoperate perfectly with every packaging system; if Requests has become _unusually_ difficult to package (and the issue here doesn't seem to qualify), then we can work with the packagers to improve it


I agree with @slingamn and have a feeling the whole discussion here went in the wrong direction. It's not task of any Python library to set variables such as `PYTHONDONTWRITEBYTECODE` similar to how it's not its task to configure logging. Both are tasks of users of the library. Conclusion, `PYTHONDONTWRITEBYTECODE` should have never been manipulated by Requests. This pull removes manipulation so it fixes the problem. We should merge this and close this issue as fixed.


It was added for a reason. As soon as we get a valid version of chardet that works on both versions of python, this problem will go away. 

Stop talking about it.


And guess who's working on that over at sigmavirus24/charade :P


@sigmavirus24: I :heart: you


Oh we're vendorizing this, right? I need to change a few things with the imports.


That's the plan. Easy to workaround though.


It isn't a lot of work to change, I just forgot that it would be vendorized.


@sigmavirus24 how close is it to being in a usable state?


Hopefully ~1 week. I haven't changed anything that would change the code, I'm 
just doing the 2to3 work and making it so that flake8 won't kill vim whenever 
I open a file (when possible). Also there's not a single test for this, so 
having an easy guide as to it working in python3 won't help.

I'm going to reference that guide from Dive into Python3 though to make sure I 
haven't missed anything. And be sure, the latter part (pep8-ifying the files) 
is the time consuming part.
On Thu, Nov 29, 2012 at 05:55:21AM -0800, Kenneth Reitz wrote:

> @sigmavirus24 how close is it to being in a usable state?
> 
> ---
> 
> Reply to this email directly or view it on GitHub:
> https://github.com/kennethreitz/requests/pull/907#issuecomment-10847816


It may be easier to start with chardet2 and work backwards