Re: [Python-Dev] email package status in 3.X
l...@rmi.net writes: FWIW, after rewriting Programming Python for 3.1, 3.x still feels a lot like a beta to me, almost 2 years after its release. Email, of course, is a big wart. But guess what? Python 2's email module doesn't actually work! Sure, the program runs most of the time, but every program that depends on email must acquire inches of armorplate against all the things that can go wrong. You simply can't rely on it to DTRT except in a pre-MIME, pre-HTML, ASCII-only world. Although they're often addressing general problems, these hacks are *not* integrated back into the email module in most cases, but remain app-specific voodoo. If you live in Kansas, sure, you can concentrate on dodging tornados and completely forget about Unicode and MIME and text/bogus content. For the rest of the world, though, the problem is not Python 3. It's STD 11 (which still points at RFC 822, dated 1982!) It's really inappropriate to point at the email module, whose developers are trying *not* to punt on conformance and robustness, when even the IETF can only run in circles, scream and shout! Maybe there are other problems with Python 3 that deserve to be pointed at, but given the general scarcity of resources I think the email module developers are working on the right things. Unlike many other modules, email really needs to be rewritten from the ground (Python 3) up, because of the centrality of bytes/unicode confusion to all email problems. Python 3 completely changes the assumptions there; a Python 2-style email module really can't work properly. Then on top of that, today we know a lot more about handling issues like text/html content and MIME in general than when the Python 2 email module was designed. New problems have arisen over the period of Python 3 development, like domain keys, which email doesn't handle out of the box AFAIK, but email for Python 3 should IMHO. Should Python 3 have been held back until email was fixed? Dunno, but I personally am very glad it was not; where I have a choice, I always use Python 3 now, and have yet to run into a problem. I expect that to change if I can find the time to get involved in email and Mailman 3 development, of course.wink ___ 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] Python Library Support in 3.x (Was: email package status in 3.X)
Steve Holden Wrote: We are also attempting to enable tax-deductible fund raising to increase the likelihood of David's finding support. Perhaps we need to think about a broader campaign to increase the quality of the python 3 libraries. I find it very annoying that the #python IRC group still has Don't use Python 3 in it's topic. They adamantly refuse to remove it until there is better library support, and they are the guys who see the issues day in day out so it is hard to argue with them (and I don't think an autocratic decision-making process would be appropriate). Yes, #python keeps the text It's too early to use Python 3.x in its topic. Library support is the only reason. -- Regards, Stephen Thorne Development Engineer ___ 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 Library Support in 3.x (Was: email package status in 3.X)
On Fri, Jun 18, 2010 at 8:07 AM, Stephen Thorne step...@thorne.id.au wrote: We are also attempting to enable tax-deductible fund raising to increase the likelihood of David's finding support. Perhaps we need to think about a broader campaign to increase the quality of the python 3 libraries. I find it very annoying that the #python IRC group still has Don't use Python 3 in it's topic. They adamantly refuse to remove it until there is better library support, and they are the guys who see the issues day in day out so it is hard to argue with them (and I don't think an autocratic decision-making process would be appropriate). Yes, #python keeps the text It's too early to use Python 3.x in its topic. Library support is the only reason. I do not know what are you intending to do, but my opinion that fund raising for patching library is a waste of money. PSF should concentrate on enhancing tools to make lives of library supporters easier. I do not want to become a maintainer, and I believe there was a lot of spam about this topic from me. The latest thread was in http://bugs.python.org/issue9008 in short: `pydotorg` tools - theres is no: 1. separate commit notifications for the module with ability to reply to dedicated group for review 2. separate bug tracker category for my module with giving users ability to change every property of it 3. bug tracker timeline for the module that includes ticket changes, wiki edits, commits and everything else. Filtered. 4. roadmap page with actual status, plans and coverage 5. dashboard page with links to all the above `python development tools`: 1. no way to get all related code for the module 1.1. source code location (repository, branches) 1.2. source code components (source file, tests, documentation) 2. no code coverage (test/user story/rfc/pep) 3. no convenient way to run module-related tests http://bugs.python.org/issue9027 4. no code review management process 5. no way to notify interested parties -- 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] Python Library Support in 3.x (Was: email package status in 3.X)
On Fri, 18 Jun 2010 11:19:37 pm Jesse Noller wrote: Awesome. I plan on wasting as much money on the useless effort of moving python 3 forward as humanly possible. I'm sorry, but if that's sarcasm, it's far too subtle for me :( -- Steven D'Aprano ___ 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 Library Support in 3.x (Was: email package status in 3.X)
On Fri, Jun 18, 2010 at 07:44, anatoly techtonik techto...@gmail.comwrote: On Fri, Jun 18, 2010 at 8:07 AM, Stephen Thorne step...@thorne.id.au wrote: We are also attempting to enable tax-deductible fund raising to increase the likelihood of David's finding support. Perhaps we need to think about a broader campaign to increase the quality of the python 3 libraries. I find it very annoying that the #python IRC group still has Don't use Python 3 in it's topic. They adamantly refuse to remove it until there is better library support, and they are the guys who see the issues day in day out so it is hard to argue with them (and I don't think an autocratic decision-making process would be appropriate). Yes, #python keeps the text It's too early to use Python 3.x in its topic. Library support is the only reason. I do not know what are you intending to do, but my opinion that fund raising for patching library is a waste of money. PSF should concentrate on enhancing tools to make lives of library supporters easier. I do not want to become a maintainer, and I believe there was a lot of spam about this topic from me. The latest thread was in http://bugs.python.org/issue9008 in short: `pydotorg` tools - theres is no: 1. separate commit notifications for the module with ability to reply to dedicated group for review If you know how to set this up, feel free to implement it. 2. separate bug tracker category for my module with giving users ability to change every property of it The Python bug tracker isn't the place for my module. The second part of this sentence has been brought up and I think it's a good point. For example, those who lack developer privileges can't assign issues to themselves. I think Twisted's tracker does well in this area, as the fields are inclusive rather than exclusive. Assignment is open to anyone willing to work on it, and the field is used to prod the next responsible person into acting (I think, correct me if I'm wrong). 3. bug tracker timeline for the module that includes ticket changes, wiki edits, commits and everything else. Filtered. That seems like information overload. It might be cool to see all of that, but I'm not sure what the gain is. Some modules get worked on in spurts and sometimes modules don't see action for months. It doesn't actually mean anything, though. 4. roadmap page with actual status, plans and coverage 5. dashboard page with links to all the above If you know how to do this, you are more than welcome to whip up some code and show how it would help. `python development tools`: 1. no way to get all related code for the module 1.1. source code location (repository, branches) 1.2. source code components (source file, tests, documentation) What exactly do you mean? Since you have submitted several issues, some with patches, I have a hard time believing that you've done all of that work without knowing where any of that information was. 2. no code coverage (test/user story/rfc/pep) If you know of a way to incorporate code coverage tools and metrics into the current process, I believe a number of people would be interested. There currently exists some coverage tool that runs on the current repository, but I'm not sure of its location or status. 4. no code review management process I agree, this is an area that could use work. It has been suggested that Rietveld be incorporated into Roundup both visually (upload to Rietveld button) and as a part of the workflow (possible requirement before commit). As with many of these comments, lack of time and a lack of available volunteers are two of many answers as to why there is no traction on this. 5. no way to notify interested parties I'm not sure what this is specifically addressing. 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] email package status in 3.X
Replying en masse to save bandwidth here... Barry Warsaw ba...@python.org writes: We know it, we have extensively discussed how to fix it, we have IMO a good design, and we even have someone willing and able to tackle the problem. We need to find a sufficient source of funding to enable him to do the work it will take, and so far that's been the biggest stumbling block. It will take a focused and determined effort to see this through, and it's obvious that volunteers cannot make it happen. I include myself in the latter category, as I've tried and failed at least twice to do it in my spare time. All understood, and again, not to disparage anyone here. My comments are directed to the development community at large to underscore the grave p/r problems 3.X faces. I realize email parsing is a known issue; I also realize that most people evaluating 3.X today won't care that it is. Most will care only that the new version of a language reportedly used by Google and YouTube still doesn't support CGI uploads a year and a half after its release. As an author, that's a downright horrible story to have to tell the world. Stephen J. Turnbull step...@xemacs.org writes: Email, of course, is a big wart. But guess what? Python 2's email module doesn't actually work! Yes it does (see next point). If you live in Kansas, sure, you can concentrate on dodging tornados and completely forget about Unicode and MIME and text/bogus content. For the rest of the world, though, the problem is not Python 3 Yes it is, and Kansas is a lot bigger than you seem to think. I want to reiterate that I was able to build a feature rich email client with the email package as it exists in 3.1. This includes support on both the receiving and sending sides for HTML, arbitrary attachments, and decoding and encoding of both text payloads and headers according to email, MIME, and Unicode/I18N standards. It's an amazingly useful package, and does work as is in 3.X. The two main issues I found have been recently fixed. It's unfortunate that this package is also the culprit behind CGI breakage, but it's not clear why it became a critical path for so much utility in the first place. The package might not be aesthetically ideal, but to me it seems that an utterly incompatible overhaul of this in the name of supporting potentially very different data streams is a huge functional overload. And to those people in Kansas who live outside the pydev clique, replacing it with something different at this point will look as if an incompatible Python is already incompatible with releases in its own line. Why in the world would anyone base a new project on that sort of thrashing? For my part, I've had to add far too many notes to the upcoming edition of Programming Python about major pieces of functionality that worked in 2.X but no longer do in 3.X. That's disappointing to me personally, but it will probably seem a lot worse to the book's tens of thousands of readers. Yet this is the reality that 3.X has created for itself. Should Python 3 have been held back until email was fixed? Dunno, but I personally am very glad it was not; where I have a choice, I always use Python 3 now, and have yet to run into a problem. I guess we'll just have to disagree on that. IMHO, Python 3 shot itself in the foot by releasing in half-baked form. And the 3.0 I/O speed issue (remember that?) came very close to blowing its leg clean off. The reality out there in Kansas today is that 3.X is perceived as so bad that it could very well go the way of POP4 if its story does not improve. I don't know what sort of Python world will be left behind in the wake, but I do know it will probably be much smaller. Steve Holden st...@holdenweb.com writes: Lest the readership think that the PSF is unaware of this issue, allow me to point out that we have already partially funded this effort, and are still offering R. David Murray some further matching funds if he can raise sponsorship to complete the effort (on which he has made a very promising start). We are also attempting to enable tax-deductible fund raising to increase the likelihood of David's finding support. Perhaps we need to think about a broader campaign to increase the quality of the python 3 libraries. I find it very annoying that the #python IRC group still has Don't use Python 3 in it's topic. They adamantly refuse to remove it until there is better library support, and they are the guys who see the issues day in day out so it is hard to argue with them (and I don't think an autocratic decision-making process would be appropriate). I'm all for people getting paid for work they do, but with all due respect, I think this underscores part of the problem in the Python world today. If funding had been as stringent a prerequisite in the 90s, I doubt there would be a Python today. It was about the fun and the code, not the bucks and the bureaucracy. As
Re: [Python-Dev] email package status in 3.X
On 18/06/2010 16:09, l...@rmi.net wrote: Replying en masse to save bandwidth here... Barry Warsawba...@python.org writes: We know it, we have extensively discussed how to fix it, we have IMO a good design, and we even have someone willing and able to tackle the problem. We need to find a sufficient source of funding to enable him to do the work it will take, and so far that's been the biggest stumbling block. It will take a focused and determined effort to see this through, and it's obvious that volunteers cannot make it happen. I include myself in the latter category, as I've tried and failed at least twice to do it in my spare time. All understood, and again, not to disparage anyone here. My comments are directed to the development community at large to underscore the grave p/r problems 3.X faces. I realize email parsing is a known issue; I also realize that most people evaluating 3.X today won't care that it is. Most will care only that the new version of a language reportedly used by Google and YouTube still doesn't support CGI uploads a year and a half after its release. As an author, that's a downright horrible story to have to tell the world. Really? How widely used is the CGI module these days? Maybe there is a reason nobody appeared to notice... [snip...] Should Python 3 have been held back until email was fixed? Dunno, but I personally am very glad it was not; where I have a choice, I always use Python 3 now, and have yet to run into a problem. I guess we'll just have to disagree on that. IMHO, Python 3 shot itself in the foot by releasing in half-baked form. And the 3.0 I/O speed issue (remember that?) came very close to blowing its leg clean off. Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think half-baked is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*? Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release. Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment... All the best, Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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-06-11 - 2010-06-18) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2777 open (+43) / 18070 closed (+12) / 20847 total (+55) Open issues with patches: 1122 Average duration of open issues: 713 days. Median duration of open issues: 503 days. Open Issues Breakdown open 2747 (+43) languishing13 ( +0) pending16 ( +0) Issues Created Or Reopened (64) ___ New SSL module doesn't seem to verify hostname against commonN 2010-06-15 http://bugs.python.org/issue1589reopened pitrou struct allows repeat spec. without a format specifier 2010-06-12 CLOSED http://bugs.python.org/issue3129reopened belopolsky patch datetime lacks concrete tzinfo implementation for UTC 2010-06-15 CLOSED http://bugs.python.org/issue5094reopened belopolsky patch datetime.strptime doesn't support %z format ? 2010-06-18 http://bugs.python.org/issue6641reopened belopolsky patch libffi update to 3.0.9 2010-06-12 http://bugs.python.org/issue8142reopened haypo patch, buildbot struct - please make sizes explicit2010-06-15 CLOSED http://bugs.python.org/issue8469reopened mark.dickinson patch test_distutils fails if srcdir != builddir 2010-06-15 http://bugs.python.org/issue8577reopened pitrou patch Expose sqlite3 connection inTransaction as read-only in_transa 2010-06-12 http://bugs.python.org/issue8845reopened haypo patch, easy Tkinter Litmus Test2010-06-11 CLOSED http://bugs.python.org/issue8971reopened merwok svnmerge errors in msgfmt.py 2010-06-11 http://bugs.python.org/issue8974created merwok patch Bug in cookiejar 2010-06-11 http://bugs.python.org/issue8975created Popa.Claudiu subprocess module causes segmentation fault2010-06-11 http://bugs.python.org/issue8976created Chris.Blazick Globalize lonely augmented assignment 2010-06-11 CLOSED http://bugs.python.org/issue8977created serprex patch tarfile.ReadError: file could not be opened successfully if 2010-06-11 http://bugs.python.org/issue8978created flox OptParse __getitem__ 2010-06-12 CLOSED http://bugs.python.org/issue8979created bcward distutils.tests.test_register.RegisterTestCase.test_strict fai 2010-06-12 http://bugs.python.org/issue8980created Arfrever patch _struct.__version__ should be string, not bytes2010-06-12 CLOSED http://bugs.python.org/issue8981created belopolsky easy argparse docs cross reference Namespace as a class but the Nam 2010-06-12 http://bugs.python.org/issue8982created r.david.murray Docstrings should refer to
Re: [Python-Dev] Python Library Support in 3.x (Was: email package status in 3.X)
On 18.06.10 17:04, Brian Curtin wrote: [...] 2. no code coverage (test/user story/rfc/pep) If you know of a way to incorporate code coverage tools and metrics into the current process, I believe a number of people would be interested. There currently exists some coverage tool that runs on the current repository, but I'm not sure of its location or status. http://coverage.livinglogic.de/ I haven't touched the code in a year, but the job's still running. [...] Servus, Walter ___ 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] email package status in 3.X
Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release. Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment... Declaring something to be a turd doesn't change the fact that it's a turd. I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether. Let's be honest here; 3.X was released to the community in part as an extended beta. That's not a problem, unless you drop the word beta. And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as experimental, and promised a phase of disappointment. Why would you expect the Python world to react any differently? Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think half-baked is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*? I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind. So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) ___ 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] email package status in 3.X
On 18/06/2010 18:22, l...@rmi.net wrote: Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release. Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment... Declaring something to be a turd doesn't change the fact that it's a turd. Right - but *you're* the one calling it a turd, which is not a helpful approach or likely to achieve *anything* useful. I still have no idea what you are actually suggesting. I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether. Let's be honest here; 3.X was released to the community in part as an extended beta. Correction - 3.0 was an experimental release. That is not true of 3.1 and future releases. All the best, Michael That's not a problem, unless you drop the word beta. And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as experimental, and promised a phase of disappointment. Why would you expect the Python world to react any differently? Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think half-baked is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*? I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind. So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] email package status in 3.X
Giampaolo Rodolà g.rod...@gmail.com wrote: 2010/6/17 Bill Janssen jans...@parc.com: There's a related meta-issue having to do with antique protocols. Can I know what meta-issue are you talking about exactly? Giampaolo, I believe that you and I have already discussed this on one of the FTP issues. 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] email package status in 3.X
2010/6/18 Bill Janssen jans...@parc.com: Giampaolo Rodolà g.rod...@gmail.com wrote: 2010/6/17 Bill Janssen jans...@parc.com: There's a related meta-issue having to do with antique protocols. Can I know what meta-issue are you talking about exactly? Giampaolo, I believe that you and I have already discussed this on one of the FTP issues. Bill I only remember a discussion in which I was against removing OOB data support from asyncore in order to support certain parts of the FTP protocol using it, but that's all. I don't see how urlib or any other stdlib module is supposed to be penalized by FTP protocol in any way. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ 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] email package status in 3.X
I wasn't calling Python 3 a turd. I was trying to show the strangeness of the logic behind your rationalization. And failing badly... (maybe I should have used tar ball?) What I'm suggesting is that extreme caution be exercised from this point forward with all things 3.X-related. Whether you wish to accept this or not, 3.X has a negative image to many. This suggestion specifically includes not abandoning current 3.X email package users as a case in point. Ripping the rug out from new 3.X users after they took the time to port seems like it may be just enough to tip the scales altogether. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) -Original Message- From: Michael Foord fuzzy...@voidspace.org.uk To: l...@rmi.net Subject: Re: [Python-Dev] email package status in 3.X Date: Fri, 18 Jun 2010 18:27:46 +0100 On 18/06/2010 18:22, l...@rmi.net wrote: Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release. Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment... Declaring something to be a turd doesn't change the fact that it's a turd. Right - but *you're* the one calling it a turd, which is not a helpful approach or likely to achieve *anything* useful. I still have no idea what you are actually suggesting. I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether. Let's be honest here; 3.X was released to the community in part as an extended beta. Correction - 3.0 was an experimental release. That is not true of 3.1 and future releases. All the best, Michael That's not a problem, unless you drop the word beta. And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as experimental, and promised a phase of disappointment. Why would you expect the Python world to react any differently? Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think half-baked is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*? I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind. So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] email package status in 3.X
At 05:22 PM 6/18/2010 +, l...@rmi.net wrote: So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL parsing, joining, opening, etc. To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all. IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, that way may not be obvious at first unless you're Dutch. ;-) Since at the moment Python 3 offers me only cosmetic improvements over 2.x (apart from argument annotations), it's hard to get excited enough about it to want to muck about with porting anything to it, or even trying to learn about all the ramifications of the changes. :-( ___ 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 Library Support in 3.x (Was: email package status in 3.X)
On 6/18/2010 12:32 PM, Walter Dörwald wrote: http://coverage.livinglogic.de/ I am a bit puzzled as to the meaning of the gray/red/green bars since the correlation between coverage % and bars is not very high. ___ 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] email package status in 3.X
On Fri, Jun 18, 2010 at 4:48 PM, P.J. Eby p...@telecommunity.com wrote: At 05:22 PM 6/18/2010 +, l...@rmi.net wrote: So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? Certainly, this was my impression as well, after all the Web-SIG discussions regarding the state of the stdlib in 3.x with respect to URL parsing, joining, opening, etc. Nothing is set in stone; if something is incredibly painful, or worse yet broken, then someone needs to file a bug, bring it to this list, or bring up a patch. This is code we're talking about - nothing is set in stone, and if something is criminally broken it needs to be first identified, and then fixed. To be honest, I'm waiting to see some sort of tutorial(s) for using 3.x that actually addresses these kinds of stdlib usage issues, so that I don't have to think about it or futz around with experimenting, possibly to find that some things can't be done at all. I guess tutorial welcome, rather than patch welcome then ;) IOW, 3.x has broken TOOOWTDI for me in some areas. There may be obvious ways to do it, but, as per the Zen of Python, that way may not be obvious at first unless you're Dutch. ;-) What areas. We need specifics which can either be: 1 Shot down. 2 Turned into bugs, so they can be fixed 3 Documented in the core documentation. jesse ___ 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 Library Support in 3.x (Was: email package status in 3.X)
On Fri, Jun 18, 2010 at 13:53, Terry Reedy tjre...@udel.edu wrote: On 6/18/2010 12:32 PM, Walter Dörwald wrote: http://coverage.livinglogic.de/ I am a bit puzzled as to the meaning of the gray/red/green bars since the correlation between coverage % and bars is not very high. Gray is lines that are unexecutable (comments, etc.), green are lines that were executed, and red is lines not executed. ___ 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] email package status in 3.X
On 18/06/2010 19:52, l...@rmi.net wrote: I wasn't calling Python 3 a turd. I was trying to show the strangeness of the logic behind your rationalization. And failing badly... (maybe I should have used tar ball?) I didn't make myself clear. The expected disappointment I was referring to was about the rate of adoption, not about the quality of the product. I'm still baffled as to how a bug in the cgi module (along with the acknowledged email problems) is such a big deal. Was it reported and then languished in the bug tracker? That would be bad ion its own but if it was only recently discovered that indicates that it probably isn't such a big deal - either way it needs fixing, but using Python for writing cgis hasn't been a big use case for a long time. All the best, Michael What I'm suggesting is that extreme caution be exercised from this point forward with all things 3.X-related. Whether you wish to accept this or not, 3.X has a negative image to many. This suggestion specifically includes not abandoning current 3.X email package users as a case in point. Ripping the rug out from new 3.X users after they took the time to port seems like it may be just enough to tip the scales altogether. --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) -Original Message- From: Michael Foordfuzzy...@voidspace.org.uk To: l...@rmi.net Subject: Re: [Python-Dev] email package status in 3.X Date: Fri, 18 Jun 2010 18:27:46 +0100 On 18/06/2010 18:22, l...@rmi.net wrote: Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release. Any reasonable expectation about Python 3 adoption predicted that it would take years, and would include going through a phase of difficulty and disappointment... Declaring something to be a turd doesn't change the fact that it's a turd. Right - but *you're* the one calling it a turd, which is not a helpful approach or likely to achieve *anything* useful. I still have no idea what you are actually suggesting. I have a feeling that most people outside this list would have much rather avoided the difficulty and disappointment altogether. Let's be honest here; 3.X was released to the community in part as an extended beta. Correction - 3.0 was an experimental release. That is not true of 3.1 and future releases. All the best, Michael That's not a problem, unless you drop the word beta. And if you're still not buying that, imagine the sort of response you'd get if you tried to sell software that billed itself as experimental, and promised a phase of disappointment. Why would you expect the Python world to react any differently? Whilst I agree that there are plenty of issues to workon, and I don't underestimate the difficulty of some of them, I think half-baked is very much overblown. Whilst you have a lot to say about how much of a problem this is I don't understand what you are suggesting be *done*? I agree that 3.X isn't all bad, and I very much hope it succeeds. And no, I have no answers; I'm just reporting the perception from downwind. So here it is: The prevailing view is that 3.X developers hoisted things on users that they did not fully work through themselves. Unicode is prime among these: for all the talk here about how 2.X was broken in this regard, the implications of the 3.X string solution remain to be fully resolved in the 3.X standard library to this day. What is a common Python user to make of that? --Mark Lutz (http://learning-python.com, http://rmi.net/~lutz) -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further
Re: [Python-Dev] Python Library Support in 3.x (Was: email package status in 3.X)
On 6/18/2010 10:24 AM, Jesse Noller wrote: http://jessenoller.com/2010/05/20/announcing-python-sprint-sponsorship/ This does not specify what expenses you are thinking of covering. Food is the most obvious. Anyway, this got me to think about offering my house at a site for US east coast mid-atlantic sprints (near I95, halfway betweenn NY and WDC, FIOS internet, TV/Playstation/Netflix for breaks ;-). 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
Re: [Python-Dev] email package status in 3.X
Michael Foord: Python 3.0 was *declared* to be an experimental release, and by most standards 3.1 (in terms of the core language and functionality) was a solid release. That looks to me like an after-the-event rationalization. The release note for Python 3.0 (and the What's new) gives no indication that it is experimental but does say We are confident that Python 3.0 is of the same high quality as our previous releases ... you can safely choose either version (or both) to use in your projects. http://mail.python.org/pipermail/python-dev/2008-December/083824.html Neil ___ 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 Library Support in 3.x (Was: email package status in 3.X)
On Fri, Jun 18, 2010 at 6:08 PM, Terry Reedy tjre...@udel.edu wrote: On 6/18/2010 10:24 AM, Jesse Noller wrote: http://jessenoller.com/2010/05/20/announcing-python-sprint-sponsorship/ This does not specify what expenses you are thinking of covering. Food is the most obvious. Anyway, this got me to think about offering my house at a site for US east coast mid-atlantic sprints (near I95, halfway betweenn NY and WDC, FIOS internet, TV/Playstation/Netflix for breaks ;-). Terry Jan Reedy Yup, I'm putting the site together now - essentially what's covered is anything up to this amount - meaning, if you spend 200$ on room space, then this could go to that. Or 200$ in food for 20 people, etc. We'll have basic guidelines. jesse ___ 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] email package status in 3.X
On Jun 18, 2010, at 3:08 PM, Michael Foord wrote: I'm still baffled as to how a bug in the cgi module (along with the acknowledged email problems) is such a big deal. Was it reported and then languished in the bug tracker? That would be bad ion its own but if it was only recently discovered that indicates that it probably isn't such a big deal - either way it needs fixing, but using Python for writing cgis hasn't been a big use case for a long time. That's one possible explanation. Another possible explanation is the product isn't being heavily exercised for serious work and that it has yet to be shaken-out thoroughly. There has been a disappointing lack of bug reports across the board for 3.x. That doesn't mean that the bugs aren't there and that they won't be reported when adoption is heavier. In the cases of email, mime handling, cgi and whatnot, the important point is not whether a given technology is popular. The important part is that it hints at the kind of bytes/text issues that people are going to face and that we will need to help them address (i.e. such as blobs containing multiple encodings, a need to use byte oriented tools such as md5 in conjunction with text oriented applications, etc.) One other thought: In addition to not getting many 3.x specific bug reports, we don't seem to be getting many 3.x specific help questions (i.e. asking about dictviews or how to make a priority queue in a environment where many callable don't support ordering operations, etc.). Mark Lutz wrote What I'm suggesting is that extreme caution be exercised from this point forward with all things 3.X-related. Whether you wish to accept this or not, 3.X has a negative image to many. This suggestion specifically includes not abandoning current 3.X email package users as a case in point. Ripping the rug out from new 3.X users after they took the time to port seems like it may be just enough to tip the scales altogether. A couple other areas that need work (some of them are minor): * BeautifulSoup was left behind when SGML parsing was removed from the standard lib. * Shelves were crippled for Windows users when bsddb was ripped out. * Lists containing None for missing values are no longer sortable. * The basic heapq approach to making a priority queue not longer works well. Simply decorating with (priority_level, callable_or_object) fails with two tasks at the same priority if the callable or other objects aren't orderable. Raymond P.S. I do think it would be great if we could direct some attention to parts of 3.x that are really nice. Am hoping that this conversation doesn't drown in negativity. Instead, it should focus on what improvements are needed to win broader adoption. ___ 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] email package status in 3.X
On 18/06/2010 23:51, Raymond Hettinger wrote: On Jun 18, 2010, at 3:08 PM, Michael Foord wrote: I'm still baffled as to how a bug in the cgi module (along with the acknowledged email problems) is such a big deal. Was it reported and then languished in the bug tracker? That would be bad ion its own but if it was only recently discovered that indicates that it probably isn't such a big deal - either way it needs fixing, but using Python for writing cgis hasn't been a big use case for a long time. That's one possible explanation. Another possible explanation is the product isn't being heavily exercised for serious work and that it has yet to be shaken-out thoroughly. There has been a disappointing lack of bug reports across the board for 3.x. That doesn't mean that the bugs aren't there and that they won't be reported when adoption is heavier. Oh, I quite agree. I don't think it makes py3k a turd either. In the cases of email, mime handling, cgi and whatnot, the important point is not whether a given technology is popular. The important part is that it hints at the kind of bytes/text issues that people are going to face and that we will need to help them address (i.e. such as blobs containing multiple encodings, a need to use byte oriented tools such as md5 in conjunction with text oriented applications, etc.) One other thought: In addition to not getting many 3.x specific bug reports, we don't seem to be getting many 3.x specific help questions (i.e. asking about dictviews or how to make a priority queue in a environment where many callable don't support ordering operations, etc.). Most of the questions I've seen about Python 3 are from library authors doing porting rather than application developers. This is to be expected I guess. Mark Lutz wrote What I'm suggesting is that extreme caution be exercised from this point forward with all things 3.X-related. Whether you wish to accept this or not, 3.X has a negative image to many. This suggestion specifically includes not abandoning current 3.X email package users as a case in point. Ripping the rug out from new 3.X users after they took the time to port seems like it may be just enough to tip the scales altogether. A couple other areas that need work (some of them are minor): * BeautifulSoup was left behind when SGML parsing was removed from the standard lib. * Shelves were crippled for Windows users when bsddb was ripped out. * Lists containing None for missing values are no longer sortable. Yeah, this one can be a bugger. :-) * The basic heapq approach to making a priority queue not longer works well. Simply decorating with (priority_level, callable_or_object) fails with two tasks at the same priority if the callable or other objects aren't orderable. Raymond P.S. I do think it would be great if we could direct some attention to parts of 3.x that are really nice. Am hoping that this conversation doesn't drown in negativity. Instead, it should focus on what improvements are needed to win broader adoption. I definitely agree that our focus should be on fixing problems as we find them and working on increasing adoption. No argument from me. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] email package status in 3.X
On 6/18/2010 6:51 PM, Raymond Hettinger wrote: There has been a disappointing lack of bug reports across the board for 3.x. Here is one from this week involving the interaction of array and bytearray. It needs a comment from someone who can understand the C-API based patch, which is beyond me. http://bugs.python.org/issue8990 Another possible reason for the lack: 500 of the current 2800 open issues have NO comment (ie, message count = 1), some with patches. I just posted '500 tracker orphans; we need more reviewers' on python-list to encourage more participation. 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
