Please add absolute_import at the beginning of every file

I have an import warning:

```
site-packages/requests/utils.py:17: ImportWarning: Not importing directory '/home/x/platform'
 missing __init__.py

  import platform

```

so my directory: platform hided system module platform.py

This can only be fixed by adding 
`from __future__ import absolute_import` at the first line of utils.py

Also it would be nice to have this for every module.

This should do no harm to python 3.


This is not a totally unreasonable thing to do, though it's totally tragic that we need it: if we didn't support Python 2.6 this wouldn't be a problem. @sigmavirus24?


So I have done this before to debug other problems. The major issue is that it doesn't protect urllib3 so if someone shadows another standard library module locally, they will still have this problem. I'm +0 on the change (and to be clear this is only not an issue on Python 3+) but I don't think it will help people too much who already aren't following best practices for module naming, i.e., not shadowing standard library modules.


I'm working in a company that we have python and c++ code site together,
and the c++ guys definitely don't care or know about standard python
package name.

Shadowing another standard library is another problem.

On Sat, Sep 12, 2015 at 10:07 AM, Ian Cordasco notifications@github.com
wrote:

> So I have done this before to debug other problems. The major issue is
> that it doesn't protect urllib3 so if someone shadows another standard
> library module locally, they will still have this problem. I'm +0 on the
> change (and to be clear this is only not an issue on Python 3+) but I don't
> think it will help people too much who already aren't following best
> practices for module naming, i.e., not shadowing standard library modules.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2771#issuecomment-139774010
> .


> I'm working in a company that we have python and c++ code site together, and the c++ guys definitely don't care or know about standard python package name. 

If the C++ code is used in Python then perhaps your company needs a naming convention such that this doesn't happen. If your C++ developers don't care about not causing problems in the languages they're being consumed from then I'd say find new C++ developers because the ones your company has hired have some serious attitude problems.

> Shadowing another standard library is another problem.

For example, if your company starts shadowing `socket`, `httplib`, `http.client`, `ssl`, `OpenSSL`, `threading`, `collections` or countless others, the protections in requests would only go so far because urllib3 imports those and doesn't also use this. Getting every upstream dependency of yours to use this will likely be more work than just fixing your corporate development process. Also, note that we're not against this change, I'm just being realistic about exactly how helpful it will be for people who carelessly shadow standard library modules.


The C++ developer is our CEO and I like this company.
I agree with you that fixing every upstream dependency would be not
possible, and this seemed to be a python 2 problem that cannot be fixed.

It's still unrealistic to check every standard library modules' name before
make a directory.

Regards.

On Mon, Sep 14, 2015 at 9:40 AM, Ian Cordasco notifications@github.com
wrote:

> I'm working in a company that we have python and c++ code site together,
> and the c++ guys definitely don't care or know about standard python
> package name.
> 
> If the C++ code is used in Python then perhaps your company needs a naming
> convention such that this doesn't happen. If your C++ developers don't care
> about not causing problems in the languages they're being consumed from
> then I'd say find new C++ developers because the ones your company has
> hired have some serious attitude problems.
> 
> Shadowing another standard library is another problem.
> 
> For example, if your company starts shadowing socket, httplib, http.client,
> ssl, OpenSSL, threading, collections or countless others, the protections
> in requests would only go so far because urllib3 imports those and doesn't
> also use this. Getting every upstream dependency of yours to use this will
> likely be more work than just fixing your corporate development process.
> Also, note that we're not against this change, I'm just being realistic
> about exactly how helpful it will be for people who carelessly shadow
> standard library modules.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/kennethreitz/requests/issues/2771#issuecomment-140078395
> .


@shazow If I open a PR that does this for urllib3, would you merge it?


No strong feelings about this, I'd merge it if you think it's a good idea. :)


I think it's probably a good idea. It runs the risk of breaking people who are doing really sketchy crap on Python 2, like attempting to alias stdlib modules by having specially named modules on the import path, but...I feel like that's ok?


Worth a shot, we can always revert once people inevitably complain. :P


@Lukasa it's getting late by you, want me to tackle this tonight?


There's no rush, I'm happy to do it tomorrow, but if you're looking for something to occupy you then feel free to pick it up. =)


I had already done this and stashed it previously, so it was a matter of popping that and committing it. See also: https://github.com/shazow/urllib3/pull/735


This seems like an already solved issue too, so perhaps it's worth closing?