Re: [Python-Dev] debug and release python
I.e. even with the change, it would *still* depend on objimpl.h (and other) settings what ABI this debug DLL exactly has. I think it does. My proposal was perhaps not clear: For existing python versions, always export _PyObject_DebugMalloc et al. Hmm. That's still not clear. What are "existing Python versions"? You can't change them anymore; any change can only affect future, as-of-yet-non-existing Python versions. Also, what do you mean by "always"? Even in release builds? Would this really help? You shouldn't be mixing PyObject_DebugMalloc and PyObject_Malloc in a single process. On new python versions, remove the _PyObject_DebugMalloc from the ABI. Make the switch internal to obmalloc.c, so that you can turn on the debug library by recompiling pythonxx_d.dll only (currently, you have to recompile the .pyd files too!) That sounds fine. But there are tons of ABI changes that may happen in a debug build. If you want to cope with all of them, you really need to recompile the source of all extensions. Are there? Can you give me an example? If you define Py_TRACE_REFS, every object has two additional pointers, which aren't there if you don't. So extensions compiled with it are incompatible with extensions compiled without it. If you define COUNT_ALLOCS, every type object will have additional slots; again, you can't mix extensions that have a different setting here than the interpreter. Regards, Martin ___ Python-Dev mailing list [email protected] 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 16, 2010, at 08:48 PM, [email protected] wrote: >Well, it looks like I've stumbled onto the "other shoe" on this >issue--that the email package's problems are also apparently >behind the fact that CGI binary file uploads don't work in 3.1 >(http://bugs.python.org/issue4953). Yikes. > >I trust that people realize this is a show-stopper for broader >Python 3.X adoption. 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. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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
Nick Coghlan wrote: > My personal perspective is that a lot of that code was likely already > broken in hard to detect ways when dealing with mixed encodings - > releasing 3.x just made the associated errors significantly easier to > detect. I have to agree with this, and not just about encodings. I think much of the stdlib code dealing with all aspects of HTTP (urllib and the http package which now includes cgi) is kind of shaky. And it affects (infects) other parts of the stdlib, too; sockets are hacked to support the read-after-close paradigm that httplib uses, for instance. Which means that SSL and other socket-using code also has to support it, etc. Some of this was cleaned up in the move to 3.x, but more work needs to be done. Cudos to the folks working on httplib2 (http://code.google.com/p/httplib2/) and WSGI. There's a related meta-issue having to do with antique protocols. FTP, for instance, was designed when the Internet had only 19 nodes connected together with custom-built refrigerator-sized routers. A very early experiment in application protocols. It does a few odd things that we've since learned to be inefficient/unwise/unnecessary. Does it make sense that Python support every part of it? On the other hand, it was fairly static when the Python support was added (unlike HTTP, which was under very active development!) so that module is pretty robust. Bill ___ Python-Dev mailing list [email protected] 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 Thu, Jun 17, 2010 at 08:43, Barry Warsaw wrote: > On Jun 16, 2010, at 08:48 PM, [email protected] wrote: > >>Well, it looks like I've stumbled onto the "other shoe" on this >>issue--that the email package's problems are also apparently >>behind the fact that CGI binary file uploads don't work in 3.1 >>(http://bugs.python.org/issue4953). Yikes. >> >>I trust that people realize this is a show-stopper for broader >>Python 3.X adoption. > > 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. And in general I think this is the reason some modules have not transitioned as well as others: there are only so many of us. The stdlib passes its test suite, but obviously some unit tests do not cover enough of the code in the ways people need it covered. As for using Python 3 for my code, I do and have since Python 3 became more-or-less usable. I just happen to not work with internet-related stuff in my day-to-day work. Plus we have needed to maintain FOUR branches for a while. That is a nasty time sink when you are having to port bug fixes and such. It also means that python-dev has been focused on making sure Python 2.7 is a solid release instead of getting to focus on the stdlib in Python 3. This a nasty chicken-and-egg issue; we could ignore Python 2 and focus on Python 3, but then the community would complain about us not supporting the transition from 2 to 3 better, but obviously focusing on 2 has led to 3 not getting enough TLC. Once Python 2.7 is done and out the door the entire situation for Python 3 should start to improve as python-dev as whole will have a chance to begin to focus solely on Python 3. ___ Python-Dev mailing list [email protected] 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/17 Bill Janssen : > There's a related meta-issue having to do with antique protocols. Can I know what meta-issue are you talking about exactly? > FTP, for instance, was designed when the Internet had only 19 nodes connected > together with custom-built refrigerator-sized routers. A very early > experiment in application protocols. It does a few odd things that > we've since learned to be inefficient/unwise/unnecessary. Does it make > sense that Python support every part of it? Being FTP protocol still quite widespread I'd say it makes a lot of sense. That aside, what parts of urllib/http* are penalized because of FTP support? --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil ___ Python-Dev mailing list [email protected] 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
Barry Warsaw wrote: > On Jun 16, 2010, at 08:48 PM, [email protected] wrote: > >> Well, it looks like I've stumbled onto the "other shoe" on this >> issue--that the email package's problems are also apparently >> behind the fact that CGI binary file uploads don't work in 3.1 >> (http://bugs.python.org/issue4953). Yikes. >> >> I trust that people realize this is a show-stopper for broader >> Python 3.X adoption. > > 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. > > -Barry > 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). regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.com/ "All I want for my birthday is another birthday" - Ian Dury, 1942-2000 ___ Python-Dev mailing list [email protected] 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
David and his Google Summer of Code student, Shashwat Anand. You can read Shashwat's weekly progress updates at http://l0nwlf.in/ or subscribe to http://twitter.com/l0nwlf for more micro updates. We have more than 30 paid students working on Python 3 tasks this year, most of them participating under the PSF umbrella but also a few with 3rd party projects such as Mercurial porting those various packages to Py3. Given all this "on the horizon" work, I think the Py3 package situation will look a lot brighter by Python 3.2's release. On Thu, Jun 17, 2010 at 10:32 PM, Steve Holden wrote: > > 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. > ___ Python-Dev mailing list [email protected] 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
[email protected] 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
