I'm teaching kids to code in Python. Today we had two boys, one with Windows 8, the other one with Windows 10. In both cases Python 3.5 was installed and the automatic path where files are saved was C:\Windows\system32. This wasn't possible, since it cannot be written to. Yet, the boys tried to save files to it. 

In the Windows 8-case the file did not get saved. Yet, IDLE still refered to the file as having an error (it couldn't find the turtle package because the file was called turtle.py - we got that right eventually). Even after reinstalling Python it still refered to the non-existing file and the error in it. 
We changed the path and it solved the problem. Hope this can be fixed.

On my win 10 machine, upgraded from win 7 a week ago, I have C:/programs/Python27, ...34, and ...35.  C:/Windows/system32 contains python27.dll and ...34.dll, but not ...35.dll.  For Idle 2.7 and 3.4, default 'Save As' directory is Python27 and ...34.  (Saving to install directory is not best but works.) For 3.5, it is indeed ...system32.  This is wrong and bad.  The startup directory becomes '.', at the head of sys.path, the module search path.

This is not an IDLE issue.  Start console Python from the icon.
>>> import os; os.getcwd()
'C:\\Programs\\Python34'  # 3.4
'C:\\WINDOWS\\System32'  # 3.5
The following test of Python installed on Windows (preferably before release) would have caught this regression/bug.
  os.getcwd() == os.path.split(sys.executable)[0]

As for IDLE: in IOBinding.py, save_as (l.350) calls asksavefile (l.512).  That calls tkinter.filedialog.SaveAs().show with initialdir = self.defaultfilename("save")[0].  defaultfilename (l.500) defaults to os.getcwd(), which, as above, returns ...system32.

I believe this is an installation bug of not specifying the startup directory for the 3.5 Python and IDLE icons (others should be checked also).

The 3.4 IDLE Icon Properties dialog has 'Target: Python 3.4.3 (64bit)', the latter in grayed-out read-only unselectable text and Start in: C:\Programs\Python34\, the latter rather dangerously pre-selecteed (and hence too easy to inadvertently alter or delete).  

The 3.5 dialog has '''Target: C:\Programs\Python35\pythonw.exe "C:\Programs\Python35\Lib\idlelib\idle.pyw"''', with the target preselected.  This change is useful since users can add IDLE startup arguments at the end, such as '-s' to execute PYTHONSTARTUP.

However, 'Start in:' is blank and for what ever reason, the default is ...system32.  Putting C:\Programs\Python35\ there fixes the problem, and that or something should be there on installation.  When I start IDLE on a command line with "python -m idlelib", the start 'directory' is "Desktop /n Terry", which is an alias for c:\Users\Terry. For most people, that is a better default directory than the install directory.

Larry, Maja is the 2nd or 3rd teacher to report this problem.  See python-list thread "teacher need help!" 
https://mail.python.org/pipermail/python-list/2015-October/698054.html
for one who had problems on 3 of 13 machines and in desperation "formatted the machines, reinstalling everything, including Python."

Maja, the recurring problem may have been due to the bad startup directory being the first directory searched for imports. Or it it may be due to 'C:\Windows\system34\turtle.py' being recorded in <home directory>/.idlerc/recent-files.lst, which is used for File -> Recent Files.  Although IDLE deletes at least some bad entries, the ultimate solution to problems with that file is for a user to edit and delete bad names or delete the file entirely.

> 'Start in:' is blank and for what ever reason, the default is ...system32. 

When the "Start in" field of a .lnk shortcut is blank, the child process inherits the working directory of the parent process (i.e. the process that runs the shortcut), unless the parent passes some other directory to ShellExecute. 

If you copy the shortcut to the desktop, for example, Explorer sets the working directory to the desktop. If it's run from the command prompt, cmd uses its own working directory. When run from the Start menu, the child inherits Explorer's working directory, %SystemRoot%\System32.

The old installer (pre-3.5) sets "Start in" to the installation directory. IMO, a better choice would be "%USERPROFILE%". The Windows shell expands the environment variable to the current user's profile directory when it runs the shortcut. 

I'm not keen on using a profile subdirectory such as "Documents" or "Desktop", since a user can relocate most of the special folders in his or her profile. Unfortunately the "Start in" field won't accept shell: locations such as "shell:Personal" or "shell:Desktop". It would be nice if it did, since those take into account relocated folders.

Thanks for the explanation.  When I did the test with Command Prompt, I happened to be in /Users/Terry, which is where C.P. starts.  %USERPROFILE% is what I was thinking of but could not precisely remember.  It worked when put in that box.

I think adding /Documents would be a mistake because many users (including me) put Python stuff in other subdirectories.

A minor mystery.  Changing Start in: for the Python icon requires admin permission; for the IDLE icon, not.

Unfortunately it looks like MSI won't let you put an environment variable into the shortcut, as it has to resolve it on install (see WkDir at https://msdn.microsoft.com/en-us/library/aa371847(VS.85).aspx)

Trying some other ideas, but it looks like the most robust solution will be for IDLE to change the current directory on startup (maybe via a command line option?), or specify the initial directory in its open/save dialogs.

Otherwise, the best I can realistically promise is to set it to the Python install directory, which is not particularly useful either...

I see the problem: there is only one IDLE icon for all users, so you need the env var to customize for each user, which you cannot use. Staying with the python install directory, as before, should be better.  We never got any complaints about that.  But the new install locations are more problematical.

I have also thought of adding an new startup option, but it should only apply if IDLE is started with the ICON.  When started at the command line, it should start at the current directory of the console, as it does now, so '.' refers to that directory.  Ironically, a current directory of .../system32 would be a good indicator.  I need to see what is in sys.argv after the different start methods.

This issue is currently only for Windows. I don't know what happens on other systems or whether they could stand improvement.

Steve, I think you're right that it's simpler and more reliable to add a command-line option that sets IDLE's working directory to the current user's home directory. 

Terry, the default behavior in Linux, at least in Ubuntu, is to start IDLE with the working directory set to the user's home directory. 

The Linux equivalent of a Windows .lnk shortcut is an XDG .desktop file [1]. A desktop application entry sets the working directory using the "Path" key, such as Path=/absolute/path (or also, and maybe only in Ubuntu Unity, Path=relative/path) in the main "Desktop Entry" or in a "Desktop Action" (i.e. right-click menu action). Environment variables are not supported. 

If "Path" isn't defined, I can only say from experience what Ubuntu's Unity shell does, since the spec doesn't define a default behavior. In this case, the child process inherits Unity's working directory. Since it's a plugin for the Compiz window manager, the child inherits the working directory of Compiz. This is the current user's $HOME directory, which Compiz inherits indirectly from the user-mode init process. I confirmed the behavior by attaching gdb to compiz and executing `call chdir("/home")`, and then continued compiz and opened IDLE to verify that the working directory was inherited as "/home". 

[1]: http://standards.freedesktop.org/desktop-entry-spec/latest

We can add more options to the start menu icon, even something like "--start-in %userprofile%" should work there, as it really is just a blob of text (though I need to test that). Accepting "--start-in ~" and os.path.expanduser() would also be fine, I believe.

New changeset df12c29882b1 by Steve Dower in branch '3.5':
Issue #25450: Updates shortcuts to start Python in installation directory.
https://hg.python.org/cpython/rev/df12c29882b1

I've fixed the shortcuts. Let me know if you add any extra command line options to Idle for setting a more useful start directory and I can add those to the shortcuts as well.

Steve, I am adding you as nosy on #22121, which is now about adding a new startup option.