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:
> 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+03
Neil Hodgson wrote:
>>- But then, the wide API gives all results as Unicode. If you want to
>> promote only those entries that need it, it really means that you
>> only want to "demote" those that don't need it. But how can you tell
>> whether an entry needs it? There is no API to find out.
>
>
Martin v. Löwis:
> - But then, the wide API gives all results as Unicode. If you want to
> promote only those entries that need it, it really means that you
> only want to "demote" those that don't need it. But how can you tell
> whether an entry needs it? There is no API to find out.
I
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 f
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). Promoting only those e
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,
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
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() h
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()
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, M.
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
M.-A. Lemburg:
> It's naive to assume that all people in Germany using the German
> locale have German names ;-)
That is not an assumption I would make. The assumption I would make
is that if it is important to you to have your account name in a
particular character set then you will normally
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 attri
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 preferr
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 us
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 accoun
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 firs
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 - PyUnicodeObjects c
Neil Hodgson <[EMAIL PROTECTED]> writes:
> 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
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', '']
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',
u'\u0417\u0434\u0440\u0430\
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
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
> 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
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...
It isn't clear whether you are saying this should be fixed by the
user or in the library. For a quick example, say someone wrote some
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 m
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 now in SourceForge. New parallel features
> 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 pa
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
Guido van Rossum wrote:
> > By the way, it also occurs to me that for the sake of subclassability, the
> > methods should not return 'path(somestr)' when creating new objects, but
> > instead use self.__class__(somestr).
>
> Clearly it needs a PEP.
I haven't read the rest of the thread
Once, ther
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 out
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 co
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
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(),
On 6/28/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>
> AFAICT, the only unresolved issue outstanding is a compromise or
> Pronouncement regarding the atime/ctime/mtime members' datatype. This is
> assuming, of course, that making the "empty path" be os.curdir doesn't
> receive any objections,
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
Pronou
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
http://mail.python.org/mail
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()' o
At 08:52 PM 6/27/2005 +0200, Walter Dörwald wrote:
>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 t
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 'path.cwd()'; i.e. a
> constructor classmethod by analogy with
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
> prop
> >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 p
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.
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 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()' l
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 th
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
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.
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).
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 r
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 provi
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
Unsubscri
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, mti
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>
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
>tech
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.
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.datet
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)
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 fi
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
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 i
63 matches
Mail list logo
