On 09/08/18 05:13, INADA Naoki wrote:
> Please use Python 3.7.
>
> Python 3.7 has several improvements on this area.
Thanks! Darkly remembering something about UTF-8 mode, I suspected it
might...
>
> * When PEP 538 or 540 is used, default error handler for stdio is
> surrogateescape
> * You can
INADA Naoki :
> For Python 3.6, I think best way to allow arbitrary bytes on stdout is
> using `PYTHONIOENCODING=utf-8:surrogateescape` environment variable.
Good info!
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Please use Python 3.7.
Python 3.7 has several improvements on this area.
* When PEP 538 or 540 is used, default error handler for stdio is
surrogateescape
* You can sys.stdout.reconfigure(errors='surrogateescape')
For Python 3.6, I think best way to allow arbitrary bytes on stdout is using
`PYTH
On 09Aug2018 03:14, MRAB wrote:
[...]
Is it true that Unix filenames can contain control characters, e.g. \x07?
Yep. They're just byte strings. You can't have \0 (NUL) because the API uses
NUL terminated strings, and you can't use slash '/' in the filename components
because that is the comp
On 2018-08-09 01:14, Thomas Jollans wrote:
On 09/08/18 01:48, MRAB wrote:
On 2018-08-08 23:16, Thomas Jollans wrote:
On *nix, file names are bytes. In real life, we prefer to think of file
names as strings. How non-ASCII file names are created is determined by
the locale, and on most systems th
On 09/08/18 01:48, MRAB wrote:
> On 2018-08-08 23:16, Thomas Jollans wrote:
>> On *nix, file names are bytes. In real life, we prefer to think of file
>> names as strings. How non-ASCII file names are created is determined by
>> the locale, and on most systems these days, every locale uses UTF-8 an
On 2018-08-08 23:16, Thomas Jollans wrote:
On *nix, file names are bytes. In real life, we prefer to think of file
names as strings. How non-ASCII file names are created is determined by
the locale, and on most systems these days, every locale uses UTF-8 and
everybody's happy. Of course this does
On *nix, file names are bytes. In real life, we prefer to think of file
names as strings. How non-ASCII file names are created is determined by
the locale, and on most systems these days, every locale uses UTF-8 and
everybody's happy. Of course this doesn't mean you'll never run into and
old direct
En Tue, 22 Jun 2010 11:43:34 -0300, escribió:
Python 2.6.5 (Win32): Is there a work around for ftplib's (and
ftputil's) apparent inability to support Unicode file names?
I'm thinking that I might be able to use the encodings.idna as a
work around for this?
According to RFC 2
Python 2.6.5 (Win32): Is there a work around for ftplib's (and
ftputil's) apparent inability to support Unicode file names?
I'm thinking that I might be able to use the encodings.idna as a
work around for this?
In other words, regardless of whether I'm getting or putting a
f
"kai_nerda" wrote in message
news:hp69ri+a...@egroups.com...
Hi,
OS = Windows XP (German language)
Python = 3.1.2
I need to write a directory listing into a XML file.
And after hours of trying and searching i have no clue.
My main problem is that the file and folder names can
have characters
Hi,
OS = Windows XP (German language)
Python = 3.1.2
I need to write a directory listing into a XML file.
And after hours of trying and searching i have no clue.
My main problem is that the file and folder names can
have characters of different languages like
German, Turkish, Russian, maybe else
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Oddly, os.getcwd() and os.getcwdu() both still exist in Python 3.0.
Since the behavior is now identical it seems os.getcwdu() should be
dropped.
It is dropped, and os.getcwdb() has been added.
Must be changed po
> Oddly, os.getcwd() and os.getcwdu() both still exist in Python 3.0.
> Since the behavior is now identical it seems os.getcwdu() should be
> dropped.
It is dropped, and os.getcwdb() has been added.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
"Jordan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
l = os.listdir(unicode(os.getcwd()))
Other options to get the same result:
l = os.listdir(os.getcwdu())
l = os.listdir(u'.')
Oddly, os.getcwd() and os.getcwdu() both still exist in Python 3.0. Since
the behavior is now
On Oct 18, 5:57 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Should the note be removed, or should it say something like "Unicode
> > file names are supported. New in Python 2.6."? Is there anything else
> > that should be mentioned?
>
> Should the note be removed, or should it say something like "Unicode
> file names are supported. New in Python 2.6."? Is there anything else
> that should be mentioned?
The note should be corrected, documenting the behaviour implemented.
> More on cp437: I see where you
d astray by the fact that the 2.6 docs still
contain the note that the OP asked about: "There is no official file
name encoding for ZIP files. If you have unicode file names, you must
convert them to byte strings in your desired encoding before passing
them to write(). WinZip interprets all
> Step 4: Either wait for Python 2.7 or apply the patch to your own copy
> of zipfile ...
Actually, this is released in Python 2.6, see r62724.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
rs in
> position 13-16: character maps to
>
> I'm perfectly willing to let command prompt refuse to print that (it's
> debugging only) if the next issue was resolved >_>:
use print repr(thing) for debugging.
>
> """
> Note: There is no o
g'
u'03-\u3072\u3089\u304c\u306a.jpg'
>>>for thing in l:
...print thing
01-ひらがな.jpg
02-ひらがな.jpg
03-ひらがな.jpg
[/code]
Yay.
Having a file that tries "for thing in l: print thing" fails with:
File "C:\Python25\Lib\encodings\cp437.py", line 12, in encode
On Oct 16, 10:18 pm, John Machin <[EMAIL PROTECTED]> wrote:
> On Oct 17, 12:52 pm, Jordan <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Oct 16, 9:20 pm, John Machin <[EMAIL PROTECTED]> wrote:
>
> > > On Oct 17, 11:43 am, Jordan <[EMAIL PROTECTED]> wrote:
>
> > > > I've got a bunch of files with Japanese
On Oct 17, 12:52 pm, Jordan <[EMAIL PROTECTED]> wrote:
> On Oct 16, 9:20 pm, John Machin <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Oct 17, 11:43 am, Jordan <[EMAIL PROTECTED]> wrote:
>
> > > I've got a bunch of files with Japanese characters in their names and
> > > os.listdir() replaces those charac
2008/10/16 Jordan <[EMAIL PROTECTED]>:
> On Oct 16, 9:20 pm, John Machin <[EMAIL PROTECTED]> wrote:
>> On Oct 17, 11:43 am, Jordan <[EMAIL PROTECTED]> wrote:
>>
>> > I've got a bunch of files with Japanese characters in their names and
>> > os.listdir() replaces those characters with ?'s. I'm tryin
On Oct 16, 9:20 pm, John Machin <[EMAIL PROTECTED]> wrote:
> On Oct 17, 11:43 am, Jordan <[EMAIL PROTECTED]> wrote:
>
> > I've got a bunch of files with Japanese characters in their names and
> > os.listdir() replaces those characters with ?'s. I'm trying to open
> > the files several steps later,
Try Python 3. Python 3 strings are native by default, so the
os.listdir() in Python 3 should support the Japanese characters.
On Oct 17, 1:43 am, Jordan <[EMAIL PROTECTED]> wrote:
> I've got a bunch of files with Japanese characters in their names and
> os.listdir() replaces those characters with
On Oct 17, 11:43 am, Jordan <[EMAIL PROTECTED]> wrote:
> I've got a bunch of files with Japanese characters in their names and
> os.listdir() replaces those characters with ?'s. I'm trying to open
> the files several steps later, and obviously Python isn't going to
> find '01-.jpg' (formally '0
I've got a bunch of files with Japanese characters in their names and
os.listdir() replaces those characters with ?'s. I'm trying to open
the files several steps later, and obviously Python isn't going to
find '01-.jpg' (formally '01-ひらがな.jpg') because it doesn't exist.
I'm not sure where in th
28 matches
Mail list logo
