* Bill Janssen wrote:
I'm far less concerned about
the decision with regards to unquote_to_bytes/quote_from_bytes, as
those are new features which can wait.
Forgive me, but those are the *old* features, which must be there.
This whole discussion circles too much, I think. Maybe it
This whole discussion circles too much, I think. Maybe it should be pepped?
The issue isn't circular. It's been patched and tested, then a whole lot of
people agreed including Guido. Then you and Bill wanted the bytes
functionality back. So I wrote that in there too, and Bill at least said
that
On Tue, Aug 5, 2008 at 10:46 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Tue, Aug 5, 2008 at 5:56 PM, Leo Soto M. [EMAIL PROTECTED] wrote:
But that's going to be easier if I understand the why and not only
the how. I can live with a no idea why answer, though.
Close -- I would have to
* Matt Giuca wrote:
This whole discussion circles too much, I think. Maybe it should be
pepped?
The issue isn't circular. It's been patched and tested, then a whole lot
of people agreed including Guido. Then you and Bill wanted the bytes
functionality back. So I wrote that in there too,
There are a lot of quotes around. Including After the most recent flurry
of
discussion I've lost track of what's the right thing to do.
But I don't talk for other people.
OK .. let me compose myself a little. Sorry I went ahead and assumed this
was closed.
It's just frustrating to me that
André Malo wrote:
* Matt Giuca wrote:
We've reached, to quote Guido, as close as consensus as we can get on
this issue.
There are a lot of quotes around. Including After the most recent flurry of
discussion I've lost track of what's the right thing to do.
But I don't talk for other people.
I suggest we continue this discussion, if at all, on the bug-tracker,
where there's code, and more participants.
http://bugs.python.org/issue3300
I've now posted my idea of how quote/unquote should work in py3K, there.
Bill
___
Python-Dev mailing list
Nobody's been
assigned to look at it and it hasn't been given a priority, even though
we all agree it's a bug (though we disagree on how to fix it).
This I can explain (I think). Nobody is assigned to look: we usually
don't do assignments of bugs or patches, except when there is a specific
Martin v. Löwis martin at v.loewis.de writes:
URLs are just not made for non-ASCII characters.
Perhaps they are not, but every non-English wiki (just to take a simple, generic
example) potentially contains non-ASCII URLs.
e.g. http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
Implement IRIs if you want non-ASCII characters; the rules are much clearer
for these.
I think most people would expect something which works with the current World
Wide Web rather than a rigorous implementation of a specific RFC. Implementing
RFCs is fine but it does not magically
On 2008-08-06 18:55, Antoine Pitrou wrote:
Martin v. Löwis martin at v.loewis.de writes:
URLs are just not made for non-ASCII characters.
Perhaps they are not, but every non-English wiki (just to take a simple, generic
example) potentially contains non-ASCII URLs.
e.g.
On Wed, Aug 6, 2008 at 9:09 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Nobody's been
assigned to look at it and it hasn't been given a priority, even though
we all agree it's a bug (though we disagree on how to fix it).
This I can explain (I think). Nobody is assigned to look: we usually
Hello heroes and heroins of the python universe, lend me your ears and
I will tell you a tale that will make your platters spin!
As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS X provides fullfsync
which actually flushes the file
Ian Charnas wrote:
As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS X provides fullfsync
which actually flushes the file descriptor to disk. This simple patch
modifies python's fsync to take advantage of fullfsync on platforms
On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote:
Hello heroes and heroins of the python universe, lend me your ears and
I will tell you a tale that will make your platters spin!
As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does
not actually flush a file to disk... instead OS
James Y Knight wrote:
On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote:
While some people might suggest that fullfsync should be exposed as a
method on the 'os' module for platforms that support it, I believe
this is not the best approach. Because the docstring for os.fsync
says that it forces
Richard Boulton wrote:
I can't think of a situation where it would be useful to do an fsync()
in which you don't want the data to be flushed as far as possible. If
you're bothering to call fsync(), it's presumably because you need to
guarantee that the data will be in a consistent state in
17 matches
Mail list logo
