* 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
> 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 --
* 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 ther
> 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
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 peopl
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
Guido van Rossum wrote:
> I don't see a way that __del__ could be invoked and access the NULL
> between the Py_CLEAR() call and the Py_INCREF() call in the second
> version.
Consider this:
class Bad:
def __del__(self):
obj.some_method()
obj.set_foo(Bad())
obj.set_foo(None)
Now,
> 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
m
Martin v. Löwis 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
http://wiki.python.org/moin/J
>> 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 el
On 2008-08-06 18:55, Antoine Pitrou wrote:
Martin v. Löwis 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
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
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 fil
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 platform
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 X
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 th
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 the
18 matches
Mail list logo
