homepage

Ah yeah I support this endeavor, I fixed a few instances in rmtree while working on it. It’s just confusing.
JFTR, is there any rationale/reason to do it? Last time I checked it wasn’t deprecated.

I think deprecation makes not big value.
We should continue aliases support and there are no place to raise warning.
What we can do — mention deprecation in the doc.
The reason to get rid of other OSError aliases to make cleaner code (especially considering situations like `except (os.error, IOError):` and use best practices in stdlib.
I think the later is very important because stdlib is first class example of coding style for many users.
After stdlib we can cleanup C code to that unification and use concrete exception classes instead of errno checking (#16705).

> I think deprecation makes not big value.
> We should continue aliases support and there are no place to raise warning.
> What we can do — mention deprecation in the doc.
That’s what I meant. I saw it in shutil code, were confused, looked it up, wondered why it exists. I would like to get rid of it.
Do you have any concrete plans or should I just wade through shutil and make it pretty for 3.4?
> The reason to get rid of other OSError aliases to make cleaner code (especially considering situations like `except (os.error, IOError):` and use best practices in stdlib.
Sure.
> I think the later is very important because stdlib is first class example of coding style for many users.
I hope not. :-/
> After stdlib we can cleanup C code to that unification and use concrete exception classes instead of errno checking (#16705).
Awesome.

New changeset 47f98a550d42 by Andrew Svetlov in branch 'default':
Issue #16706: get rid of os.error
http://hg.python.org/cpython/rev/47f98a550d42 

Fixed. 
About deprecation: I've created #16716 for that.