This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients kristjan.jonsson, loewis
Date 2009-01-16.09:10:39
SpamBayes Score 0.0336579
Marked as misclassified No
Message-id <>
So you are saying that you see no problem with the repr of a fileobject 
being generated in different ways depending on the fileobject being 
unicode or string?
You see no danger of confusion when one is confonted with
<open file 'foo\bar' ...>
<open file u'foo\\bar' ...>
You don't think anyone will be surprised when they try to 
eval 'foo\bar' as they can with u'foo\\bar' and get nonsensical results?

I maintain that this is a bug in python that ought to be fixed and not 
hidden by changing the test suite.  If you are going to rely on using 
the repr of the fileobject to extract the filename, you better be able 
to do that in a consistent manner irrespective of the type of the 
underlying filename.
Date User Action Args
2009-01-16 09:10:43kristjan.jonssonsetrecipients: + kristjan.jonsson, loewis
2009-01-16 09:10:43kristjan.jonssonsetmessageid: <>
2009-01-16 09:10:41kristjan.jonssonlinkissue4927 messages
2009-01-16 09:10:39kristjan.jonssoncreate