homepage

$ echo lovely spam > "<string>"
$ python -c 'open("nonexistent","r")'
Traceback (most recent call last):
 File "<string>", line 1, in <module>
 lovely spam
IOError: [Errno 2] No such file or directory: 'nonexistent'
I see this in python 2.7.3 and 3.2.3 from Ubuntu 12.04.

Heh. Nice find. I'm not sure how practical it is to fix, though. We don't have any actual rules about what indicates a 'non-file-stand-in' for the __file__ attribute, just a loose convention that it is an identifier in angle brackets. If we make that a hard rule, though, and someone really has a file named '<string>'.... :)

Well, it should't open "<string>" IMHO.

Does it have to be an identifier in angle brackets? An empty string makes more sense to me.

Ideally there would be an unambiguous way to know if the object came from a file or some other source (say, __file__ is None and another special attribute gives the clue to the actual source), but that's not the way things work now, and for backward compatibility reasons I doubt that we can change it. I'm sure there are programs that depend on at least '<string>', if not some of the other places where a similar thing is done.

Hmm. A backward compatible fix would be to add an attribute that indicates whether or not the __file__ attribute is supposed to be pointing to a real file.

+1
On 16 January 2013 17:43, R. David Murray <report@bugs.python.org> wrote:
>
> R. David Murray added the comment:
>
> Ideally there would be an unambiguous way to know if the object came from
> a file or some other source (say, __file__ is None and another special
> attribute gives the clue to the actual source), but that's not the way
> things work now, and for backward compatibility reasons I doubt that we can
> change it. I'm sure there are programs that depend on at least '<string>',
> if not some of the other places where a similar thing is done.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue16974>
> _______________________________________
>

If we were to add a new attribute to indicate whether a file is real or not, there would need to be a way for users to indicate whether a file is real or not to functions such as `compile()` (there's lots more!) that take a filename. Without enforcing this being set and introducing backward incompatible changes, it would need a default value. To be backwards compatible we could default to True and the existing behaviour persists.
It's also worth mentioning that there's a few places (there might be more!) where Python already assumes that a file in angle brackets is not a real file:
* https://github.com/python/cpython/blob/abd7cd856ba326bd7574135c7d034e98492ab695/Lib/bdb.py#L45
* https://github.com/python/cpython/blob/abd7cd856ba326bd7574135c7d034e98492ab695/Lib/pdb.py#L694
* https://github.com/python/cpython/blob/abd7cd856ba326bd7574135c7d034e98492ab695/Lib/pickle.py#L324
Nothing major though and easily changeable so it's definitely possible but it would be a lot of work to make sure that everything is setting the new attribute properly.
Is there a preference on what the name of this attribute should be? Maybe `__is_real_file__`. It's clear but long.