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

2010-09-21 Thread Georg Brandl
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 (that

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

2010-09-21 Thread Antoine Pitrou
On Tue, 21 Sep 2010 02:34:46 +0200 Éric Araujo mer...@netwok.org 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,

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

2010-09-21 Thread Georg Brandl
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] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

2010-09-21 Thread Nick Coghlan
On Tue, Sep 21, 2010 at 3:03 PM, Stephen J. Turnbull step...@xemacs.org 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

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

2010-09-21 Thread Nick Coghlan
On Tue, Sep 21, 2010 at 5:25 PM, Georg Brandl g.bra...@gmx.net 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.

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

2010-09-21 Thread Michael Foord
On 21/09/2010 14:42, Nick Coghlan wrote: On Tue, Sep 21, 2010 at 5:25 PM, Georg Brandlg.bra...@gmx.net 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

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

2010-09-21 Thread Benjamin Peterson
2010/9/21 Nick Coghlan ncogh...@gmail.com: On Tue, Sep 21, 2010 at 5:25 PM, Georg Brandl g.bra...@gmx.net 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

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

2010-09-21 Thread Steven Bethard
On Tue, Sep 21, 2010 at 3:46 PM, Michael Foord fuzzy...@voidspace.org.uk 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

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

2010-09-21 Thread Paul Moore
On 21 September 2010 14:38, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Sep 21, 2010 at 3:03 PM, Stephen J. Turnbull step...@xemacs.org 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

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

2010-09-21 Thread Stephen J. Turnbull
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 on

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

2010-09-21 Thread Barry Warsaw
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 via

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

2010-09-21 Thread Antoine Pitrou
On Wed, 22 Sep 2010 00:10:01 +0900 Stephen J. Turnbull step...@xemacs.org 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

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

2010-09-21 Thread Ian Bicking
On Mon, Sep 20, 2010 at 6:19 PM, Nick Coghlan ncogh...@gmail.com 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

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

2010-09-21 Thread Paul Moore
On 21 September 2010 16:23, Barry Warsaw ba...@python.org 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

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

2010-09-21 Thread P.J. Eby
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)

2010-09-21 Thread Chris McDonough
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.parse,

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

2010-09-21 Thread Chris McDonough
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] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

2010-09-21 Thread Antoine Pitrou
On Tue, 21 Sep 2010 12:09:44 -0400 P.J. Eby p...@telecommunity.com 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

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

2010-09-21 Thread Ian Bicking
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 backup plan that would allow the Python 3 stdlib to move forward,

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

2010-09-21 Thread Ian Bicking
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby p...@telecommunity.com 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

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

2010-09-21 Thread P.J. Eby
At 12:55 PM 9/21/2010 -0400, Ian Bicking wrote: On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough mailto:chr...@plope.comchr...@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] Backup plan: WSGI 1 Addenda and wsgiref update for Py3

2010-09-21 Thread Jacob Kaplan-Moss
On Tue, Sep 21, 2010 at 11:09 AM, P.J. Eby p...@telecommunity.com 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

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

2010-09-21 Thread P.J. Eby
At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote: On Tue, 21 Sep 2010 12:09:44 -0400 P.J. Eby p...@telecommunity.com 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

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

2010-09-21 Thread Nick Coghlan
On Wed, Sep 22, 2010 at 1:10 AM, Stephen J. Turnbull step...@xemacs.org 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

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

2010-09-21 Thread Nick Coghlan
On Wed, Sep 22, 2010 at 1:57 AM, Ian Bicking i...@colorstudy.com 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

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

2010-09-21 Thread Neil Hodgson
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 have a

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

2010-09-21 Thread Andrew McNamara
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, *it is

[Python-Dev] Goodbye

2010-09-21 Thread Mark Lawrence
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] Goodbye

2010-09-21 Thread Jack Diederich
On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence breamore...@yahoo.co.uk 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.

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

2010-09-21 Thread Stephen J. Turnbull
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 just