On Wed, Oct 1, 2008 at 4:14 PM, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Oct 1, 2008, at 3:03 PM, Glenn Linderman wrote:
>> On approximately 10/1/2008 11:30 AM, came the following characters from
>> the keyboard of James Y Knight:
>>>
>>> BTW, Windows will cheerfully let you create and access
On Oct 1, 2008, at 3:03 PM, Glenn Linderman wrote:
On approximately 10/1/2008 11:30 AM, came the following characters
from the keyboard of James Y Knight:
BTW, Windows will cheerfully let you create and access files with
"garbage surrogates" in it.
Try it yourself:
open(u"\ud8fd", 'w').clo
Bill Janssen wrote:
> Perhaps PEP 355 just went too far.
That was certainly one of the major objections to it. A filesystem path
object which didn't try to combine a half-dozen different modules into
methods on a single object, but instead focused on solving a few
specific problems with using raw
On 03:54 pm, [EMAIL PROTECTED] wrote:
I'm actually sort of liking this idea. A Pathname class, for
convenience
a subtype of String, but containing the underlying binary
representation
used by the OS. Even non-unicode pathnames could be represented.
On the one hand, I agree with you - excep
On Tuesday 30 September 2008, M.-A. Lemburg wrote:
> On 2008-09-30 08:00, Martin v. Löwis wrote:
> >> Change the default file system encoding to store bytes in Unicode is
> >> like introducing a new Python type: .
> >
> > Exactly. Seems like the best solution to me, despite your polemics.
>
> Not a
On 03:32 am, [EMAIL PROTECTED] wrote:
On Sep 30, 2008, at 10:06 PM, [EMAIL PROTECTED] wrote:
Can you clarify what proposal you are supporting for Python:
Sure. Neither of your descriptions is terribly accurate, but I'll try
to explain.
1) Two sets of APIs, one returning unicode strings, an
On 30 Sep, 09:22 pm, [EMAIL PROTECTED] wrote:
On Tue, Sep 30, 2008 at 1:04 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
Guido van Rossum wrote:
On Mon, Sep 29, 2008 at 11:00 PM, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
Martin, I don't understand why you are in favor of storing raw by
On 1-Oct-2008, at 00:32 , Martin v. Löwis wrote:
How does windows (and Python on windows) handle NFC versus NFD
issues?
That's left to the application.
Can I have two files called "ümlaut.txt", one in NFD and one NFC
form?
Yes, you can. It sounds confusing, but only in a theoretical
On 30-Sep-2008, at 23:42 , Martin v. Löwis wrote:
It's the other way 'round: On Windows, Unicode file names are the
natural choice, and byte strings have limitations. In a sense, Windows
got it right - but then, they started later. Unix missed the
opportunity
of declaring that all file APIs
On 05:56 pm, [EMAIL PROTECTED] wrote:
On Tue, Sep 30, 2008 at 10:59 AM, <[EMAIL PROTECTED]> wrote:
On 02:32 pm, [EMAIL PROTECTED] wrote:
In the absence of a 2.6 getcwdb, perhaps the fixer could just drop the
"benefit of the doubt" case? It could always be added to 2.7, and the
parity relea
On 02:32 pm, [EMAIL PROTECTED] wrote:
On Tue, Sep 30, 2008 at 6:21 AM, <[EMAIL PROTECTED]> wrote:
On 12:47 am, [EMAIL PROTECTED] wrote:
It sounds like maybe there should be some 2to3 fixers in here
somewhere,
too? Not necessarily as part of this patch, but somewhere related? I
don't
know
Silence is one of hardest arguments to refute
Have a great day!<><><><>___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail
On Wed, Oct 1, 2008 at 12:14 PM, Glenn Linderman <[EMAIL PROTECTED]> wrote:
> The original byte string must be preserved for use in actually opening
> files. How it is displayed is another question. Doing something that
> works for both Unicode display and access to the file is basically
> imposs
>> SQLite has a similar problem with NULLs, and I'm definitely sticking
>> paths in there, too.
>
> I think that you can say "all C libraries".
Just for the sake of nit-picking: the socket library, and the regular
POSIX stream IO library (as well as C standard "unformatted" IO) deal
just fine wit
BTW, Windows will cheerfully let you create and access files with
"garbage surrogates" in it.
Try it yourself:
open(u"\ud8fd", 'w').close()
os.listdir(u'.')
IMO that pretty much blows out of the water any suggestion encoding
invalid UTF-8 sequences into lone surrogates is an evil and broken
[EMAIL PROTECTED] wrote:
> > I'm actually sort of liking this idea. A Pathname class, for
> > convenience
> > a subtype of String, but containing the underlying binary
> > representation
> >used by the OS. Even non-unicode pathnames could be represented.
>
> On the one hand, I agree with you -
Antoine Pitrou writes:
> Stephen J. Turnbull sk.tsukuba.ac.jp> writes:
> >
> > It's usually not "hypothetical"; often, the user knows what it is.
> > Why not ask her? That's what web browsers do, in effect, by providing
> > View as Charset commands.
>
> The average user does not even /kn
M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-10-01 09:54, Ulrich Eckhardt wrote:
> > On Tuesday 30 September 2008, M.-A. Lemburg wrote:
> >> On 2008-09-30 08:00, Martin v. Löwis wrote:
> Change the default file system encoding to store bytes in Unicode is
> like introducing a new Py
On Wed, Oct 1, 2008 at 7:36 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> The average user does not even /know/ what a charset is.
Except those users who need the feature. They certainly have no
trouble learning how to make the pages readable once someone explains
it to them.
--
--Guido van Ro
Stephen J. Turnbull sk.tsukuba.ac.jp> writes:
>
> It's usually not "hypothetical"; often, the user knows what it is.
> Why not ask her? That's what web browsers do, in effect, by providing
> View as Charset commands.
The average user does not even /know/ what a charset is.
Web browsers provide
Antoine Pitrou writes:
> Stephen J. Turnbull xemacs.org> writes:
> >
> > What makes you think the filenames are invalid? The file*names* are
> > probably perfectly valid in the intended encoding; they are simply
> > invalid in the encoding that Python wants to apply.
>
> Those filenames
[EMAIL PROTECTED] wrote:
> The reasoning is that a lot of software doesn't care if it's wrong for
> edge cases, it's really hard to come up with something that's correct
> with respect to all of those edge cases (absurdly difficult, if you need
> to stay in the straightjacket of string / bytes type
Stephen J. Turnbull xemacs.org> writes:
>
> What makes you think the filenames are invalid? The file*names* are
> probably perfectly valid in the intended encoding; they are simply
> invalid in the encoding that Python wants to apply.
Those filenames don't work today with Python 3, the problem
Antoine Pitrou writes:
> But those funny characters only appear for invalid
> filenames.
What makes you think the filenames are invalid? The file*names* are
probably perfectly valid in the intended encoding; they are simply
invalid in the encoding that Python wants to apply.
_
Greg Ewing canterbury.ac.nz> writes:
>
> Seems like what will fail is taking one of these utf-8b
> decoded names and passing it to some external library
> that uses it as a filename without knowing that it has
> to use utf-8b to encode it. Then the funny characters
> won't be encoded the way they
On 2008-10-01 09:54, Ulrich Eckhardt wrote:
> On Tuesday 30 September 2008, M.-A. Lemburg wrote:
>> On 2008-09-30 08:00, Martin v. Löwis wrote:
Change the default file system encoding to store bytes in Unicode is
like introducing a new Python type: .
>>> Exactly. Seems like the best solut
Le Wednesday 01 October 2008 04:06:25 [EMAIL PROTECTED], vous avez écrit :
> b = gtk.Button(u"\u/hello/world")
>
> which emits this message:
> TypeError: OGtkButton.__init__() argument 1 must be string without
> null bytes or None, not unicode
>
> SQLite has a similar problem with NULLs
27 matches
Mail list logo
