Re: [Python-Dev] urllib.quote and unquote - Unicode issues
Wow .. a lot of replies today! On Thu, Aug 7, 2008 at 2:09 AM, "Martin v. Löwis" <[EMAIL PROTECTED]>wrote: > It hasn't been given priority: There are currently 606 patches in the > tracker, many fixing bugs of some sort. It's not clear (to me, at least) > why this should be given priority over all the other things such as > interpreter crashes. Sorry ... when I said "it hasn't been given priority" I mean "it hasn't been given *a* priority" - as in, nobody's assigned a priority to it, whatever that priority should rightfully be. > We all agree it's a bug: no, I don't. I think it's a missing feature, > at best, but I'm staying out of the discussion. As-is, urllib only > supports ASCII in URLs, and that is fine for most purposes. Seriously, Mr. L%C3%B6wis, that's a tremendously na%C3%AFve statement. > URLs are just not made for non-ASCII characters. Implement IRIs if you > want non-ASCII characters; the rules are much clearer for these. Python 3.0 fully supports Unicode. URIs support *encoding* of arbitrary characters (as of more recent revisions). The difference is that URIs *may only consist* of ASCII characters (even though they can encode Unicode characters), while IRIs may also consist of Unicode characters. It's our responsibility to implement URIs here ... IRIs are a separate issue. Having said this, I'm pretty sure Martin can't be convinced, so I'll leave that alone. On Thu, Aug 7, 2008 at 3:34 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > So unquote() should probably try to decode using UTF-8 first > and then fall back to Latin-1 if that doesn't work. That's an interesting proposal. I think I don't like it - for a user application that's a good policy. But for a programming language library, I think it should not do guesswork. It should use the encoding supplied, and have a single default. But I'd be interested to hear if anyone else wants this. As-is, it passes 'replace' to the errors argument, so encoding errors get replaced by '�' characters. OK I haven't looked at the review yet .. guess it's off to the tracker :) Matt ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small PATCH to fix os.fsync on OS X
> 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. Essentially, you are saying that you don't see a use for fsync. If that's the case, then this API should be removed from Python completely. As all others have said: the strong feature of the posix module is that it exposes the operating system calls *as-is*, i.e. without trying to tweak their semantics. If Apple had found it as a useful default for fsync to have the harddisk flushed, they would have put that into the implementation of fsync, instead of coming up with a new API. We don't second-guess operating system vendors (normally). Please understand the enormous relevance of this strategy. If we deviate from it, people might be stuck in chasing the culprit, complaining alternatingly to the OS vendor and to Python. With our strategy to the POSIX module, we can always defer people to the system vendor, and they can easily reproduce the behavior with a C program. (Of course, we also have higher-layer libbraries, were any bugs are our own). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small PATCH to fix os.fsync on OS X
Excellent comments, everyone. It looks like I didn't know the full situation, thanks scott for pointing me towards that email on darwin-dev. The email said that fsync on OS X does indeed force a flush from the operating system to the hard drive (so my earlier understanding was incorrect), but data could still be waiting in the write buffer of the physical hard drive, so OS X provides a "fullfsync" feature to force the disk to flush its buffers. So far they are seemingly the only unix to provide this. So, I think we should cancel the ticket I made in Roundup, and I'd like to make another patch that exposes os.fullfsync on platforms that support it, just like we already have os.fdatasync on supported platforms. That way, os.fsync remains untouched, and people wishing to get at fullfsync may do so. comments? Should I go ahead and make this patch? many thanks, -Ian Charnas On Thu, Aug 7, 2008 at 9:48 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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. > > Essentially, you are saying that you don't see a use for fsync. If > that's the case, then this API should be removed from Python completely. > > As all others have said: the strong feature of the posix module is that > it exposes the operating system calls *as-is*, i.e. without trying to > tweak their semantics. > > If Apple had found it as a useful default for fsync to have the > harddisk flushed, they would have put that into the implementation > of fsync, instead of coming up with a new API. We don't second-guess > operating system vendors (normally). > > Please understand the enormous relevance of this strategy. If we > deviate from it, people might be stuck in chasing the culprit, > complaining alternatingly to the OS vendor and to Python. With our > strategy to the POSIX module, we can always defer people to the > system vendor, and they can easily reproduce the behavior with > a C program. (Of course, we also have higher-layer libbraries, were > any bugs are our own). > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ian.charnas%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small PATCH to fix os.fsync on OS X
OK I finished a patch that exposes os.fullfsync on platforms that support it, and I added the corresponding documentation in Doc/library/os.rst Any comments? http://bugs.python.org/issue3517 -ian On Thu, Aug 7, 2008 at 10:17 AM, Ian Charnas <[EMAIL PROTECTED]> wrote: > Excellent comments, everyone. It looks like I didn't know the full > situation, thanks scott for pointing me towards that email on > darwin-dev. The email said that fsync on OS X does indeed force a > flush from the operating system to the hard drive (so my earlier > understanding was incorrect), but data could still be waiting in the > write buffer of the physical hard drive, so OS X provides a > "fullfsync" feature to force the disk to flush its buffers. So far > they are seemingly the only unix to provide this. > > So, I think we should cancel the ticket I made in Roundup, and I'd > like to make another patch that exposes os.fullfsync on platforms that > support it, just like we already have os.fdatasync on supported > platforms. > > That way, os.fsync remains untouched, and people wishing to get at > fullfsync may do so. > > comments? Should I go ahead and make this patch? > > many thanks, > -Ian Charnas > > On Thu, Aug 7, 2008 at 9:48 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> 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. >> >> Essentially, you are saying that you don't see a use for fsync. If >> that's the case, then this API should be removed from Python completely. >> >> As all others have said: the strong feature of the posix module is that >> it exposes the operating system calls *as-is*, i.e. without trying to >> tweak their semantics. >> >> If Apple had found it as a useful default for fsync to have the >> harddisk flushed, they would have put that into the implementation >> of fsync, instead of coming up with a new API. We don't second-guess >> operating system vendors (normally). >> >> Please understand the enormous relevance of this strategy. If we >> deviate from it, people might be stuck in chasing the culprit, >> complaining alternatingly to the OS vendor and to Python. With our >> strategy to the POSIX module, we can always defer people to the >> system vendor, and they can easily reproduce the behavior with >> a C program. (Of course, we also have higher-layer libbraries, were >> any bugs are our own). >> >> Regards, >> Martin >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ian.charnas%40gmail.com >> > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Milestones in IronPython
We reached an important milestone in the IronPython project this week with the release of IronPython 2.0 beta 4. But it's not our code that makes this release so remarkable -- it's yours, the Python developers. For the first time, Microsoft is including the standard Python library as part of what you can download from CodePlex. Previously, users of IronPython who wanted to make use of the urllib module (to give just one example) would have to download the CPython distribution separately and then fiddle with the bits on the disk to make them work together. That is no longer the case. Of course, this isn't any kind of great technical achievement -- but it is legal and cultural progress here at Microsoft. All of us working on the IronPython and IronRuby projects are committed to pulling the company in a more open source direction, so it's very gratifying to see this happening. Links: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=14353 http://devhawk.net/2008/08/06/Including+The+Batteries+In+IronPython.aspx (IronPython 2.0 targets compatibility with Python 2.5.) -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Milestones in IronPython
On Thu, Aug 7, 2008 at 3:25 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > We reached an important milestone in the IronPython project this week > with the release of IronPython 2.0 beta 4. But it's not our code that > makes this release so remarkable -- it's yours, the Python developers. > For the first time, Microsoft is including the standard Python > library as part of what you can download from CodePlex. Previously, > users of IronPython who wanted to make use of the urllib module (to > give just one example) would have to download the CPython distribution > separately and then fiddle with the bits on the disk to make them work > together. That is no longer the case. > > Of course, this isn't any kind of great technical achievement -- but > it is legal and cultural progress here at Microsoft. All of us > working on the IronPython and IronRuby projects are committed to > pulling the company in a more open source direction, so it's very > gratifying to see this happening. > Glad you were able to work out what you needed internally to see this happen, Curt! -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib.quote and unquote - Unicode issues
FWIW, the rest of this discussion is now happening in the tracker: http://bugs.python.org/issue3300. We could really use some feedback from Python users in Asian countries. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Milestones in IronPython
On Thu, Aug 7, 2008 at 3:36 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Thu, Aug 7, 2008 at 3:25 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: >> We reached an important milestone in the IronPython project this week >> with the release of IronPython 2.0 beta 4. But it's not our code that >> makes this release so remarkable -- it's yours, the Python developers. >> For the first time, Microsoft is including the standard Python >> library as part of what you can download from CodePlex. Previously, >> users of IronPython who wanted to make use of the urllib module (to >> give just one example) would have to download the CPython distribution >> separately and then fiddle with the bits on the disk to make them work >> together. That is no longer the case. >> >> Of course, this isn't any kind of great technical achievement -- but >> it is legal and cultural progress here at Microsoft. All of us >> working on the IronPython and IronRuby projects are committed to >> pulling the company in a more open source direction, so it's very >> gratifying to see this happening. >> > > Glad you were able to work out what you needed internally to see this > happen, Curt! Indeed, very good news. It made Google's internal open source list already. :-) Congrats on the release, Curt and team!! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
