Martin v. Löwis:
This appears to be based on the usedDefault return value of
WideCharToMultiByte. I believe this is insufficient:
WideCharToMultiByte might convert Unicode characters to
codepage characters in a lossy way, without using the default
character. For example, it converts U+0308
Neil Hodgson wrote:
There is WC_NO_BEST_FIT_CHARS to defeat that. It says that it will
use the default character if the translation can't be round-tripped.
Available on WIndows 2000 and XP but not NT4.
Ah, ok, that's a useful feature. Of course, limited availability of the
feature means
Martin v. Löwis wrote:
Guido van Rossum wrote:
Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(.) really behave differently
than os.listdir(u.)? Bah! I don't think that's a very good design
(although I see where it comes from).
Hi Neil,
With the proposed modification, sys.argv[1] u'\u20ac.txt' is
converted through cp1251
Actually, it is not: if you pass in a Unicode argument to
one of the file I/O functions and the OS supports Unicode
directly or at least provides the notion of a file system
encoding, then the file
M.-A. Lemburg:
2) Return unicode when the text can not be represented in ASCII. This
will cause a change of behaviour for existing code which deals with
non-ASCII data.
+1 on this one (s/ASCII/Python's default encoding).
I assume you mean the result of sys.getdefaultencoding() here.
Hi Neil,
2) Return unicode when the text can not be represented in ASCII. This
will cause a change of behaviour for existing code which deals with
non-ASCII data.
+1 on this one (s/ASCII/Python's default encoding).
I assume you mean the result of sys.getdefaultencoding() here.
Yes.
The
Hi Marc-Andre,
With the proposed modification, sys.argv[1] u'\u20ac.txt' is
converted through cp1251
Actually, it is not: if you pass in a Unicode argument to
one of the file I/O functions and the OS supports Unicode
directly or at least provides the notion of a file system
Guido van Rossum:
In some sense the safest approach from this POV would be to return
Unicode as soon as it can't be encoded using the global default
encoding. IOW normally this would return Unicode for all names
containing non-ASCII characters.
On unicode versions of Windows, for
Neil Hodgson wrote:
On unicode versions of Windows, for attributes like os.listdir,
os.getcwd, sys.argv, and os.environ, which can usefully return unicode
strings, there are 4 options I see:
1) Always return unicode. This is the option I'd be happiest to use,
myself, but expect this
I'm in full agreement with Marc-Andre below, except I don't like (1)
at all -- having used other APIs that always return Unicode (like the
Python XML parsers) it bothers me to get Unicode for no reason at all.
OTOH I think Python 3.0 should be using a Unicode model closer to
Java's.
On 7/11/05,
Neil Hodgson wrote:
Thomas Heller:
But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
this file as module. Internally Python\import.c converts everything to
strings. I started to refactor import.c to work with PyStringObjects
instead of char buffers as a first step -
M.-A. Lemburg:
I don't really buy this trick: what if you happen to have
a home directory with Unicode characters in it ?
Most people choose account names and thus home directory names that
are compatible with their preferred locale settings: German users are
unlikely to choose an account
Neil Hodgson wrote:
M.-A. Lemburg:
I don't really buy this trick: what if you happen to have
a home directory with Unicode characters in it ?
Most people choose account names and thus home directory names that
are compatible with their preferred locale settings: German users are
On 7/9/05, Neil Hodgson [EMAIL PROTECTED] wrote:
M.-A. Lemburg:
I don't really buy this trick: what if you happen to have
a home directory with Unicode characters in it ?
Most people choose account names and thus home directory names that
are compatible with their preferred locale
Thomas Heller:
OTOH, I once had a bug report from a py2exe user who complained that the
program didn't start when installed in a path with japanese characters
on it. I tried this out, the bug existed (and still exists), but I was
astonished how many programs behaved the same: On a PC with
Neil Hodgson [EMAIL PROTECTED] writes:
Guido van Rossum:
Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(.) really behave differently
than os.listdir(u.)?
Yes:
os.listdir(.)
['abc', '']
os.listdir(u.)
[u'abc',
Guido van Rossum:
Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(.) really behave differently
than os.listdir(u.)?
Yes:
os.listdir(.)
['abc', '']
os.listdir(u.)
[u'abc',
Guido van Rossum:
Then maybe the code that handles Unicode paths in arguments should be
fixed rather than adding a module that encapsulates a work-around...
On 7/3/05, Neil Hodgson [EMAIL PROTECTED] wrote:
It isn't clear whether you are saying this should be fixed by the
user or in the
Neil Hodgson [EMAIL PROTECTED] writes:
Thomas Heller:
OTOH, Python is lacking a lot when you have to handle unicode strings on
sys.path, in command line arguments, environment variables and maybe
other places.
A new patch #1231336 Add unicode for sys.argv, os.environ,
os.system is
Thomas Heller:
Not only that, all the other flags like -O and -E are also in sys.argvu
but not in sys.argv.
OK, new patch fixes these and the -c issue.
Those are nearly obsoleted by the subprocess module (although I do not
know how that handles unicode.
It breaks. The argspec is
On 6/30/05, Neil Hodgson [EMAIL PROTECTED] wrote:
One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on Windows.
Currently, to implement code that may see unicode paths, you must
first understand that unicode paths may be
Guido van Rossum:
Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do?
Neil Hodgson [EMAIL PROTECTED] writes:
One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on
Guido van Rossum:
Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do?
One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on Windows.
Currently, to implement code that may
On 6/27/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
I think the only questions remaining open are where to put it and what to
call the class.
Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do? The path module seems mostly useful for
folks
Phillip J. Eby wrote:
At 03:45 PM 6/27/2005 -0500, Skip Montanaro wrote:
We're getting enough discussion about various aspects of Jason's
path module that perhaps a PEP is warranted. All this discussion on
python-dev is just going to get lost.
AFAICT, the only unresolved issue outstanding
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes as much sense as
Michael Hoffman wrote:
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
constructor classmethod by analogy with 'dict.fromkeys()' or
'datetime.now()'. 'getcwd()'
Phillip J. Eby wrote:
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
constructor classmethod by analogy with 'dict.fromkeys()' or
At 05:10 PM 6/27/2005 +0200, Reinhold Birkenfeld wrote:
Phillip J. Eby wrote:
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or 'path.cwd()'; i.e. a
constructor classmethod by analogy with 'dict.fromkeys()' or
'datetime.now()'. 'getcwd()' looks like it's getting a property of a path
Phillip J. Eby wrote:
At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote:
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
I'm also not keen on the fact that it makes certain things
properties whose value can change
At 08:24 PM 6/27/2005 +0100, Michael Hoffman wrote:
On Mon, 27 Jun 2005, Phillip J. Eby wrote:
At 08:20 AM 6/27/2005 +0100, Michael Hoffman wrote:
os.getcwd() returns a string, but path.getcwd() returns a new path
object.
In that case, I'd expect it to be 'path.fromcwd()' or
We're getting enough discussion about various aspects of Jason's path module
that perhaps a PEP is warranted. All this discussion on python-dev is just
going to get lost.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
At 03:45 PM 6/27/2005 -0500, Skip Montanaro wrote:
We're getting enough discussion about various aspects of Jason's path module
that perhaps a PEP is warranted. All this discussion on python-dev is just
going to get lost.
AFAICT, the only unresolved issue outstanding is a compromise or
On Mon, 2005-06-27 at 14:25, Phillip J. Eby wrote:
[...]
As for the open issues, if we can't reach some sane compromise about
atime/ctime/mtime, I'd suggest just providing the stat() method and let
people use stat().st_mtime et al. Alternately, I'd be okay with creating
last_modified(),
Andrew Durdin:
While we'ew discussing outstanding issues: In a related discussion of
the path module on c.l.py, Thomas Heller pointed out that the path
module doesn't correctly handle unicode paths:
...
Here is a patch that avoids failure when paths can not be
represented in a single 8
At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
1226256:
The path module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are frequent praises about it.
I
Phillip J. Eby wrote:
At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
1226256:
The path module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes as much sense as fromkeys() does on a dict instance, which is
technically possible but non-sensical.
And, assuming these
Phillip It has many ways to do the same thing, and many of its property
Phillip and method names are confusing because they either do the same
Phillip thing as a standard function, but have a different name (like
Phillip the 'parent' property that is os.path.dirname in disguise),
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be properties, but rather methods.
I think ctime, mtime and atime should be (or return)
datetime.datetime
At 09:00 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
One more issue is open: the one of naming. As path is already the name of
a module, what would the new object be called to avoid confusion? pathobj?
objpath? Path?
I was thinking os.Path, myself.
At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes as much sense as fromkeys() does on a dict instance, which is
technically
At 02:31 PM 6/26/2005 -0500, Skip Montanaro wrote:
Phillip It has many ways to do the same thing, and many of its property
Phillip and method names are confusing because they either do the same
Phillip thing as a standard function, but have a different name (like
Phillip the
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be properties, but rather methods.
I think ctime, mtime and atime
Walter I think ctime, mtime and atime should be (or return)
Walter datetime.datetime objects instead of integer timestamps.
+1
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Phillip ... but have a different name (like the 'parent' property that
Phillip is os.path.dirname in disguise) ...
Phillip ... (like the 'listdir()' method that returns full paths rather
Phillip than just filenames).
Skip To the extent that the path module tries to provide a
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be
At 08:29 PM 6/26/2005 -0500, Skip Montanaro wrote:
Phillip ... but have a different name (like the 'parent' property that
Phillip is os.path.dirname in disguise) ...
Phillip ... (like the 'listdir()' method that returns full paths rather
Phillip than just filenames).
At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote:
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e.
51 matches
Mail list logo
