Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

Neil Hodgson writes: >Over time, the set of trail bytes used has expanded - in GB18030 > digits are possible although many of the most important characters > for parsing such as ''' "#%&.?/''' are still safe as they may not > be trail bytes in the common double-byte character sets. That's

Re: [Python-Dev] Goodbye

On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence wrote: > I'm rather sad to have been sacked, but such is life.  I won't be doing any > more work on the bug tracker for obvious reasons, but hope that you who have > managed to keep your voluntary jobs manage to keep Python going. Umm, what? You mea

[Python-Dev] Goodbye

I'm rather sad to have been sacked, but such is life. I won't be doing any more work on the bug tracker for obvious reasons, but hope that you who have managed to keep your voluntary jobs manage to keep Python going. Kindest regards. Mark Lawrence. ___

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

>> On the other hand, it is dangerous to provide a polymorphic API which >> does that more extensive parsing, because a less than paranoid >> programmer will have very likely allowed the parsed components to >> escape from the context where their encodings can be reliably >> determined. =A0Remember

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

Ian Bicking: > I think the use case everyone has in mind here is where > you get a URL from one of these sources, and you want to handle it.  I have > a hard time imagining the sequence of events that would lead to mojibake. > Naive parsing of a document in bytes couldn't do it, because if you hav

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Wed, Sep 22, 2010 at 1:57 AM, Ian Bicking wrote: > All this is unrelated to the question, though -- a separate byte-oriented > function won't help any case I can think of.  If the programmer is > implementing something like > urlparse.urlsplit(user_input.encode(sys.getdefaultencoding())), it's

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Wed, Sep 22, 2010 at 1:10 AM, Stephen J. Turnbull wrote: > Nick Coghlan writes: > >  > (Basically, while the issue of programmers assuming 'latin-1' or >  > 'utf-8' or similar ASCII friendly encodings when they shouldn't is >  > real, I don't believe a polymorphic API here will make things any

Re: [Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote: On Tue, 21 Sep 2010 12:09:44 -0400 "P.J. Eby" wrote: > While the Web-SIG is trying to hash out PEP 444, I thought it would > be a good idea to have a backup plan that would allow the Python 3 > stdlib to move forward, without needing a major new

Re: [Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

On Tue, Sep 21, 2010 at 11:09 AM, P.J. Eby wrote: > After all, even if PEP 333 is ultimately replaced by PEP 444, it's probably > a good idea to have *some* sort of WSGI 1-ish thing available on Python 3, > with bytes/unicode and other matters settled. Indeed. Though I generally like the directi

Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

At 12:55 PM 9/21/2010 -0400, Ian Bicking wrote: On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough <chr...@plope.com> wrote: On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote: > While the Web-SIG is trying to hash out PEP 444, I thought it would > be a good idea to have a

Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby wrote: > The Python 3 specific changes are to use: > > * ``bytes`` for I/O streams in both directions > * ``str`` for environ keys and values > * ``bytes`` for arguments to start_response() and write() > This is the only thing that seems odd to me -- it

Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough wrote: > On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote: > > While the Web-SIG is trying to hash out PEP 444, I thought it would > > be a good idea to have a backup plan that would allow the Python 3 > > stdlib to move forward, without needing

Re: [Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

On Tue, 21 Sep 2010 12:09:44 -0400 "P.J. Eby" wrote: > While the Web-SIG is trying to hash out PEP 444, I thought it would > be a good idea to have a backup plan that would allow the Python 3 > stdlib to move forward, without needing a major new spec to settle > out implementation questions. I

Re: [Python-Dev] [Web-SIG] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote: > While the Web-SIG is trying to hash out PEP 444, I thought it would > be a good idea to have a backup plan that would allow the Python 3 > stdlib to move forward, without needing a major new spec to settle > out implementation questions. If a

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Tue, 2010-09-21 at 23:38 +1000, Nick Coghlan wrote: > And if this turns out to be a disaster in practice: > a) on my head be it; and > b) we still have the option of the DeprecationWarning dance for bytes > inputs to the existing functions and moving to a parallel API In the case of urllib.pars

[Python-Dev] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

While the Web-SIG is trying to hash out PEP 444, I thought it would be a good idea to have a backup plan that would allow the Python 3 stdlib to move forward, without needing a major new spec to settle out implementation questions. After all, even if PEP 333 is ultimately replaced by PEP 444,

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On 21 September 2010 16:23, Barry Warsaw wrote: > On Sep 21, 2010, at 04:01 PM, Paul Moore wrote: > >>Sorry if this is off-topic, but I don't believe I ever saw Stephen's >>email. I have a feeling that's happened a couple of times recently. >>Before I go off trying to work out why gmail is dumping

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Mon, Sep 20, 2010 at 6:19 PM, Nick Coghlan wrote: > > What are the cases you believe will cause new mojibake? > > Calling operations like urlsplit on byte sequences in non-ASCII > compatible encodings and operations like urljoin on byte sequences > that are encoded with different encodings. T

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Wed, 22 Sep 2010 00:10:01 +0900 "Stephen J. Turnbull" wrote: > > But I don't know whether the web apps programmers will be satisfied > with such a minimal API. Web app programmers will generally go through a framework, which handles encoding/decoding for them (already so in 2.x). > And there

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Sep 21, 2010, at 04:01 PM, Paul Moore wrote: >Sorry if this is off-topic, but I don't believe I ever saw Stephen's >email. I have a feeling that's happened a couple of times recently. >Before I go off trying to work out why gmail is dumping list mails on >me, did anyone else see Stephen's mail

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

Nick Coghlan writes: > (Basically, while the issue of programmers assuming 'latin-1' or > 'utf-8' or similar ASCII friendly encodings when they shouldn't is > real, I don't believe a polymorphic API here will make things any > *worse* than what would happen with a parallel API) That depends o

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On 21 September 2010 14:38, Nick Coghlan wrote: > On Tue, Sep 21, 2010 at 3:03 PM, Stephen J. Turnbull > wrote: >> On the other hand, it is dangerous to provide a polymorphic API which [...] Sorry if this is off-topic, but I don't believe I ever saw Stephen's email. I have a feeling that's happ

Re: [Python-Dev] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

On Tue, Sep 21, 2010 at 3:46 PM, Michael Foord wrote: > I agree. Don't feel strongly about it though. (I'm sure Strunk and White > would disapprove.) No doubt. http://chronicle.com/article/50-Years-of-Stupid-Grammar/25497 ;-) Steve -- Where did you get that preposterous hypothesis? Did Steve

Re: [Python-Dev] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

2010/9/21 Nick Coghlan : > On Tue, Sep 21, 2010 at 5:25 PM, Georg Brandl wrote: >> I've been told that "Note that" should be removed altogether, as it's >> quite redundant :) > > I still find starting a paragraph with "Note that" to be useful as a > mild attention getter that isn't as shouty as an

Re: [Python-Dev] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

On 21/09/2010 14:42, Nick Coghlan wrote: On Tue, Sep 21, 2010 at 5:25 PM, Georg Brandl wrote: I've been told that "Note that" should be removed altogether, as it's quite redundant :) I still find starting a paragraph with "Note that" to be useful as a mild attention getter that isn't as shout

Re: [Python-Dev] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

On Tue, Sep 21, 2010 at 5:25 PM, Georg Brandl wrote: > I've been told that "Note that" should be removed altogether, as it's > quite redundant :) I still find starting a paragraph with "Note that" to be useful as a mild attention getter that isn't as shouty as an actual ReST note. Cheers, Nick.

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Tue, Sep 21, 2010 at 3:03 PM, Stephen J. Turnbull wrote: > On the other hand, it is dangerous to provide a polymorphic API which > does that more extensive parsing, because a less than paranoid > programmer will have very likely allowed the parsed components to > escape from the context where t

Re: [Python-Dev] r84931 - in python/branches/py3k: Include/symtable.h Misc/NEWS Python/ast.c Python/compile.c Python/future.c Python/symtable.c

Am 21.09.2010 01:02, schrieb benjamin.peterson: > Author: benjamin.peterson > Date: Tue Sep 21 01:02:10 2010 > New Revision: 84931 > > Log: > add column offset to all syntax errors > Modified: python/branches/py3k/Misc/NEWS >

Re: [Python-Dev] [Python-checkins] r84906 - python/branches/py3k/Doc/library/ssl.rst

On Tue, 21 Sep 2010 02:34:46 +0200 Éric Araujo wrote: > > Log: > > Remove references to read() and write() methods, which are useless > > synonyms of recv() and send() > > Unless I’m mistaken, ssl.SSLSocket.write is still useful for use with > print, pprint and maybe other functions, Hmm, sorry?

Re: [Python-Dev] [Python-checkins] r84858 - in python/branches: py3k/Doc/library/logging.rst release27-maint/Doc/library/logging.rst

Am 21.09.2010 01:42, schrieb Éric Araujo: > Hello > > + NOTE: If you are thinking of defining your own levels, please see > the section > + on :ref:`custom-levels`. > > I think those instances of upper-case-as-markup should either be real > reST note/warning/etc. directives or plain English (