[Python-3000] basestring removal, __file__ and co_filename
Gregory P. Smith
greg at krypto.org
Thu Oct 11 22:11:49 CEST 2007
On 10/11/07, Guido van Rossum <guido at python.org> wrote:
> On 10/11/07, Christian Heimes <lists at cheimes.de> wrote:
> > Guido van Rossum wrote:
> > > Um, where does the filename object in that expression come from? It
> > > appears to be a PyString object. Who created it? That could should be
> > > changed to create a PyUnicode instead (using the filesystem encoding).
> > Python/compile.c:makecode()
> > filename = PyString_FromString(c->c_filename);
> > Modules/pyexpat.c:getcode()
> > filename = PyString_FromString(__FILE__);
> > Objects/codeobject.c:code_new()
> > PyArg_ParseTuple(args, "iiiiiSO!O!O!SSiS|O!O!:code"
> > As I tried to explain earlier that may be a problem. PyUnicode_Decode()
> > doesn't work so early. The codecs package isn't initialized yet.
> But some codecs are "built-in" and have custom APIs. I wonder if we
> could do something that figures out the default fs encoding, and see
> if it is one of the supported ones, and then uses that; otherwise
> tries UTF-8 with the "replace" error handling option (so it won't fail
> if the data is non-UTF-8).
Thats pretty much what Christian pondered at the start of this thread but
with a defined "failure" mode.
+1 from me, give it a try and see what 3.0a2 testers say. Are there OSes
and filesystems out there that'd store in anything other than one of the
popular codecs (UTF-8, 16, 32, latin1, mbcs)? That seems like a bad idea to
me but obviously I don't run the world.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000