Likely has the same issue on any platform which uses the same functionality (lpr filename to print).

I can confirm this bug for POSIX platforms. Changing the lpr command in config-main.def to quote the filename seems to fix the problem. 

   print-command-posix=lpr "%%s"


It might also be a problem on Windows, but I haven't tried it.

But then will be problems with filenames containing ".

I think if IDLE directly starts lpr directly (subprocess) rather than using a shell to run it, then this problem won't happen.

Since there is no 'print filename' command on the menu, I am guessing that this is about 'File/Print Window' where the window is an edit window for a file with spaces in the name. In any case, on Win7 3.3 this worked fine for 'tem with space.py' except that .py is left off. However, the latter has nothing to do with spaces as 'tem.py' also appears as just 'tem' (centered at top of page). Is stripping the extension intended and done by idle or something Windows does?

The attached patch changes %%s to %%r. This should handle file names containing quotes automatically.

Ramchandra's point of using a subprocess instead would fix the issue as well. That would require changing "print_window" in Lib/idlelib/IOBinding.py 

Terry's observation about Windows' Notepad omitting the file extension is just a behavior of Notepad.

See also issue12274.

Going to attach a patch using subprocess in a few minutes...

It is not so easy. The problem is that we have to determine the print command by configuration line. A user may wish to change these settings, and some users already changed them. The patch should not break them. For backward compatibility we also have to run a command with a shell, not directly. A method of quoting of command arguments varies in the different systems and it differs from Python's repr. The new code should work in case if the user has not changed the default settings, and in case he changed them (for example when he replaced %%s to "%%s"). Definitely, this is not an easy issue.

@Serhiy Storchaka
I don't think anybody edits that line anyway.
IMHO, a warning about this change should be enough.

At least one who want print filenames on non-default printer must edit that line. In any case we can't break this in a bugfix release.

@Serhiy

IDLE places its default configuration files within the standard library. Any upgrade of Python can modify the contents of the standard library. Even if we do *nothing* to change Lib/idlelib/config-main.def, the next upgrade would overwrite an end users custom print command anyway.

Now, if the end-user changed ~/.idlerc/config-main.cfg instead to include the new "print-command-posix" entry then this patch will not change their custom setting.

Attached is a patch which uses subprocess. Haven't tested it much.

No surrounding %%s with quotes, nor changing to %%r doesn't work in all cases, because Python and shell use different quoting schemas. The only solution is using shlex.quote (which available only since 3.3). But even in this case we should be careful, this can break user code if user has "fixed" the issue by surrounding %%s with quotes (singular or double) or changing to %%r. Perhaps we should substitute not only bare %%s, but also "%%s", '%%s' and %%r.

Ramchandra's patch doesn't help. First, shlex.split will fail in the same way as a shell. Second, we must run the command via shell, because user can use pipe or redirection.

New changeset e651d96e6b07 by Serhiy Storchaka in branch '2.7':
Issue #16829: IDLE printing no longer fails if there are spaces or other
http://hg.python.org/cpython/rev/e651d96e6b07

New changeset 20065626c0b5 by Serhiy Storchaka in branch '3.2':
Issue #16829: IDLE printing no longer fails if there are spaces or other
http://hg.python.org/cpython/rev/20065626c0b5

New changeset 778bead39825 by Serhiy Storchaka in branch '3.3':
Issue #16829: IDLE printing no longer fails if there are spaces or other
http://hg.python.org/cpython/rev/778bead39825

New changeset 529b5ced59e0 by Serhiy Storchaka in branch 'default':
Issue #16829: IDLE printing no longer fails if there are spaces or other
http://hg.python.org/cpython/rev/529b5ced59e0

I have committed a very simple fix with shlex.quote (pipes.quote before 3.3). This is not fully backward compatible, it can break user configuration if the user had "fixed" this issue himself (and this "fix" is not perfect). But I think it's quite unlikely. Otherwise, we would get a bug report much earlier. An attempt to consider such hypothetical situation requires tedious code.

Thank you for report, Rod.

Given the system-dependent nature of the problem, starting with the simplest thing that really ought to work seems reasonable to me. I verified that the 3.3 patch has no effect on Windows. IE, files with and without spaces printed without .py in the printed title.