homepage

https://stackoverflow.com/questions/26977236/how-can-i-use-future-division-in-the-idle-startup-file report what seems like possibly fixable perhaps buggy behavior with respect to __future__ imports. More investigation is needed.
Any change here might interact with #5233 IDLE: exec IDLESTARTUP/PYTHONSTARTUP on restart

Easy test case using -c:
\python_d.exe -m idlelib.idle -c "from __future__ import division; print(1/2)"
>>> 
0.5
>>> 1/2
0
>>> division
_Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192)
Replace "-m idlelib.idle" with "-i" to get interactive interpreter and >>> 1/2 is .5 instead of 0.
---
Implementation of -s in PyShell.py
if o == '-s': startup = True # line 1504
if startup: # line 1586
 filename = ...
 if filename ...
 ... execfile(filename)
execfile (line 650) is the same method used to run -c and -r code. After compiling code, it calls runcode (779). That normally sends the code to the user process, but may run code in the debugger or in the idle process. When the future import is run, it is just an import and not also a 'from __future__' statement.
Editor files are compiled in ScriptBinding.ScriptBinding.checksyntax. This is why not affected by __future__ import in PyShell (#24222). Run_module_event calls (interp.)runcode, as above.
I believe Shell input is run by .runsource, which is called by .runit, which is called when appropriate by the <enter> callback.
.runsource in turn calls the base class method code.InteractiveInterpreter.runsource, which uses 'self.compile', which is an instance of codeop.CommandCompiler. codeop.CommandCompiler indirectly uses 'self.compiler', which is an instance of codeop.Compiler. The latter is what actually calls the builtin function compile, with self.flags (futures imported), it updates self.flags from the flags in the code returned by compile.
So I believe the solution is for the ExtendedInterpreter instance to get a reference to the Compiler instance, after InteractiveInterpreter is initialized, and call that, with symbol='exec' instead of 'single', instead of calling compile directly.
A reason not to use the same pipeline as for statements enter interactively is that there is extra code to account for the possibility of compiling correct partial statements. "while True:\n" is not an error at a prompt, since more may follow, but is as a complete code string.