Re: [Python-Dev] PEP 3333: wsgi_string() function
On Sat, Jan 8, 2011 at 6:16 AM, Robert Brewer wrote: > Python 3.1 was released June 27th, 2009. We're coming up faster on the > two-year period than we seem to be on a revised WSGI spec. Maybe we > should shoot for a "bytes of a known encoding" type first. There were a few minor* practical issues in getting agreement on how such a type would actually behave. Instead, the approach WSGI adopted (or the stricter, 7-bit ASCII only approach used internally by urllib.parse to handle bytes in 3.2) was deemed sufficient, since it could be done right now without having to agree on how many different bikesheds were needed and what colours they should all be. Cheers, Nick. *i.e. major :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] r87838 - python/branches/py3k/Doc/library/threading.rst
On Fri, 7 Jan 2011 22:54:18 +0100 (CET) raymond.hettinger wrote: > Author: raymond.hettinger > Date: Fri Jan 7 22:54:18 2011 > New Revision: 87838 > > Log: > Revert r87821 which moved the source link to the wrong section (from the > module intro covering the module to a section on thread imports). Well, I insist, Raymond. The threading module's source code is less important than the threading module API, so can you please leave that link at the bottom? *Especially* given you're not even involved in maintenance of that module. Thank you Antoine. ___ 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] PEP 3333: wsgi_string() function
Paul Moore wrote: > Robert Brewer wrote: > > P.J. Eby wrote: > > > Also, it should be mentioned that none of this would be > > > necessary if we could've gotten a "bytes of a known encoding" > > > type. > > > > Still looking forward to the day when that moratorium is lifted. > > Anyone have any idea when that will be? > > See PEP 3003 (http://www.python.org/dev/peps/pep-3003/) - Python 3.3 > is expected to be post-moratorium. "This PEP proposes a temporary moratorium (suspension) of all changes to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1." Python 3.1 was released June 27th, 2009. We're coming up faster on the two-year period than we seem to be on a revised WSGI spec. Maybe we should shoot for a "bytes of a known encoding" type first. Robert Brewer fuman...@aminus.org ___ 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] PEP 3333: wsgi_string() function
P.J. Eby wrote: > Right. Also, it should be mentioned that none of this would be > necessary if we could've gotten a "bytes of a known encoding" type. Indeed! Or even "string using a known encoding"... > If you look back to the last big Python-Dev discussion on > bytes/unicode and stdlib API breakage, this was the holdup for getting > a sane WSGI spec. Yep. Bill ___ 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] PEP 3333: wsgi_string() function
On Fri, Jan 7, 2011 at 12:04 PM, P.J. Eby wrote: > At 09:43 AM 1/7/2011 -0500, James Y Knight wrote: >> >> On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote: >> > I don't understand why you are attached to this horrible hack >> > (bytes-in-unicode). It introduces more work and more confusing than >> > using raw bytes unchanged. >> > >> > It doesn't work and so something has to be changed. >> >> It's gross but it does work. This has been discussed ad-nausium on web-sig >> over a period of years. >> >> I'd like to reiterate that it is only even a potential issue for the >> PATH_INFO/SCRIPT_NAME keys. Those two keys are required to have been >> urldecoded already, into byte-data in some encoding. For all the other keys >> (including the ones from os.environ), they are either *properly* decoded in >> 8859-1 or are just ascii (possibly still urlencoded, so the app needs to >> urldecode and decode into a string with the correct encoding). > > Right. Also, it should be mentioned that none of this would be necessary if > we could've gotten a "bytes of a known encoding" type. If you look back to > the last big Python-Dev discussion on bytes/unicode and stdlib API breakage, > this was the holdup for getting a sane WSGI spec. > > Since we couldn't change the language to fix the problem (due to the > moratorium), we had to use this less-pleasant way of dealing with things, in > order to get a final WSGI spec for Python 3. If the fix was that critical; exceptions should be made. ___ 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] PEP 3333: wsgi_string() function
On 7 January 2011 18:36, Robert Brewer wrote: > Still looking forward to the day when that moratorium is lifted. Anyone > have any idea when that will be? See PEP 3003 (http://www.python.org/dev/peps/pep-3003/) - Python 3.3 is expected to be post-moratorium. Paul. ___ 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] API refactoring tracker field for Python4
On 07/01/2011 19:22, Guido van Rossum wrote: On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord wrote: On 07/01/2011 19:11, Guido van Rossum wrote: On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky wrote: -1 on the "star system" for the tracker The tracker on Google Code uses stars. We use this tracker to track external App Engine issues. It works very well to measure how widespread a particular issue or need is (even if we don't always fix the highest-star issues first -- the top issues are "unfixable" like PHP support :-). Maybe it works because in that tracker, a star means you get emailed when the issue is updated; this makes people think twice before frivolously adding a star. This is not quite the same as the "nosy" list: adding a star is less work in the UI, you don't have to think up something meaningful to say, and no email is generated merely because someone adds or removes a star. In our issue tracker it is more or less the same. Adding yourself as nosy sends you emails when it is updated and there is a convenient button for adding yourself as nosy without having to think up a meaningful comment. Ah, that must be new -- I didn't realize that. Nice. It is. Sorry I should have made that clearer. Now I also want a button to *remove* myself from the nosy list. Me too - but it was considered unnecessary clutter in the UI. I (Of course, a better UI for adding/removing yourself could be a star. Clicking the star changes your nosy status. It should work immediately, unlike the existing [+] button.) Right, you still need to submit after clicking [+] at the moment. The only (sometimes annoying but sometimes useful or interesting) difference is that you also get emailed when someone else adds themselves as nosy. Maybe that could be fixed? Then the remaining feature would be a way to sort issue lists by number of nosy people, and to display the length of the nosy list. Sounds good too me. Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] API refactoring tracker field for Python4
On 07/01/2011 18:44, Antoine Pitrou wrote: On Fri, 7 Jan 2011 13:36:26 -0500 Alexander Belopolsky wrote: On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote: .. Don't you think that if people could review issues and "star" them then such minor issues could be scheduled for release not only by "severity" status as decided be release manager and several core developers, but also by community vote? Anyone can already cast his or her vote by posting a comment with +1 or -1 in it. Doing so brings the issue to the top of the default view and gets an e-mail into many developers' mailboxes. I certainly hope casual users don't start posting lots of +1s and -1s around, though. Well, some indication of how many users this affects may be useful when looking at issues to work on. Launchpad has a button for "this affects me" and you can see how many users are affected by an issue (or have declared that at least). Not sure if this sends you email, but I'm pretty sure it is different to subscribing to an issue - which is nice. Sometimes I care about an issue but can neither fix it myself nor want to receive every email from the discussion on the issue tracker. Michael Regards Antoine. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 11:18 AM, Antoine Pitrou wrote: > I'd also mention that many bugzilla installs have a "voting" facility > where people can vote for a limited number of issues of their choice (I > think the number of votes also depends on the user's number of > contributions, although I'm not sure). The latter part sounds like overengineering by geeks too worried about abuse. -- --Guido van Rossum (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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 11:15 AM, Michael Foord wrote: > On 07/01/2011 19:11, Guido van Rossum wrote: >> >> On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky >> wrote: >>> >>> -1 on the "star system" for the tracker >> >> The tracker on Google Code uses stars. We use this tracker to track >> external App Engine issues. It works very well to measure how >> widespread a particular issue or need is (even if we don't always fix >> the highest-star issues first -- the top issues are "unfixable" like >> PHP support :-). >> >> Maybe it works because in that tracker, a star means you get emailed >> when the issue is updated; this makes people think twice before >> frivolously adding a star. This is not quite the same as the "nosy" >> list: adding a star is less work in the UI, you don't have to think up >> something meaningful to say, and no email is generated merely because >> someone adds or removes a star. >> > In our issue tracker it is more or less the same. Adding yourself as nosy > sends you emails when it is updated and there is a convenient button for > adding yourself as nosy without having to think up a meaningful comment. Ah, that must be new -- I didn't realize that. Nice. Now I also want a button to *remove* myself from the nosy list. (Of course, a better UI for adding/removing yourself could be a star. Clicking the star changes your nosy status. It should work immediately, unlike the existing [+] button.) > The only (sometimes annoying but sometimes useful or interesting) difference > is that you also get emailed when someone else adds themselves as nosy. Maybe that could be fixed? Then the remaining feature would be a way to sort issue lists by number of nosy people, and to display the length of the nosy list. -- --Guido van Rossum (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] API refactoring tracker field for Python4
On Fri, 7 Jan 2011 11:11:47 -0800 Guido van Rossum wrote: > On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky > wrote: > > -1 on the "star system" for the tracker > > The tracker on Google Code uses stars. We use this tracker to track > external App Engine issues. It works very well to measure how > widespread a particular issue or need is (even if we don't always fix > the highest-star issues first -- the top issues are "unfixable" like > PHP support :-). > > Maybe it works because in that tracker, a star means you get emailed > when the issue is updated; this makes people think twice before > frivolously adding a star. This is not quite the same as the "nosy" > list: adding a star is less work in the UI, you don't have to think up > something meaningful to say, and no email is generated merely because > someone adds or removes a star. I'd also mention that many bugzilla installs have a "voting" facility where people can vote for a limited number of issues of their choice (I think the number of votes also depends on the user's number of contributions, although I'm not sure). Regards Antoine. ___ 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] API refactoring tracker field for Python4
On 07/01/2011 19:11, Guido van Rossum wrote: On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky wrote: -1 on the "star system" for the tracker The tracker on Google Code uses stars. We use this tracker to track external App Engine issues. It works very well to measure how widespread a particular issue or need is (even if we don't always fix the highest-star issues first -- the top issues are "unfixable" like PHP support :-). Maybe it works because in that tracker, a star means you get emailed when the issue is updated; this makes people think twice before frivolously adding a star. This is not quite the same as the "nosy" list: adding a star is less work in the UI, you don't have to think up something meaningful to say, and no email is generated merely because someone adds or removes a star. In our issue tracker it is more or less the same. Adding yourself as nosy sends you emails when it is updated and there is a convenient button for adding yourself as nosy without having to think up a meaningful comment. The only (sometimes annoying but sometimes useful or interesting) difference is that you also get emailed when someone else adds themselves as nosy. Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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] API refactoring tracker field for Python4
Am 07.01.2011 19:39, schrieb Brian Curtin: > Tagging: > as a tracker user, try to add tag 'easy' to some easy issue > > > You probably need escalated privileges for this. If you can't change it, you > can > always request on the issue that a field be changed. He *could* also behave reasonable for a while, leading to him being granted tracker maintenance privileges. Georg ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 10:36 AM, Alexander Belopolsky wrote: > -1 on the "star system" for the tracker The tracker on Google Code uses stars. We use this tracker to track external App Engine issues. It works very well to measure how widespread a particular issue or need is (even if we don't always fix the highest-star issues first -- the top issues are "unfixable" like PHP support :-). Maybe it works because in that tracker, a star means you get emailed when the issue is updated; this makes people think twice before frivolously adding a star. This is not quite the same as the "nosy" list: adding a star is less work in the UI, you don't have to think up something meaningful to say, and no email is generated merely because someone adds or removes a star. -- --Guido van Rossum (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] API refactoring tracker field for Python4
> Module split: > try to get all issues for 'os' module > try to subscribe to all commits for 'CGIHTTPServer' +1 I've been thinking about such a thing as well and I think it would be useful. Every now and then I go to the bug tracker to see whether the modules I usually maintain (mainly ftplib, asyncore, asynchat) need some attention. I do this by using the plain text search but a select box containing all the module names would be better. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/1/7 anatoly techtonik : > On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin wrote: >>> >>> There are many API changes and proposals that were forgotten and >>> didn't get into Python 3, although they should be, because it was the >>> only chance to change things with backwards compatibility break. For >>> example http://bugs.python.org/issue1559549 >> >> That can be added in 3.3. >> To answer your comment on the issue: no investigation is needed. It didn't >> make it in yet because there was no code written for it. It's really not a >> big deal, it happens all the time. > > Don't you think that if more people were aware of this issue, the > patch could be made faster? > >>> This happened, because of poor bug management, where community doesn't >>> play any role in determining which issues are desired. >> >> The community absolutely plays a role in determining which issues are >> desired. They do this by action when they want something. A patch says a >> whole lot about desire. >> > Don't you think that if people could review issues and "star" them > then such minor issues could be scheduled for release not only by > "severity" status as decided be release manager and several core > developers, but also by community vote? > > Patch requires time, experience and approved contribution agreement, > which you've sent using ground mail beforehand. Voting doesn't require > any of this, but helps core developers see what user community wants. > With the list of desired features Jesse Noller sponsored sprints will > have more value for all of us. > >>> >>> This mostly because of limitation of our tracker and desire of people >>> to extend it to get damn "stars", module split, sorting, digging and >>> tagging options. >> >> I have no idea what any of this means. > > Stars: > go http://code.google.com/p/support/issues/list > find Stars column > guess > > Module split: > try to get all issues for 'os' module > try to subscribe to all commits for 'CGIHTTPServer' > > Sorting: > click on column titles in bug tracker search results > > Tagging: > as a tracker user, try to add tag 'easy' to some easy issue > >>> >>> I won't be surprised if things won't change in the next couple of >>> years, that's why I'd like to propose a very small change, so that >>> when time will come to create Python4 (and standard library won't be >>> separated from interpreter by this time), everybody can get quickly >>> get a list of proposed API enhancements and filter which are eligible >>> for the next BC API break. This change is a simple "api-refactoring" >>> flag that could be added to corresponding issues by tracker users. >> >> I'm not sure I see the need for such a flag, as there are probably too few >> cases for this in the first place. > > I haven't started using Python 3 yet, but I already know some annoying > API issues that are not fixed there. Unfortunately, I don't remember > them to give you a list. That's why I asked for a flag. > -- > anatoly t. > ___ > 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/g.rodola%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] API refactoring tracker field for Python4
On Fri, 7 Jan 2011 12:39:34 -0600 Brian Curtin wrote: > > > > I haven't started using Python 3 yet, but I already know some annoying > > API issues that are not fixed there. Unfortunately, I don't remember > > them to give you a list. That's why I asked for a flag. > > If you haven't used it yet, then how are you already annoyed...? Anatoly is apparently annoyed by a lot of things he never participates in (such as contributing to Python, for example). Regards Antoine. ___ 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] API refactoring tracker field for Python4
On Fri, 7 Jan 2011 13:36:26 -0500 Alexander Belopolsky wrote: > On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote: > .. > > Don't you think that if people could review issues and "star" them > > then such minor issues could be scheduled for release not only by > > "severity" status as decided be release manager and several core > > developers, but also by community vote? > > > > Anyone can already cast his or her vote by posting a comment with +1 > or -1 in it. Doing so brings the issue to the top of the default view > and gets an e-mail into many developers' mailboxes. I certainly hope casual users don't start posting lots of +1s and -1s around, though. Regards Antoine. ___ 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] Summary of Python tracker Issues
On Fri, Jan 7, 2011 at 1:17 PM, anatoly techtonik wrote: .. >>> Issues counts and deltas: >>> open 2501 (-24) >>> closed 20138 (+80) >>> total 22639 (+56) .. > Less users -> less issues. It's always easy to speedup the process by > leaving the most irritating ones. ;) You should read the summary more carefully before leaving a witty comment like this. Hint: "total 22639 (+56)". ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote: > On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin > wrote: > >> > >> This mostly because of limitation of our tracker and desire of people > >> to extend it to get damn "stars", module split, sorting, digging and > >> tagging options. > > > > I have no idea what any of this means. > > Stars: > go http://code.google.com/p/support/issues/list > find Stars column > guess > This reminds me of my inbox, where I star emails all the time and do absolutely nothing different to them compared to non-starred emails. I personally don't see the need for that, so that's a -1 for me. > Module split: > try to get all issues for 'os' module > No solution for this right now, but people have suggested that we add drop-downs for each module. I'm -0 on that. > try to subscribe to all commits for 'CGIHTTPServer' > You can subscribe to the python-checkins mailing list and create a filter that looks for whatever you want. > > Sorting: > click on column titles in bug tracker search results > This could probably be solved with a patch to our Roundup instance. > > Tagging: > as a tracker user, try to add tag 'easy' to some easy issue > You probably need escalated privileges for this. If you can't change it, you can always request on the issue that a field be changed. > >> > >> I won't be surprised if things won't change in the next couple of > >> years, that's why I'd like to propose a very small change, so that > >> when time will come to create Python4 (and standard library won't be > >> separated from interpreter by this time), everybody can get quickly > >> get a list of proposed API enhancements and filter which are eligible > >> for the next BC API break. This change is a simple "api-refactoring" > >> flag that could be added to corresponding issues by tracker users. > > > > I'm not sure I see the need for such a flag, as there are probably too > few > > cases for this in the first place. > > I haven't started using Python 3 yet, but I already know some annoying > API issues that are not fixed there. Unfortunately, I don't remember > them to give you a list. That's why I asked for a flag. If you haven't used it yet, then how are you already annoyed...? ___ 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] PEP 3333: wsgi_string() function
P.J. Eby wrote: > At 09:43 AM 1/7/2011 -0500, James Y Knight wrote: > >On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote: > > > I don't understand why you are attached to this horrible hack > > > (bytes-in-unicode). It introduces more work and more confusing than > > > using raw bytes unchanged. > > > > > > It doesn't work and so something has to be changed. > > > >It's gross but it does work. This has been discussed ad-nausium on > >web-sig over a period of years. > > > >I'd like to reiterate that it is only even a potential issue for the > >PATH_INFO/SCRIPT_NAME keys. Those two keys are required to have been > >urldecoded already, into byte-data in some encoding. For all the > >other keys (including the ones from os.environ), they are either > >*properly* decoded in 8859-1 or are just ascii (possibly still > >urlencoded, so the app needs to urldecode and decode into a string > >with the correct encoding). > > Right. Also, it should be mentioned that none of this would be > necessary if we could've gotten a "bytes of a known encoding" > type. If you look back to the last big Python-Dev discussion on > bytes/unicode and stdlib API breakage, this was the holdup for > getting a sane WSGI spec. > > Since we couldn't change the language to fix the problem (due to the > moratorium), we had to use this less-pleasant way of dealing with > things, in order to get a final WSGI spec for Python 3. > > (If anybody is wondering about the specifics of the language change > that was needed, it'd be having a "bytes with known encoding" type, > that when combined in any polymorphic operation with a unicode > string, would result in bytes-with-encoding output, and would raise > an error if the resulting value could not be encoded in the target > encoding. Then we would simply do all WSGI header operations with > this type, using latin-1 as the target encoding.) Still looking forward to the day when that moratorium is lifted. Anyone have any idea when that will be? Bob ___ 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] API refactoring tracker field for Python4
On 2011-01-07, at 7:14 PM, anatoly techtonik wrote: > Don't you think that if people could review issues and "star" them > then such minor issues could be scheduled for release not only by > "severity" status as decided be release manager and several core > developers, but also by community vote? > > Patch requires time, experience and approved contribution agreement, > which you've sent using ground mail beforehand. Voting doesn't require > any of this, but helps core developers see what user community wants. > With the list of desired features Jesse Noller sponsored sprints will > have more value for all of us. Two things. First, technically, the bug tracker already has "stars". It's the nosy list. You can even run a search by nosy count. Second, I'm not sure starring matters that much. Ultimately, for something to be done, you need a patch. Sure, sometimes, the patch is going to be made by someone who has no interest in it, but I think most of the time the patch is submitted by someone wanting the patch to be applied. I don't think the number of stars affect the likeliness of a patch being created very much. Maybe you can point to a google code project for which starring is used intensively and to observably good results? Virgil Dupras ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 1:14 PM, anatoly techtonik wrote: .. > Don't you think that if people could review issues and "star" them > then such minor issues could be scheduled for release not only by > "severity" status as decided be release manager and several core > developers, but also by community vote? > Anyone can already cast his or her vote by posting a comment with +1 or -1 in it. Doing so brings the issue to the top of the default view and gets an e-mail into many developers' mailboxes. Number of votes is never a deciding factor on any issue, so tallying them automatically is rather pointless. A vote that is accompanied by a rationale or a patch will always carry greater weight than just a +1. -1 on the "star system" for the tracker (Note that some kind of vote/star system is contemplated for the community documentation.) ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 12:14, anatoly techtonik wrote: > On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin > wrote: > >> > >> There are many API changes and proposals that were forgotten and > >> didn't get into Python 3, although they should be, because it was the > >> only chance to change things with backwards compatibility break. For > >> example http://bugs.python.org/issue1559549 > > > > That can be added in 3.3. > > To answer your comment on the issue: no investigation is needed. It > didn't > > make it in yet because there was no code written for it. It's really not > a > > big deal, it happens all the time. > > Don't you think that if more people were aware of this issue, the > patch could be made faster? > Maybe, but someone still has to write the code. You could start a facebook group for the issue and it could have 10,000 "likes", but it still doesn't solve the problem. I'm reminded of the saying "9 women can't have a baby in 1 month"... I do think it would be great if more people were involved in the issue tracker. I don't know what it will take to get more people involved, but I know it involves a lot more than modifying the tracker itself. > > >> This happened, because of poor bug management, where community doesn't > >> play any role in determining which issues are desired. > > > > The community absolutely plays a role in determining which issues are > > desired. They do this by action when they want something. A patch says a > > whole lot about desire. > > > Don't you think that if people could review issues and "star" them > then such minor issues could be scheduled for release not only by > "severity" status as decided be release manager and several core > developers, but also by community vote? > I'm not sure thatt's the right answer here. I'd rather people "star" or vote on issues by completing a step of the process rather than just clicking a thumbs up button. Writing a test case or checking that a patch applies on a particular branch is a vote to me. > Patch requires time, experience and approved contribution agreement, > which you've sent using ground mail beforehand. Voting doesn't require > any of this, but helps core developers see what user community wants. > I think the fact that it requires no "skin in the game" is a negative point. I don't show up at government meetings and vote on things -- I don't have that power. If I want something voted on, I go through a representative and I tell them my story, my side of things, and show them what I want and why I want it. If we just let people vote on things, the first issue that would be created would be "Remove the GIL" and it would have 10,000 votes and zero patches. ___ 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] Summary of Python tracker Issues
On Fri, Jan 7, 2011 at 7:55 PM, Michael Foord wrote: > On 07/01/2011 17:07, Python tracker wrote: >> >> ACTIVITY SUMMARY (2010-12-31 - 2011-01-07) >> Python tracker athttp://bugs.python.org/ >> >> To view or respond to any of the issues listed below, click on the issue. >> Do NOT respond to this message. >> >> Issues counts and deltas: >> open 2501 (-24) >> closed 20138 (+80) >> total 22639 (+56) >> > > Nice work everyone. :-) > > At this rate we'll be down to zero open issues in only 2 years. ;-) Less users -> less issues. It's always easy to speedup the process by leaving the most irritating ones. ;) -- anatoly t. ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 7:41 PM, Brian Curtin wrote: >> >> There are many API changes and proposals that were forgotten and >> didn't get into Python 3, although they should be, because it was the >> only chance to change things with backwards compatibility break. For >> example http://bugs.python.org/issue1559549 > > That can be added in 3.3. > To answer your comment on the issue: no investigation is needed. It didn't > make it in yet because there was no code written for it. It's really not a > big deal, it happens all the time. Don't you think that if more people were aware of this issue, the patch could be made faster? >> This happened, because of poor bug management, where community doesn't >> play any role in determining which issues are desired. > > The community absolutely plays a role in determining which issues are > desired. They do this by action when they want something. A patch says a > whole lot about desire. > Don't you think that if people could review issues and "star" them then such minor issues could be scheduled for release not only by "severity" status as decided be release manager and several core developers, but also by community vote? Patch requires time, experience and approved contribution agreement, which you've sent using ground mail beforehand. Voting doesn't require any of this, but helps core developers see what user community wants. With the list of desired features Jesse Noller sponsored sprints will have more value for all of us. >> >> This mostly because of limitation of our tracker and desire of people >> to extend it to get damn "stars", module split, sorting, digging and >> tagging options. > > I have no idea what any of this means. Stars: go http://code.google.com/p/support/issues/list find Stars column guess Module split: try to get all issues for 'os' module try to subscribe to all commits for 'CGIHTTPServer' Sorting: click on column titles in bug tracker search results Tagging: as a tracker user, try to add tag 'easy' to some easy issue >> >> I won't be surprised if things won't change in the next couple of >> years, that's why I'd like to propose a very small change, so that >> when time will come to create Python4 (and standard library won't be >> separated from interpreter by this time), everybody can get quickly >> get a list of proposed API enhancements and filter which are eligible >> for the next BC API break. This change is a simple "api-refactoring" >> flag that could be added to corresponding issues by tracker users. > > I'm not sure I see the need for such a flag, as there are probably too few > cases for this in the first place. I haven't started using Python 3 yet, but I already know some annoying API issues that are not fixed there. Unfortunately, I don't remember them to give you a list. That's why I asked for a flag. -- anatoly t. ___ 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] Summary of Python tracker Issues
On 07/01/2011 17:07, Python tracker wrote: ACTIVITY SUMMARY (2010-12-31 - 2011-01-07) Python tracker athttp://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2501 (-24) closed 20138 (+80) total 22639 (+56) Nice work everyone. :-) At this rate we'll be down to zero open issues in only 2 years. ;-) Michael -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessinghttp://www.sqlite.org/different.html ___ 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] API refactoring tracker field for Python4
On Fri, Jan 7, 2011 at 11:20, anatoly techtonik wrote: > There are many API changes and proposals that were forgotten and > didn't get into Python 3, although they should be, because it was the > only chance to change things with backwards compatibility break. For > example http://bugs.python.org/issue1559549 That can be added in 3.3. To answer your comment on the issue: no investigation is needed. It didn't make it in yet because there was no code written for it. It's really not a big deal, it happens all the time. > This happened, because of poor bug management, where community doesn't > play any role in determining which issues are desired. > The community absolutely plays a role in determining which issues are desired. They do this by action when they want something. A patch says a whole lot about desire. > This mostly because of limitation of our tracker and desire of people > to extend it to get damn "stars", module split, sorting, digging and > tagging options. > I have no idea what any of this means. I won't be surprised if things won't change in the next couple of > years, that's why I'd like to propose a very small change, so that > when time will come to create Python4 (and standard library won't be > separated from interpreter by this time), everybody can get quickly > get a list of proposed API enhancements and filter which are eligible > for the next BC API break. This change is a simple "api-refactoring" > flag that could be added to corresponding issues by tracker users. I'm not sure I see the need for such a flag, as there are probably too few cases for this in the first place. ___ 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] API refactoring tracker field for Python4
There are many API changes and proposals that were forgotten and didn't get into Python 3, although they should be, because it was the only chance to change things with backwards compatibility break. For example http://bugs.python.org/issue1559549 This happened, because of poor bug management, where community doesn't play any role in determining which issues are desired. This mostly because of limitation of our tracker and desire of people to extend it to get damn "stars", module split, sorting, digging and tagging options. I won't be surprised if things won't change in the next couple of years, that's why I'd like to propose a very small change, so that when time will come to create Python4 (and standard library won't be separated from interpreter by this time), everybody can get quickly get a list of proposed API enhancements and filter which are eligible for the next BC API break. This change is a simple "api-refactoring" flag that could be added to corresponding issues by tracker users. -- anatoly t. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-12-31 - 2011-01-07)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2501 (-24)
closed 20138 (+80)
total 22639 (+56)
Open issues with patches: 1045
Issues opened (40)
==
#4188: test_threading hang when running as verbose
http://bugs.python.org/issue4188 reopened by r.david.murray
#8109: Server-side support for TLS Server Name Indication extension
http://bugs.python.org/issue8109 reopened by pitrou
#10789: Lock.acquire documentation is misleading
http://bugs.python.org/issue10789 reopened by terry.reedy
#10803: ctypes: better support of bytearray objects
http://bugs.python.org/issue10803 opened by mfxmfx
#10805: traceback.print_exception throws AttributeError when exception
http://bugs.python.org/issue10805 opened by abingham
#10808: ssl unwrap fails with Error 0
http://bugs.python.org/issue10808 opened by apollo13
#10811: sqlite segfault with generators
http://bugs.python.org/issue10811 opened by Erick.Tryzelaar
#10812: Add some posix functions
http://bugs.python.org/issue10812 opened by rosslagerwall
#10813: Suppress adding decimal point for places=0 in moneyfmt()
http://bugs.python.org/issue10813 opened by cgrohmann
#10817: urllib.request.urlretrieve never raises ContentTooShortError i
http://bugs.python.org/issue10817 opened by RC
#10818: pydoc: Remove old server and tk panel
http://bugs.python.org/issue10818 opened by haypo
#10820: 3.2 Makefile changes for versioned scripts break OS X framewor
http://bugs.python.org/issue10820 opened by ned.deily
#10822: test_getgroups failure under Solaris
http://bugs.python.org/issue10822 opened by pitrou
#10826: pass_fds sometimes fails
http://bugs.python.org/issue10826 opened by pitrou
#10827: Functions in time module should support year < 1900 when accep
http://bugs.python.org/issue10827 opened by belopolsky
#10829: PyUnicode_FromFormatV() bugs with "%" and "%%" format strings
http://bugs.python.org/issue10829 opened by haypo
#10830: PyUnicode_FromFormatV("%c") doesn't support non-BMP characters
http://bugs.python.org/issue10830 opened by haypo
#10831: PyUnicode_FromFormatV() doesn't support %li, %lli, %zi
http://bugs.python.org/issue10831 opened by haypo
#10832: Add support of bytes objects in PyBytes_FromFormatV()
http://bugs.python.org/issue10832 opened by haypo
#10833: Replace %.100s by %s in PyErr_Format(): the arbitrary limit of
http://bugs.python.org/issue10833 opened by haypo
#10834: Python 2.7 x86 fails to run in Windows 7
http://bugs.python.org/issue10834 opened by excubated
#10835: sys.executable default and altinstall
http://bugs.python.org/issue10835 opened by allan
#10836: TypeError during exception handling in urllib.request.urlretri
http://bugs.python.org/issue10836 opened by Alexandru.MoÈoi
#10837: Issue catching KeyboardInterrupt while reading stdin
http://bugs.python.org/issue10837 opened by Josh.Hanson
#10838: subprocess __all__ is incomplete
http://bugs.python.org/issue10838 opened by a.badger
#10839: email module should not allow some header field repetitions
http://bugs.python.org/issue10839 opened by adrien-saladin
#10841: binary stdio
http://bugs.python.org/issue10841 opened by v+python
#10842: Update third-party libraries for OS X installer builds
http://bugs.python.org/issue10842 opened by ned.deily
#10843: OS X installer: install the Tools source directory
http://bugs.python.org/issue10843 opened by ned.deily
#10845: test_multiprocessing failure under Windows
http://bugs.python.org/issue10845 opened by pitrou
#10847: Distutils drops -fno-strict-aliasing when CFLAGS are set
http://bugs.python.org/issue10847 opened by skrah
#10848: Move test.regrtest from getopt to argparse
http://bugs.python.org/issue10848 opened by brett.cannon
#10849: Backport test/__main__
http://bugs.python.org/issue10849 opened by belopolsky
#10850: inconsistent behavior concerning multiprocessing.manager.BaseM
http://bugs.python.org/issue10850 opened by chrysn
#10851: further extend ssl SNI and ciphers API
http://bugs.python.org/issue10851 opened by grooverdan
#10852: SSL/TLS sni use in smtp,pop,imap,nntp,ftp client libs by defau
http://bugs.python.org/issue10852 opened by grooverdan
#10854: Output DLL name in error message of ImportError when DLL is mi
http://bugs.python.org/issue10854 opened by techtonik
#10855: wave.Wave_read.close() doesn't release file
http://bugs.python.org/issue10855 opened by pjcreath
#10856: documentation for ImportError parameters and attributes
http://bugs.python.org/issue10856 opened by techtonik
#10828: Cannot use nonascii utf8 in names of files imported from
http://bugs.python.org/issue10828 opened by ingemar
Most recent 15 issues with no replies (15)
==
#10856: documentation for ImportError parameters and attributes
http://bugs.
Re: [Python-Dev] PEP 3333: wsgi_string() function
At 09:43 AM 1/7/2011 -0500, James Y Knight wrote: On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote: > I don't understand why you are attached to this horrible hack > (bytes-in-unicode). It introduces more work and more confusing than > using raw bytes unchanged. > > It doesn't work and so something has to be changed. It's gross but it does work. This has been discussed ad-nausium on web-sig over a period of years. I'd like to reiterate that it is only even a potential issue for the PATH_INFO/SCRIPT_NAME keys. Those two keys are required to have been urldecoded already, into byte-data in some encoding. For all the other keys (including the ones from os.environ), they are either *properly* decoded in 8859-1 or are just ascii (possibly still urlencoded, so the app needs to urldecode and decode into a string with the correct encoding). Right. Also, it should be mentioned that none of this would be necessary if we could've gotten a "bytes of a known encoding" type. If you look back to the last big Python-Dev discussion on bytes/unicode and stdlib API breakage, this was the holdup for getting a sane WSGI spec. Since we couldn't change the language to fix the problem (due to the moratorium), we had to use this less-pleasant way of dealing with things, in order to get a final WSGI spec for Python 3. (If anybody is wondering about the specifics of the language change that was needed, it'd be having a "bytes with known encoding" type, that when combined in any polymorphic operation with a unicode string, would result in bytes-with-encoding output, and would raise an error if the resulting value could not be encoded in the target encoding. Then we would simply do all WSGI header operations with this type, using latin-1 as the target encoding.) ___ 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] r87816 - peps/trunk/pep-3333.txt
On Fri, 7 Jan 2011 16:45:26 +0100 (CET) phillip.eby wrote: > Author: phillip.eby > Date: Fri Jan 7 16:45:26 2011 > New Revision: 87816 > > Log: > Fix re-raise syntax for Python 3 > > > Modified: >peps/trunk/pep-.txt > > Modified: peps/trunk/pep-.txt > == > --- peps/trunk/pep-.txt (original) > +++ peps/trunk/pep-.txt Fri Jan 7 16:45:26 2011 > @@ -323,7 +323,7 @@ > try: > if headers_sent: > # Re-raise original exception if headers sent > -raise exc_info[0], exc_info[1], exc_info[2] > +raise exc_info[1].with_traceback(exc_info[2]) You shouldn't need that. Just "raise exc_info[1]". Regards Antoine. ___ 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] [Python-checkins] r87815 - peps/trunk/pep-3333.txt
Le vendredi 07 janvier 2011 à 16:39 +0100, phillip.eby a écrit :
> Author: phillip.eby
> Date: Fri Jan 7 16:39:27 2011
> New Revision: 87815
>
> Log:
> More bytes I/O fixes
>
>
> Modified:
>peps/trunk/pep-.txt
>
> Modified: peps/trunk/pep-.txt
> ==
> --- peps/trunk/pep-.txt (original)
> +++ peps/trunk/pep-.txt Fri Jan 7 16:39:27 2011
> @@ -310,9 +310,9 @@
> elif not headers_sent:
> # Before the first output, send the stored headers
> status, response_headers = headers_sent[:] = headers_set
> - sys.stdout.write('Status: %s\r\n' % status)
> + sys.stdout.buffer.write('Status: %s\r\n' % status)
> for header in response_headers:
> - sys.stdout.write('%s: %s\r\n' % header)
> + sys.stdout.buffer.write('%s: %s\r\n' % header)
> sys.stdout.write('\r\n')
Are ('Status: %s\r\n' % status) and ('%s: %s\r\n' % header) byte strings
or unicode strings?
Victor
___
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] Checking input range in time.asctime and time.ctime
I think I've said all I can say in this thread; I'm sure you will come up with a satisfactory solution. -- --Guido van Rossum (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] PEP 3333: wsgi_string() function
On Jan 7, 2011, at 6:51 AM, Victor Stinner wrote: > I don't understand why you are attached to this horrible hack > (bytes-in-unicode). It introduces more work and more confusing than > using raw bytes unchanged. > > It doesn't work and so something has to be changed. It's gross but it does work. This has been discussed ad-nausium on web-sig over a period of years. I'd like to reiterate that it is only even a potential issue for the PATH_INFO/SCRIPT_NAME keys. Those two keys are required to have been urldecoded already, into byte-data in some encoding. For all the other keys (including the ones from os.environ), they are either *properly* decoded in 8859-1 or are just ascii (possibly still urlencoded, so the app needs to urldecode and decode into a string with the correct encoding). James ___ 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] PEP 3333: wsgi_string() function
On Fri, Jan 7, 2011 at 9:51 PM, Victor Stinner wrote: > On POSIX, the current code looks like that: > > a) the OS pass a bytes environ to the program > b) Python decodes environ from the locale encoding > c) wsgi.read_environ() encodes environ to the locale encoding to get > back the original bytes environ: this step can be skipped if os.environb > is available > d) wsgi.read_environ() decodes environ from ISO-8859-1 > e) the server/gateway encodes environ to ISO-8859-1 > f) the server/gateway decodes environ from the right encoding > > Hey! Don't you think that there are useless encode/decode steps here? > Especially (d)-(e) is useless and introduces a confusion: the environ > contains other keys that don't come from os.environ and are already > correctly decoded, how do the the server/gateway know that they are > already correctly decoded? Because WSGI is platform neutral. WSGI apps have no idea if they're running on Windows or POSIX. The type used to communicate between the WSGI engine and the WSGI must be either bytes *or* unicode, and either choice causes problems depending on the underlying OS. bytes-as-unicode is not a great choice, it is merely the least bad choice of the available options. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PEP 3333: wsgi_string() function
Victor Stinner writes: > It doesn't work and so something has to be changed. What specific bug have you observed? Everybody hates this hack, or at the very least is somewhat embarrassed by it, but the working group clearly believes that it works and something like it is necessary. They've studied it for years. To get rid of it, "somebody" needs to demonstrate a bug, and propose something better, plus implement it in code, plus fix any tests that expect Unicode and now get bytes, plus create any additional tests that may be necessitated by changing from a Unicode representation to a bytes representation. I hate it too, but not enough to to ask anybody to do any of the above without a real bug. ___ 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] PEP 3333: wsgi_string() function
Le jeudi 06 janvier 2011 à 23:50 +, And Clover a écrit : > On Tue, 2011-01-04 at 03:44 +0100, Victor Stinner wrote: > > What is this horrible encoding "bytes-as-unicode"? > > It is a unicode string decoded from bytes using ISO-8859-1. ISO-8859-1 > is the encoding specified by the HTTP RFC, as well as having the happy > property of preserving every input byte. PEP requires it. ISO-8859-1 for all fields: SERVER_NAME, PATH_INFO, the URL, form data, ...? > > os.environ is supposed to be correctly decoded and contain valid > unicode characters. > > It is not possible to ‘correctly’ decode to unicode for os.environ > because that decoding happens long before the web application (the > only party that knows what encoding should be in use) gets a look in. Agreed. > Maybe the web application is using UTF-8, maybe it's using cp1252, > but if we let the server/gateway decide and do that decoding (...) > It's an absolutely necessary idea. The locale encoding is nothing > to do with the web application's encoding. (...) Ok, so you must pass byte strings to the server/gateway. If you pass unicode, how do the server/gateway know that it has to redecode a value? Should it redecode all values? Anything, it is stupid to use a temporary useless pseudo-encoding (bytes-in-unicode). > The recoding dances present in wsgiref's CGIHandler for 3.2 are > distasteful but completely necessary to normalise differences in > encodings used by various servers and platforms to generate their CGI > environment. I don't understand why read_environ() gives unicode values: as you explained, the server/gateway will have to encode the values again, and then finally to decode them from the correct encoding. On POSIX, the current code looks like that: a) the OS pass a bytes environ to the program b) Python decodes environ from the locale encoding c) wsgi.read_environ() encodes environ to the locale encoding to get back the original bytes environ: this step can be skipped if os.environb is available d) wsgi.read_environ() decodes environ from ISO-8859-1 e) the server/gateway encodes environ to ISO-8859-1 f) the server/gateway decodes environ from the right encoding Hey! Don't you think that there are useless encode/decode steps here? Especially (d)-(e) is useless and introduces a confusion: the environ contains other keys that don't come from os.environ and are already correctly decoded, how do the the server/gateway know that they are already correctly decoded? I propose simply (for Python 3.2): a) the OS pass a bytes environ to the program: wsgi.read_environ() uses it b) the server/gateway decodes environ from the right encoding and... > (a) os.environb doesn't exist in previous Python 3.1, making it > impossible to implement WSGI before 3.2; For Python 3.1, add a step between (a) and (b): encode environ to the locale encoding (with surrogateescape) to get back the original bytes environ. > (b) a byte environment on Windows would have to be encoded > from the Unicode environment, with a server-specific encoding, > and then what encoding are you going to choose for the variables > that contain non-HTTP-sourced native Unicode strings (such as, > very commonly, Windows pathnames)? The variables coming from the HTTP server should be encoded again to the server-specific encoding. Other variables should be kept unchanged. The server/gateway can simply test the type of the variable: if it's uncode, nothing to do, if it's bytes: decode it from the correct encoding. > The bytes-or-bytes-in-Unicode argument is something that has been > bounced around Web-SIG for literally *years*; (...) WSGI and wsgiref > in Python 3.0-3.1 simply does not work. I don't understand why you are attached to this horrible hack (bytes-in-unicode). It introduces more work and more confusing than using raw bytes unchanged. It doesn't work and so something has to be changed. Victor ___ 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] PEP 3333: wsgi_string() function
On Tue, 2011-01-04 at 03:44 +0100, Victor Stinner wrote: > What is this horrible encoding "bytes-as-unicode"? It is a unicode string decoded from bytes using ISO-8859-1. ISO-8859-1 is the encoding specified by the HTTP RFC, as well as having the happy property of preserving every input byte. > os.environ is supposed to be correctly decoded and contain valid unicode > characters. Nope. It is not possible to ‘correctly’ decode to unicode for os.environ because that decoding happens long before the web application gets a look in. Maybe the web application is using UTF-8, maybe it's using cp1252, but if we let the server/gateway decide and do that decoding before the application can do anything about it, we will get the wrong encoding in *many* cases and the result will be permanent, unrecoverable mangling of non-ASCII characters in submitted headers. > If WSGI uses another encoding than the locale encoding (which is a bad idea), It's an absolutely necessary idea. The locale encoding is nothing to do with the web application's encoding. Windows applications need to be able to use UTF-8 (which is never the ANSI code page), and web applications in general need to be deployable to any server without having to worry about the server's locale. The locale-dependent status quo is that non-ASCII characters in URL paths and other HTTP headers don't work for Python apps. The recoding dances present in wsgiref's CGIHandler for 3.2 are distasteful but completely necessary to normalise differences in encodings used by various servers and platforms to generate their CGI environment. > it should use os.environb and decodes keys and values using its > own encoding. Well yes, but: (a) os.environb doesn't exist in previous Python 3.1, making it impossible to implement WSGI before 3.2; (b) there are also non-HTTP-related environment variables, which may contain native Unicode strings (eg, very commonly, Windows pathnames), so you have to have both environ *and* environb. The bytes-or-bytes-in-Unicode argument is something that has been bounced around Web-SIG for literally *years*; this is what we ended up with. Although I personally like bytes, frankly, a re-run of this argument *again* whilst WSGI remains in perpetual stalemate does not appeal. WSGI and wsgiref in Python 3.0-3.1 simply not work at all. This has been an embarrassing situation for what is supposed to be a leading web language. Let's not perpetuate this sorry story to 3.2 as well. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com skype:uknrbobince gtalk:chat?jid=bobi...@gmail.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] 3.2b2 fails test suite on (my) Windows XP
On 1/6/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Jan 6, 2011 at 4:00 PM, Terry Reedy wrote:
Does it behave itself if you add "-x test_capi" to the command line?
No, it gets worse. Really.
Let me summarize a long post.
Run 1: normal (as above)
Process stops at capi test with Windows error message.
Close command prompt window with [x] buttom (crtl-whatever had no effect).
Run 2: normal (as before)
Process reported capi test failure (supposedly fatal) but continued.
Process just stopped ('hung') at concurrent futures. Close as before.
Run 3: -x test_capi test_concurrent_futures
Instead of the normal output I expected, I got some of the craziest stuff I
have ever seen. Things like
Does it all go back to normal if you use "python -m test.regrtest"
instead? Antoine discovered that multiprocessing on Windows gets
thoroughly confused if __file__ in the main module ends with
"__main__.py" (see http://bugs.python.org/issue10845)
Yes. As I reported on the issue, only 'normal' test failure output.
Later, I will try to see if there are already issues for all of them.
--
Terry Jan Reedy
___
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
