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 vstinner
Recipients abarry, eryksun, ezio.melotti, paul.moore, python-dev, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware
Date 2016-01-28.14:51:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1453992702.17.0.965943930593.issue26227@psf.upfronthosting.co.za>
In-reply-to
Content
Steve:
"""
I couldn't remember the names of the alternate functions Windows provides to do the encoding for you, but yes. There are socket APIs there that do encoding and handle memory allocation more safely.

Apart from bugs like this, it's not really urgent and it requires someone motivated to do it. Might be a good project for someone at the PyCon sprints.
"""

Yeah, using the native Windows API is better, it gives access to the full Unicode character set. But it requires to spend time on the C code, and *I* am not interested to work on such project.

If you are motived, please open a new issue for that. If you are not motivated, I'm not sure that it's worth to open a bug report. Using an hostname not encodable to the ANSI code page would probably cause serious issues (not in Python, but in other applications).

When I played with filenames non-encodable to the ANSI code page, I also get errors from multiple applications, whereas Python now uses the native Windows API to access the filesystem. So sometimes Python is better than some other applications, sometimes it's as good :-)
History
Date User Action Args
2016-01-28 14:51:42vstinnersetrecipients: + vstinner, paul.moore, tim.golden, ezio.melotti, python-dev, zach.ware, serhiy.storchaka, eryksun, steve.dower, abarry
2016-01-28 14:51:42vstinnersetmessageid: <1453992702.17.0.965943930593.issue26227@psf.upfronthosting.co.za>
2016-01-28 14:51:42vstinnerlinkissue26227 messages
2016-01-28 14:51:42vstinnercreate