Re: [Python-Dev] PEP 361: Python 2.6/3.0 release schedule
Barry Warsaw wrote: Greetings from Pycon 2008! Neal Norwitz and I have worked out the schedule for Python 2.6 and 3.0, which will be released in lockstep. We will be following a monthly release schedule, with releases to occur on the first Wednesday of the month. We'll move to a 2 week schedule for the release candidates. Hey Barry, Thanks for putting this PEP together. This is really helpful. I didn't see discussion of PEP 3118 and it's features back-ported to Python 2.6. I've already back-ported the new buffer API as an addition to the old buffer protocol. In addition, I've planned to back-port the improvements to the struct module and the addition of the memoryview object (both in PEP 3118). If you have questions, we can talk tomorrow. Best regards, -Travis Oliphant ___ 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 361: Python 2.6/3.0 release schedule
-On [20080318 01:52], Barry Warsaw ([EMAIL PROTECTED]) wrote: This schedule gives everybody plenty of advanced notice, so you should be able to get your code in on time. In particular the memory related fixes over the last weeks, please. :) -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ To love someone deeply gives you strength. Being loved by someone deeply gives you courage... ___ 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] Installing Python 2.6 alpha1 on Windows XP
On 17/03/2008, Gregor Lingl [EMAIL PROTECTED] wrote: Another thought - do you have any copies of msvcr90.dll on your PATH? I don't think it'll make a difference, but if you do can you try renaming them? No I don't! Only in c:\Python26, in c:\Python30 and on c:\Python30\DLLs. Strange that there are two copies of msvcr90.dll in Python30. So I'll copy this beast also to C:\Python26\DLLs, and ... it works! I can import socket and I even can start IDLE from the Python2.6 Menu That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the side by side manifest installation stuff (or whatever it's called). Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise. Thanks for your advice. I'm not sure I did much more than get you to the point where you solved the problem for yourself, but I'm glad you've got things working :-) Do you have an idea if this is a 'bug' in the installer? I suspect it is - I've copied Martin for comment, but could you raise a bug in the tracker? Why the differences between 2.6 and 3000. I don't know, but that's what makes me think it's a bug (although I'm not entirely convinced that having 2 copies of the DLL, like 3.0 does, is the correct solution). Why two copies of that .dll in Python 30.0? I suspect it's a result of the msvcr90 side by side stuff. But beyond that, I don't know. I'm rather happy now :-) So am I. Glad things are working :-) 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] Change in priority fields
Guido van Rossum wrote: On Mon, Mar 17, 2008 at 11:49 PM, Barry Warsaw [EMAIL PROTECTED] wrote: We should not release the finals until there are no release blockers or criticals. Either the critical gets moved to high and ignored, or it gets moved to release blocker and gets fixed. Hm... This feels a bit like inflation of priorities to me; there would be lots of critical bugs and quite a few release blockers... The highest priority just pertains to the upcoming release which could be weeks in the future. I'd be more comfortable if there were 1-2 priorities above that, e.g. one higher for stuff that makes a buildbot go red (i.e. breaks a test) and two higher for stuff that affects most developers (e.g. stuff checked in that doesn't even build). It would be good if someone at the sprints could take the PEP 3 redraft I posted a few weeks back, update it with whatever you all come up with in relation to tracker management and check it in. (Attaching that draft here so people don't have to go trawling through email archives for it) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org PEP: 3 Title: Guidelines for Handling Tracker Issues Version: $Revision: 59412 $ Last-Modified: $Date: 2007-12-08 20:48:07 +1000 (Sat, 08 Dec 2007) $ Author: [EMAIL PROTECTED] (Jeremy Hylton), [EMAIL PROTECTED] (Nick Coghlan) Status: Active Type: Process Content-Type: text/x-rst Created: 25-Sep-2000 Post-History: 23-Feb-2008 Introduction This PEP contains guidelines for handling bug reports and feature requests for the Python project using the tracker at bugs.python.org [1]. These are guidelines for the developers of Python, not the submitters of bugs. Those are included as part of the documentation so they are available in the offline documentation as well as being available online [2]. Tracker Issues == All bug reports and feature requests are handled as issues in the tracker. Whether they are bugs or requests for new features is indicated by the type of issue. Title - This should be a short description of the problem or request. It is worth correcting it if the originator's title turns out to be misleading. Type This attribute describes the kind of issue being reported. It should be adjusted if the originator has not set it correctly. The possible issue types are: *feature request* the issue is not a bug, but a request for additional functionality *behavior* this covers most bugs (including all documentation bugs), where the behaviour is not desirable or not what the user expected *crash* a bug that causes the Python interpreter to crash (segfault/access violation/bus error) *resource usage* a bug that causes Python to handle limited resources (memory, file handles, etc) poorly *security* a bug that may allow the Python interpreter to be used to gain unauthorised access to information in memory or on the file system (either locally or remotely) (XXX: is public access to security bugs limited by default?) Severity This attribute allows the originator to indicate how important the issue is to them. It should not be adjusted (set the Priority instead). Components -- The originator and developers can use the components list to indicate which areas of Python or its development tools are affected by the issue. Eventually developers will be able to subscribe to the tracker so that it automatically adds them to the nosy list when issues are registered against components they are interested in. For discrepancies between the documentation and the actual behavior, the components list should be updated if the problem is determined to be an error in the documentation (and vice-versa if the issue was originally reported as a documentation problem, but it is later determined that the documentation accurately describes the desired behavior). Versions This field is primarily of importance for bug reports - it should indicate which versions of Python exhibit the problem. Problems which are seen in a development version should also be flagged appropriately (currently Python 2.6 for the trunk and Python 3.0 for the py3k branch). For feature requests this field is used to flag the target version for the feature (following a major version release, all open features should be bumped to target the next version). Status -- Open issues are still under consideration. Closed issues have been resolved, and the resolution field should indicate their final disposition. Pending issues are intended to be closed soon, but are being held open for a short period to allow time for some other event (e.g. additional details from the originator or a decision on whether or not a fix should be backported to the current maintenance branch). Resolution -- For closed and pending issues, indicates how
Re: [Python-Dev] Installing Python 2.6 alpha1 on Windows XP
Paul Moore schrieb: That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the side by side manifest installation stuff (or whatever it's called). Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise. In practice it's not enough on XP and higher. Starting with XP, Windows supports side by side assemblies (SxS). SxS assemblies must be installed following a special convention. The MSDN web site contains some examples. It suc.. err it's fun :/ We are still having problems to integrate the MS Merge module into our MSI. Martin is working on the problem. In the mean time you can work around the problem by installing the MSVCRT 9.0 Redist. Christian ___ 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] test_support.have_unicode
The test_support unit has this have_unicode. Do we need the Python's test unit to be *that* backward compatible? Is there still an implementation of Python that doesn't support unicode? If there is, should the test suite care? As a side question. Considering that I'm not sure whether have_unicode is relevant or not, is it more appropriate to create a ticket for it or to ask python-dev? 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] test_support.have_unicode
On Tue, Mar 18, 2008 at 8:18 AM, Virgil Dupras [EMAIL PROTECTED] wrote: The test_support unit has this have_unicode. Do we need the Python's test unit to be *that* backward compatible? Is there still an implementation of Python that doesn't support unicode? If there is, should the test suite care? Python 2.x can be compiled without Unicode. As a side question. Considering that I'm not sure whether have_unicode is relevant or not, is it more appropriate to create a ticket for it or to ask python-dev? 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/musiccomposition%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] Installing Python 2.6 alpha1 on Windows XP
That's odd. In theory, having msvcr90.dll in C:\Python26 should be sufficient, as once python.exe is loaded, its directory is added to the DLL search path. Maybe it's something to do with the side by side manifest installation stuff (or whatever it's called). Yes, with VS 2008, the DLL search path becomes irrelevant (or so it seems). Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise. I haven't figured it out myself; it's a complete mess, and Microsoft is heavily wasting our time. It seems that you absolutely *must* have the manifest file in each directory that has a DLL which links with the CRT. Whether or not separate copies of the DLL are then also necessary, and whether or not that causes two copies to be loaded into the address space, I don't know. HELP To reproduce the problem, you probably have to test on a machine which doesn't have the CRT redistributable installed centrally (neither through VS 2008 installation, nor by running the standalone CRT installer, nor by having installed any other software that provides an SxS copy of the CRT). Regards, Martin ___ 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] Change in priority fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 18, 2008, at 12:11 AM, Guido van Rossum wrote: Hm... This feels a bit like inflation of priorities to me; there would be lots of critical bugs and quite a few release blockers... The highest priority just pertains to the upcoming release which could be weeks in the future. I want a very simple roundup query that I can consult during the release cycle to know whether everything's fine, or whether I have to start pestering people and pull the big red STOP RELEASE button. Critical gives us a priority for things we really need to fix, but maybe not right this second. I'd be more comfortable if there were 1-2 priorities above that, e.g. one higher for stuff that makes a buildbot go red (i.e. breaks a test) and two higher for stuff that affects most developers (e.g. stuff checked in that doesn't even build). I think neither of these use cases should get that far. Neal and I talked it over and we're in agreement that if a commit makes the buildbots go red or breaks the build, we're going to just revert it. Tough luck Joe Dev, please test your changes more carefully next time. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR9/GJHEjvBPtnXfVAQJEugQAnyPR4WkSW7R2QN4F6v1zgQakD/8yVxCn TMESNJaG1XHhZJlZ6gSl5SBmy5PFS0w4GeUayXjbxFbH/hdpNWfAeWwgY+5+W/6S A3JO96nz89JUXqiRvOab7QaDl8N1KSd0Om7rJo50XKZZqJBNO6/ypL9mr1nAvUp/ ppZ614lz15I= =HCH0 -END PGP SIGNATURE- ___ 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] Installing Python 2.6 alpha1 on Windows XP
We are still having problems to integrate the MS Merge module into our MSI. Martin is working on the problem. In the mean time you can work around the problem by installing the MSVCRT 9.0 Redist. While this is a work-around for the people trying to run the alpha releases, it effectively prevents them from doing useful tests in that area for the later releases. IIUC, there is NO way to uninstall the CRT redist (perhaps except for deleting the files from disk, and cleaning an unknown number of registry keys), so once you have run that on a machine, the machine becomes useless for determining whether the installer would work without it. As a consequence, regular testers won't report the problem anymore, as has been demonstrated with 2.6a1, it seems (which apparently doesn't work). Non-regular testers will have no clue what happened (which also was just demonstrated). Regards, Martin ___ 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] test_support.have_unicode
The test_support unit has this have_unicode. Do we need the Python's test unit to be *that* backward compatible? Is there still an implementation of Python that doesn't support unicode? If there is, should the test suite care? It's still intended that you can build Python 2.6 without Unicode support, and that the test suite mostly works. If it doesn't, it's up to users who care about that feature to provide fixes, but you should not actively break it. Regards, Martin ___ 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] test_support.have_unicode
Martin v. Löwis schrieb: It's still intended that you can build Python 2.6 without Unicode support, and that the test suite mostly works. If it doesn't, it's up to users who care about that feature to provide fixes, but you should not actively break it. About two months ago I fixed the most critical bugs but the unicode free build is treated like a poor cousin at best. It's neither actively developed nor tested in regular intervals. IMO it's a deprecation candiate. Christian ___ 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] Installing Python 2.6 alpha1 on Windows XP
On 18/03/2008, Martin v. Löwis [EMAIL PROTECTED] wrote: Martin, can you comment? It looks like the 3.0 installer uses 2 copies of msvcr90.dll, where the 2.6 one doesn't. I would have thought that only one is necessary, but Gregor's experiments seem to demonstrate otherwise. I haven't figured it out myself; it's a complete mess, and Microsoft is heavily wasting our time. It seems that you absolutely *must* have the manifest file in each directory that has a DLL which links with the CRT. Whether or not separate copies of the DLL are then also necessary, and whether or not that causes two copies to be loaded into the address space, I don't know. HELP I'll see if I can wade through the documentation and offer any help. To reproduce the problem, you probably have to test on a machine which doesn't have the CRT redistributable installed centrally (neither through VS 2008 installation, nor by running the standalone CRT installer, nor by having installed any other software that provides an SxS copy of the CRT). That shouldn't be hard - I'll set up a Windows virtual machine with no additional software on it and can use that for testing. If you want me to try anything out, let me know and I can do so in a guaranteed clean environment. 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] Installing Python 2.6 alpha1 on Windows XP
That shouldn't be hard - I'll set up a Windows virtual machine with no additional software on it and can use that for testing. If you want me to try anything out, let me know and I can do so in a guaranteed clean environment. That should be a reasonable setup. Try moving the manifest files and the copies of the CRT around, in the 2.6 installer which (reportedly) doesn't work; you should try to reproduce the error Gregor had first. Don't use the all users install, but the per-user one; for the all-users case, I need to add proper SxS support, installing into the assembly cache, which currently isn't implemented. Then, when it does work, try to figure out how to eliminate the extra copy of the CRT. Perhaps the manifest needs to be tweaked? Regards, Martin ___ 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] test_support.have_unicode
About two months ago I fixed the most critical bugs but the unicode free build is treated like a poor cousin at best. It's neither actively developed nor tested in regular intervals. IMO it's a deprecation candiate. In the sense that 3k won't support it anymore - certainly. In the sense that it will be removed in 2.7: Why? I'd rather say it's unmaintained, not deprecated. Regards, Martin ___ 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] Installing Python 2.6 alpha1 on Windows XP
That shouldn't be hard - I'll set up a Windows virtual machine with no additional software on it and can use that for testing. If you want me to try anything out, let me know and I can do so in a guaranteed clean environment. I think I've a spare license of XP Home around somewhere. I'm going to install yet another XP in a VM, too. VMware supports snapshots and roll backs. I can try out multiple approaches and roll back the changes easily. Christian ___ 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-3000] PEP 361: Python 2.6/3.0 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote: Hey Barry, Thanks for putting this PEP together. This is really helpful. Hi Travis... thanks! I didn't see discussion of PEP 3118 and it's features back-ported to Python 2.6. I've already back-ported the new buffer API as an addition to the old buffer protocol. In addition, I've planned to back-port the improvements to the struct module and the addition of the memoryview object (both in PEP 3118). If you have questions, we can talk tomorrow. Let's do that. Neal has put together a list of things that he thinks needs to be backported. We should formalize that list (as best we can given we're still in alpha), and add it to the PEP. I think we should also make sure we have open issues in the tracker for each backporting task. Neal and I talked about this yesterday too and came up with some general guidelines. The view we have is that through conservative use of future imports and backports, we want to start closing the gap between 2.6 and 3.0. It'll still be fairly wide though, so we'll use 2.7/3.1 to close it even further by doing things like backporting more stuff, de-futurizing features in 2.6, etc. It may be that we should take a very conservative approach to new features in the next few major release (in both families), concentrating instead on stabilizing what we've got and helping make the transition less and less painful. So you could imagine that 2.8/3.2 would close the gap far enough that it wouldn't be much more work to move from 2.8 to 3.2 than it would be to move from 2.5 to 2.6. Some other thoughts: we might want to shorten our post 2.6/3.0 release cycles, say to 1 year or less so that we can help speed this transition. If we try hard to keep new features to a minimum, this might be possible, but we also have to avoid churn. Quite a few people expressed to me that it might be 5 years before they switch fully to 3.0. That seems fine to me, given that some big Python shops are still on 2.2 or gasp 1.5 and 1.6. So 3 years from 2.6/3.0 to 2.8/3.2 doesn't seem to wildly outrageous to me. Given this longer view of the transition, we can be more conservative about what we backport to 2.6. A general principle would be anything that is brand new syntax in 3.0 can be backported, because there won't be any existing code in 2.6 that could break. Anything that can be enabled through a future-import might be a candidate, but you have to be careful about tricky semantic differences. For example, changing the meaning of dict.keys() via a future-import is not a good idea. One thing I would like to see is from __future__ import unicode_strings or some such. The only thing this would do is allow you to write unicode string literals in Python 2.6 without the u'' prefix. That's a fairly localized change (affecting just the file the literals appear in), but it would go a long way toward closing that gap. One question that came up was whether we have enough bitfields to handle all the future statements we might have, and whether you even want to see Python 2.6 code sprinkled with lots of future statements. Does it make sense to have a from __future__ import python3 umbrella? Will we really have that many future statements? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBR9/WGHEjvBPtnXfVAQLP1AP+OpSuXHDgE1uxifKA6FEKxS1Zms1Pe0ww OimG2kw3afzL5+o1mdrRBUDy/rETpNhlxBTgx+fgI7VJc+Vs+uBi0sQwemCqOZ1I 9qlBFCo8YrmXlCZTdL9E0nEpiBSuanLKJcdNP8VU3QjbOX0EKqNTfK1asSckxvgT H1o5wGqnX5M= =wiJQ -END PGP SIGNATURE- ___ 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] Change in priority fields
On Tue, Mar 18, 2008 at 8:39 AM, Barry Warsaw [EMAIL PROTECTED] wrote: On Mar 18, 2008, at 12:11 AM, Guido van Rossum wrote: Hm... This feels a bit like inflation of priorities to me; there would be lots of critical bugs and quite a few release blockers... The highest priority just pertains to the upcoming release which could be weeks in the future. I want a very simple roundup query that I can consult during the release cycle to know whether everything's fine, or whether I have to start pestering people and pull the big red STOP RELEASE button. Critical gives us a priority for things we really need to fix, but maybe not right this second. Sure. My (mild) concern is that (a) the terms chosen sound a bit alarming, and (b) there's no term left for even *more* alarming issues. I also want to express my concern that this sounds like a bit *too* automatic and draconian. The key goal here (well, mine in any case :-) is to manage developers, not to get releases out at all cost. Even though the release schedule is set in stone, I think we should send out a variety of reminders ahead of each scheduled release, and these reminders must come from a human, not from a bot. There should be some kind of consensus that we're all comfortable with releasing the code in the current state -- even for an alpha release -- and that's not necessarily expressed as showstopper bugs. Maybe the reminder mail could include an exhortation to create new showstopper issues for anything that a developer feels should really be addressed before the release, even if it's not thought of a bug. The release reminder emails act as a kind of wake-up call to many developers. Another little trick we're using in my group at Google is to have a bug that tracks a specific release. I've found this is particularly handy once releases are done from release branches, and fixes in the dev branch need to be cherry-picked. But if you just want to use the mailing list for this that's probably fine too. I'd be more comfortable if there were 1-2 priorities above that, e.g. one higher for stuff that makes a buildbot go red (i.e. breaks a test) and two higher for stuff that affects most developers (e.g. stuff checked in that doesn't even build). I think neither of these use cases should get that far. Neal and I talked it over and we're in agreement that if a commit makes the buildbots go red or breaks the build, we're going to just revert it. Tough luck Joe Dev, please test your changes more carefully next time. Sure. -- --Guido van Rossum (home page: http://www.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] test_support.have_unicode
On Tue, Mar 18, 2008 at 9:25 AM, Martin v. Löwis [EMAIL PROTECTED] wrote: About two months ago I fixed the most critical bugs but the unicode free build is treated like a poor cousin at best. It's neither actively developed nor tested in regular intervals. IMO it's a deprecation candiate. In the sense that 3k won't support it anymore - certainly. In the sense that it will be removed in 2.7: Why? I'd rather say it's unmaintained, not deprecated. Right. It's a Py3k warning candidate. -- --Guido van Rossum (home page: http://www.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 361: Python 2.6/3.0 release schedule
Possible features for 2.6 New modules in the standard library: - JSON implementation Have there been any plans made for which one? All of the implementations I'm aware of (cjson, simplejson, jsonlib, demjson, python-json) have serious issues that in my opinion should be fixed before inclusion in the standard library[1]. I am the author of jsonlib, and am willing to write patches for whichever implementation becomes the standard, but it would be very nice to know what to focus on. Apologies if this has been discussed already, but there was no link to a PEP in 361 and a search of python-dev and c.l.p returned no relevant results. [1] * cjson and python-json have almost complete absense of Unicode support. * simplejson is slow and writes incorrect unicode escapes. * demjson is far too forgiving when parsing and accepts all sorts of invalid input. * jsonlib is not PEP 8-compliant and has terrible error handling. * python-json is abandoned, slow, and lacks Unicode support. ___ 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-3000] PEP 361: Python 2.6/3.0 release schedule
Barry Warsaw schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote: Hey Barry, Thanks for putting this PEP together. This is really helpful. Hi Travis... thanks! I didn't see discussion of PEP 3118 and it's features back-ported to Python 2.6. I've already back-ported the new buffer API as an addition to the old buffer protocol. In addition, I've planned to back-port the improvements to the struct module and the addition of the memoryview object (both in PEP 3118). If you have questions, we can talk tomorrow. Let's do that. Neal has put together a list of things that he thinks needs to be backported. We should formalize that list (as best we can given we're still in alpha), and add it to the PEP. I think we should also make sure we have open issues in the tracker for each backporting task. I think that [issue1971] ctypes exposing the pep 3118 buffer interface should / could also be backported to 2.6 (once it is merged into py3k). Thomas ___ 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 365 (Adding the pkg_resources module)
At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote: I am hoping that someone will create a simpler bootstrap module that is able to download a file of pure Python code and install it, perhaps by running its setup.py, assuming that it only depends on distutils (or other things previously installed). I will welcome such a module into the stdlib. I'm not sure a PEP is even needed, though interested parties are certainly welcome to write a PEP specifying the behavior first. With 2.6 and 3.0 slated for release in September, there should be enough time to get this done before then. Unfortunately, as I've already tried to explain, download a file ... and install it is not a sufficiently well-specified requirement to implement a robust tool. Even if it is not to support arbitrary existing distutils sources, there still needs to be a way to document precisely what the tool does and does not support installing, so that users can produce correct files for it to consume, register them properly with PyPI, etc. And as I said before (perhaps not very well) the distutils documentation has already proven to be inadequate as such a specification, both for users to create these files -- and even more important -- for programs to consume them. (For example, distutils source distribution tarball filenames are not unambiguously machine-parseable.) That's why I think some specific format (i.e. conventions) have to be defined for this to work, even if it's merely a set of documented restrictions on a distutils-based layout, file naming conventions, versioning, etc. In other words, you can't have your cake and eat it, too. If there's to be a bootstrap tool, you must bless *some* set of packaging conventions, including file naming, version parsing, and so on. Can we use setuptools' version parsing scheme to identify the latest stable version, for example? What about setuptools' filename component canonicalization and escaping rules? Frankly, I don't care what the conventions are, only that they be unambiguously defined and reasonably implementable for producers and consumers alike. I just want there to be *some* sort of robust, documented, standard installation bootstrap vector in the stdlib, so that setuptools, zc.buildout, and virtualenv don't have to maintain their own (or depend on setuptools maintaining its own). But not only have you rejected the *only* existing robust and well-documented conventions for automated processing of Python libraries, you say you have no time for this part of the thread when I ask what conventions you want to bless *instead*. So I'm at a bit of a loss for what we're supposed to do now. ___ 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] adding json to stdlib (was: Re: PEP 361: Python 2.6/3.0 release schedule)
On Tue, Mar 18, 2008 at 11:17 AM, John Millikin [EMAIL PROTECTED] wrote: Possible features for 2.6 New modules in the standard library: - JSON implementation Have there been any plans made for which one? All of the No. This was something I added as a nice to have for 2.6. implementations I'm aware of (cjson, simplejson, jsonlib, demjson, python-json) have serious issues that in my opinion should be fixed before inclusion in the standard library[1]. I am the author of jsonlib, and am willing to write patches for whichever implementation becomes the standard, but it would be very nice to know what to focus on. I'm not familiar enough with any of the libraries to comment. If it's premature to add a particular implementation, that's fine, we can wait. Apologies if this has been discussed already, but there was no link to a PEP in 361 and a search of python-dev and c.l.p returned no relevant results. I don't believe it has been discussed before. I've changed the subject and would like to discuss this now. It would be great if you could pull together and get the community behind a single solution that is robust enough to include in the stdlib. If that an be finished for 2.6, great. If it waits for 2.7, that would still be fine. n [1] * cjson and python-json have almost complete absense of Unicode support. * simplejson is slow and writes incorrect unicode escapes. * demjson is far too forgiving when parsing and accepts all sorts of invalid input. * jsonlib is not PEP 8-compliant and has terrible error handling. * python-json is abandoned, slow, and lacks Unicode support. ___ 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/nnorwitz%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
[Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
I'm reviving a very old thread based on discussions with Martin at pycon. Sent: Monday, 23 July 2007 5:12 PM Subject: Re: [Distutils] distutils.util.get_platform() for Windows Rather than forcing everyone to read the context, allow me to summarize: On 64bit Windows versions, we need a string that identifies the platform, and this string should ideally be used consistently. This original thread related to the files created by distutils (eg, pywin32-210.win???64??-py2.6.exe) but it seems obvious that we should be consistent wherever Python wants to display the platform (eg, in the startup banner, in platform.py, etc). In the old thread, there was a semi-consensus that 'x86_64' be used by distutils (and indeed, Lib/distutils/util.py in get_platform() has been changed, by me, to use this string), but the Python 'banner', for example, reports AMD64. Platform.py doesn't report much at all in this area, at least when pywin32 isn't installed, but it arguably should. Both Martin and I prefer AMD64 as the string, for various reasons. Firstly, it is less ugly than 'x86_64', and doesn't include an '_'/'-' which might tend to confuse parsing by humans or computers. Martin also made the point that AMD invented the architecture and AMD64 is their preferred name, so we should respect that. So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64). Any objections? Any strong feelings that using 'AMD' will confuse people with Intel processors? Strong feelings about the parsability of the name (PJE? wink)? Strong feelings about the color wink? Thanks, Mark ___ 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 361: Python 2.6/3.0 release schedule
I keep forgetting to reply to the list: This is great news. I was getting ready to submit a patch to fix the Unicode handling in simplejson (which I will probably do anyway), but I'm interested in making sure whichever lib will hit the standard library has a correct implementation. Doug On Mar 18, 2008, at 12:17 PM, John Millikin wrote: Possible features for 2.6 New modules in the standard library: - JSON implementation Have there been any plans made for which one? All of the implementations I'm aware of (cjson, simplejson, jsonlib, demjson, python-json) have serious issues that in my opinion should be fixed before inclusion in the standard library[1]. I am the author of jsonlib, and am willing to write patches for whichever implementation becomes the standard, but it would be very nice to know what to focus on. Apologies if this has been discussed already, but there was no link to a PEP in 361 and a search of python-dev and c.l.p returned no relevant results. [1] * cjson and python-json have almost complete absense of Unicode support. * simplejson is slow and writes incorrect unicode escapes. * demjson is far too forgiving when parsing and accepts all sorts of invalid input. * jsonlib is not PEP 8-compliant and has terrible error handling. * python-json is abandoned, slow, and lacks Unicode support. ___ 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/douglas%40openplans.org !DSPAM:4037,47dfeb7b286095409313003! ___ 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] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
[EMAIL PROTECTED] schrieb: So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64). +1 for AMD64 If we ever need names for Itanium and i386 compatible arch I propose IA64 and X86. Christian ___ 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] Windows x64 bsddb 4.4.20 woes
The other query I had was whether or not I should try a later version of BerkeleyDB -- are we committed to 4.4.20 (or 4.4.x?) for 2.6/3.0 or is it worth investigating newer versions? Martin/Jesus, any thoughts on this? As Greg says: 4.5.x should work fine. Importing a new version into the build process is a big effort, though, and should only be done if either a) the beta releases are close, so the new version is the one we'll ship, or b) factual improvements can be demonstrated with a new version. Regards, Martin ___ 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] Windows x64 bsddb 4.4.20 woes
Martin, you've changed externals/bsddb-4.4.20 with regards to x64 builds recently -- have you been able to get things working in your x64 environments? I changed the project files so that it will use the x64 compilers even if no environment variables were set - the original bsddb files expected that you run VS with /useenv, in an SDK x64 build environment. As a consequence, it now builds; I have never bothered testing that it actually works. Regards, Martin ___ 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] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
+1 for avoiding a bikeshed, so +1 to AMD64. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Christian Heimes [EMAIL PROTECTED] Sent: 18 March 2008 13:54 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; python-dev@python.org Subject: Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows) [EMAIL PROTECTED] schrieb: So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64). +1 for AMD64 If we ever need names for Itanium and i386 compatible arch I propose IA64 and X86. Christian ___ 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/tnelson%40onresolve.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] Change in priority fields
On Tue, Mar 18, 2008 at 10:51 AM, Guido van Rossum [EMAIL PROTECTED] wrote: The key goal here (well, mine in any case :-) is to manage developers, not to get releases out at all cost. Even though the release schedule is set in stone, I think we should send out a variety of reminders ahead of each scheduled release, and these reminders must come from a human, not from a bot. ... Maybe the reminder mail could include an exhortation to create new showstopper issues for anything that a developer feels should really be addressed before the release, even if it's not thought of a bug. The release reminder emails act as a kind of wake-up call to many developers. I think I did this for 2.5 and plan to do improve communications for 2.6. I'll need to work the details out with Barry, but it is my intention to communicate as much as possible. The next release (in two weeks) will probably be a little haphazard as I try to get up to date after pycon. I'll try to get more organized so all subsequent releases go smoothly. Suggestions to python-dev on how to improve the process are always encouraged. n ___ 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] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
On Wed, Mar 19, 2008 at 02:05:37AM +0900, [EMAIL PROTECTED] wrote: So, at the risk of painting a bike-shed, I'd like to propose that we adopt 'AMD64' in distutils (needs a change), platform.py (needs a change to use sys.getwindowsversion() in preference to pywin32, if possible, anyway), and the Python banner (which already uses AMD64). Debian uses 'amd64', it seems they chose this after a survey of what existing systems used what names, and the consensus came out in favour of amd64. http://lists.debian.org/debian-ctte/2004/06/msg00041.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
[Python-Dev] Introducing the ``make check`` command
After having one too many commits be rejected by having trailing whitespace, I wrote a script that runs reindent.py over all .py files that are to be checked in. But since there are other things that one should be aware of when creating a patch I let people know if they edited anything in the Doc directory, Misc/ACKS, and Misc/NEWS. There are a couple of things I would like to see the command gain. One is to detect if any files (outside of Doc) have changed since the last run of regrtest. That would require writing out a file, though, so one can at least stat the file to get the modification time. Do people have any issues with the idea? I would also like to more or less codify whether a patch means someone needs to be added to Misc/ACKS or not. I should be able to run ``svn diff`` to get the output and see if enough lines have changed. Could then write it out to a common file so that one does not need to run the command again if the patch is needed. Lastly, I would like to have it strip trailing whitespace in C files. The only problem is that I don't know if removing trailing whitespace could possibly cause a problem or not. Anyone know? -Brett ___ 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] Introducing test coverage stats
I have added a bugtracker issue that adds unit test coverage statistics. Issue 2403: http://bugs.python.org/issue2403 Directions are on the issue page. Titus: Brent suggested I bug you to review this. Test, complain, flame. Feedback welcome. Jerry Seutter ___ 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] [Distutils] Capsule Summary of Some Packaging/Deployment Technology Concerns
Marius Gedminas wrote: On Mon, Mar 17, 2008 at 08:37:30PM -0400, Phillip J. Eby wrote: At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote: People also want a greater variety of file_finders to be included with setuptools. Instead of just CVS and SVN, they want it to comprehend Mercurial, Bazaar, Git and so forth. Did you point them to the Cheeseshop? There are plugins already available for all the systems you mentioned, plus Darcs and Monotone. If you mean included as in bundled, this doesn't make a whole lot of sense to me. They knew there were plugins out there, of various quality and availability but wanted them bundled. ;-) It's a pain to track them down. Perhaps if the RPM format were broken out from setuptools, as the inclusion of some formats leads them to believe the set is just incomplete, not intentionally sparse. I'd think that if you're using setuptools as a developer (the only reason you need the file finders, since source distributions include a prebuilt manifest), you'd not have a problem saying easy_install setuptools-git or adding a setup_requires='setuptools-git' line to your setup.py. (Although the latter would only be needed for *development*, not deployment.) setup_requires looks like a solution, but it requires extra attention from the developers who write the setup.py. Writing a setup.py is already quite complicated -- I usually end up copying an existing one and modifying it. As a compromise, of making new formats easily available but not bundled, and not requiring special action within setup.py, setuptools could treat --formats=dpkg as an implicit setup_requires= and pull it from PyPI. And the --list-formats option could query PyPI for the possibilities, just as --list-classifiers does today. If would require a few standards in keywording/classifying those format eggs but we already need those standards for other projects, such as locating recipes for buildout and plugins for trac. -Jeff ___ 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 365 (Adding the pkg_resources module)
Guido van Rossum writes: I am hoping that someone will create a simpler bootstrap module FWIW (I've never tried to implement one of these things) I agree with Phillip. This is not possible in the sense you are advocating. Anything simpler is simply an invitation to an unending stream of issues, far more so than adopting eggs as a best current practice would. Better to Just Say No to an installer in the stdlib. I'm not sure a PEP is even needed This I simply don't understand. I *have* participated in bolting on features to such systems, and it's a mess. As features are added, existing users will demand that old packages install exactly as they ever did, except that sometimes (but not always!) they want them upgraded to put things in newly blessed places. Features are easy to add, since on the main thread of control installers are basically just a sequence of single commands, sometimes optional. python-dev has some pretty good controls that will help slow such trends. Nonetheless, PEP-less development of an installer system is scary. Installer complexity is a creeping horror, worse than kudzu.[1] Footnotes: [1] http://en.wikipedia.org/wiki/Kudzu#Invasive_species ___ 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 365 (Adding the pkg_resources module)
On Tue, Mar 18, 2008 at 11:23 AM, Phillip J. Eby [EMAIL PROTECTED] wrote: At 12:31 AM 3/18/2008 -0500, Guido van Rossum wrote: I am hoping that someone will create a simpler bootstrap module that is able to download a file of pure Python code and install it, perhaps by running its setup.py, assuming that it only depends on distutils (or other things previously installed). I will welcome such a module into the stdlib. I'm not sure a PEP is even needed, though interested parties are certainly welcome to write a PEP specifying the behavior first. With 2.6 and 3.0 slated for release in September, there should be enough time to get this done before then. Unfortunately, as I've already tried to explain, download a file ... and install it is not a sufficiently well-specified requirement to implement a robust tool. Even if it is not to support arbitrary existing distutils sources, there still needs to be a way to document precisely what the tool does and does not support installing, so that users can produce correct files for it to consume, register them properly with PyPI, etc. And as I said before (perhaps not very well) the distutils documentation has already proven to be inadequate as such a specification, both for users to create these files -- and even more important -- for programs to consume them. (For example, distutils source distribution tarball filenames are not unambiguously machine-parseable.) That's why I think some specific format (i.e. conventions) have to be defined for this to work, even if it's merely a set of documented restrictions on a distutils-based layout, file naming conventions, versioning, etc. In other words, you can't have your cake and eat it, too. If there's to be a bootstrap tool, you must bless *some* set of packaging conventions, including file naming, version parsing, and so on. Can we use setuptools' version parsing scheme to identify the latest stable version, for example? What about setuptools' filename component canonicalization and escaping rules? Frankly, I don't care what the conventions are, only that they be unambiguously defined and reasonably implementable for producers and consumers alike. I just want there to be *some* sort of robust, documented, standard installation bootstrap vector in the stdlib, so that setuptools, zc.buildout, and virtualenv don't have to maintain their own (or depend on setuptools maintaining its own). But not only have you rejected the *only* existing robust and well-documented conventions for automated processing of Python libraries, you say you have no time for this part of the thread when I ask what conventions you want to bless *instead*. So I'm at a bit of a loss for what we're supposed to do now. You're welcome to write a PEP as long as it is self-contained (at best referencing other accepted PEPs like the PyPI metadata PEPs). And the PEP better not be 2500 lines long. -- --Guido van Rossum (home page: http://www.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 365 (Adding the pkg_resources module)
There seems to be a misunderstanding about what I am proposing we do instead. The boostrap installer should only be powerful enough to allow it to be used to install a real package manager like setuptools. Maybe my use of Django as an example was confusing; I didn't actually mean that it should be possible to support installing Django directly (although I don't understand all the issure that would make it impossible). Only very few people would care about writing a setup script that works with this bootstrap module; basically only package manager implementers. --Guido On Tue, Mar 18, 2008 at 3:45 PM, Stephen J. Turnbull [EMAIL PROTECTED] wrote: Guido van Rossum writes: I am hoping that someone will create a simpler bootstrap module FWIW (I've never tried to implement one of these things) I agree with Phillip. This is not possible in the sense you are advocating. Anything simpler is simply an invitation to an unending stream of issues, far more so than adopting eggs as a best current practice would. Better to Just Say No to an installer in the stdlib. I'm not sure a PEP is even needed This I simply don't understand. I *have* participated in bolting on features to such systems, and it's a mess. As features are added, existing users will demand that old packages install exactly as they ever did, except that sometimes (but not always!) they want them upgraded to put things in newly blessed places. Features are easy to add, since on the main thread of control installers are basically just a sequence of single commands, sometimes optional. python-dev has some pretty good controls that will help slow such trends. Nonetheless, PEP-less development of an installer system is scary. Installer complexity is a creeping horror, worse than kudzu.[1] Footnotes: [1] http://en.wikipedia.org/wiki/Kudzu#Invasive_species -- --Guido van Rossum (home page: http://www.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] Introducing test coverage stats
s/Brent/Brett (sorry Brett. We still love you.) On Tue, Mar 18, 2008 at 3:00 PM, Jerry Seutter [EMAIL PROTECTED] wrote: I have added a bugtracker issue that adds unit test coverage statistics. Issue 2403: http://bugs.python.org/issue2403 Directions are on the issue page. Titus: Brent suggested I bug you to review this. Test, complain, flame. Feedback welcome. Jerry Seutter ___ 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] map, filter, zip in future_builtins
I'm working on #2171 -- putting map, filter, zip in 2.6's future_builtins. It has been suggested that it would be simplest to just return itertools.(imap, izip, ifilter), which is what py3k/Python/ bltinmodule.c, revision 61356 did. The advantage of this is that it's really easy and the behaviour seems to be identical. The disadvantage is that the two aren't identical: type(map(lambda x: x, [1, 2, 3])) # Python 3 type 'map' type(map(lambda x: x, [1, 2, 3])) == map True type(map(lambda x: x, [1, 2, 3])) # Python 2.6, with the patch type 'itertools.imap' type(map(lambda x: x, [1, 2, 3])) == map False Recommendations? ___ 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] adding json to stdlib (was: Re: PEP 361: Python 2.6/3.0 release schedule)
On Tue, Mar 18, 2008 at 11:43 AM, Neal Norwitz [EMAIL PROTECTED] wrote: On Tue, Mar 18, 2008 at 11:17 AM, John Millikin [EMAIL PROTECTED] wrote: Possible features for 2.6 New modules in the standard library: - JSON implementation Have there been any plans made for which one? All of the No. This was something I added as a nice to have for 2.6. I'd like to tentatively elevate it to a must have. There has been overwhelming support for this on web-sig. implementations I'm aware of (cjson, simplejson, jsonlib, demjson, python-json) have serious issues that in my opinion should be fixed before inclusion in the standard library[1]. I am the author of jsonlib, and am willing to write patches for whichever implementation becomes the standard, but it would be very nice to know what to focus on. I'm not familiar enough with any of the libraries to comment. If it's premature to add a particular implementation, that's fine, we can wait. On web-sig, the overwhelming majority wants simplejson, since that's the API they already use. (All current web frameworks use it.) Apologies if this has been discussed already, but there was no link to a PEP in 361 and a search of python-dev and c.l.p returned no relevant results. I don't believe it has been discussed before. I've changed the subject and would like to discuss this now. It would be great if you could pull together and get the community behind a single solution that is robust enough to include in the stdlib. If that an be finished for 2.6, great. If it waits for 2.7, that would still be fine. This is happening on web-sig as we speak. --Guido n [1] * cjson and python-json have almost complete absense of Unicode support. * simplejson is slow and writes incorrect unicode escapes. * demjson is far too forgiving when parsing and accepts all sorts of invalid input. * jsonlib is not PEP 8-compliant and has terrible error handling. * python-json is abandoned, slow, and lacks Unicode support. ___ 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/nnorwitz%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/guido%40python.org -- --Guido van Rossum (home page: http://www.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] Introducing the ``make check`` command
On Tue, 18 Mar 2008, Brett Cannon wrote: Lastly, I would like to have it strip trailing whitespace in C files. The only problem is that I don't know if removing trailing whitespace could possibly cause a problem or not. Anyone know? I would be worried about the sequence backslash-space-newline. Off the top of my head I can't see why that would occur in valid code, but dropping the space would give you an escaped newline which could be different from the original. I'd be worried about some weird case related to macro expansion or definition. http://gcc.gnu.org/onlinedocs/cppinternals/Lexer.html has some information related to the Gnu C preprocessor which may be relevant. Have you considered also forcing Mac \r and DOS \r\n line endings to Unix \n style? Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] map, filter, zip in future_builtins
On Tue, Mar 18, 2008 at 3:54 PM, David Wolever [EMAIL PROTECTED] wrote: I'm working on #2171 -- putting map, filter, zip in 2.6's future_builtins. It has been suggested that it would be simplest to just return itertools.(imap, izip, ifilter), which is what py3k/Python/ bltinmodule.c, revision 61356 did. The advantage of this is that it's really easy and the behaviour seems to be identical. The disadvantage is that the two aren't identical: type(map(lambda x: x, [1, 2, 3])) # Python 3 type 'map' type(map(lambda x: x, [1, 2, 3])) == map True type(map(lambda x: x, [1, 2, 3])) # Python 2.6, with the patch type 'itertools.imap' type(map(lambda x: x, [1, 2, 3])) == map False Recommendations? Doesn't strike me as a terrible problem. Why is the latter == failing? What's the different between type(map(...)) and map? -- --Guido van Rossum (home page: http://www.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] 3.0 buildbots all red
Trent Nelson wrote: New sprint idea: getting all (inc. trunk) the buildbots green by Thursday. Anyone interested? I think the chance to achieve that is close to zero. Sounds like a challenge if ever I've heard one -- care to wager a beer on it? (Only applies to buildbots that are connected/online.) (FWIW, I've got the x64 Windows build green on my dev server, tcl/tk and bsddb required patching, so did some tests, and so did some C code -- I'm in the process of filtering the efforts back into the tracker.) Make sure you get a screen shot for OnYourDesktop if/when they *do* go green! regards Steve ___ 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] changing regrtest to handle import errors
[changing to: and subject: ]
On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
[EMAIL PROTECTED] wrote:
Get this test to pass (UserList/UserDict no longer exist and caused a
skip).
I think the automatic skip on ImportError is harmful.
We should add a helper function to test_support so that you can write
foobar = test_support.import_optional('foobar')
and it will skip the test if foobar cannot be imported; all other
failing imports should cause the test to *fail*.
Any takers? This should be an easy two-part task.
This would be a great starter project for a new developer.
http://bugs.python.org/issue2409
Let me know if you could use some help. Feel free to contact me on or off list.
n
___
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] map, filter, zip in future_builtins
On 18-Mar-08, at 5:10 PM, Guido van Rossum wrote: On Tue, Mar 18, 2008 at 3:54 PM, David Wolever [EMAIL PROTECTED] wrote: type(map(lambda x: x, [1, 2, 3])) # Python 2.6, with the patch type 'itertools.imap' type(map(lambda x: x, [1, 2, 3])) == map False Doesn't strike me as a terrible problem. Excellent, I'll go ahead and do the same thing with filter and zip. Why is the latter == failing? What's the different between type(map(...)) and map? Because future_builtins.map imports and returns itertools.imap: def map(*args): from itertools import imap return imap(*args) ___ 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] Introducing the ``make check`` command
On Tue, Mar 18, 2008 at 4:09 PM, Isaac Morland [EMAIL PROTECTED] wrote: On Tue, 18 Mar 2008, Brett Cannon wrote: Lastly, I would like to have it strip trailing whitespace in C files. The only problem is that I don't know if removing trailing whitespace could possibly cause a problem or not. Anyone know? I would be worried about the sequence backslash-space-newline. Off the top of my head I can't see why that would occur in valid code, but dropping the space would give you an escaped newline which could be different from the original. I'd be worried about some weird case related to macro expansion or definition. http://gcc.gnu.org/onlinedocs/cppinternals/Lexer.html has some information related to the Gnu C preprocessor which may be relevant. Weird code is not allowed. =) Have you considered also forcing Mac \r and DOS \r\n line endings to Unix \n style? We let svn handle that. -Brett ___ 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-3000] No releases tonight
On 2 Mar 2008, at 02:00, Alex Martelli wrote: On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw [EMAIL PROTECTED] wrote: ... I also propose translations of the shorter text to important languages like French, German, Japanese, Portuguese and Spanish. I'm willing to help with the German translation. Cool, thanks. I'd like to volunteer for Italian (and we, the Italian Python community, do have reasonably good connections to the Italian technical press, which is covering e.g. the upcoming Pycon Due conference), and although my French is VERY rusty I can give it a try if no native French speaker is forthcoming. I'm a native French speaker, and although I am not involved in Python's development I would be happy to help by translating the documents. I have no connections with the French-speaking technical press. -- Arnaud ___ 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] Bug in Pickle protocol involving __setstate__
If we have a hierarchy of classes, and we use __getstate__/__setstate__, the wrong version of __setstate__ gets called. Possibly, this is a documentation problem, but here goes: Take two classes, A and B, where B is the child of A. Construct a B. Pickle it. Unpickle it, and you find that the __setstate__ function for A is called with the result produced by B.__getstate__(). This is wrong. An example follows: import pickle as P class A(object): def __init__(self, a): print 'A.__init__' self.a = a def __getstate__(self): print 'A.__getstate' return self.a def __setstate__(self, upstate): print 'A.__setstate', upstate self.a = upstate class B(A): def __init__(self, a, b): print 'B.__init__' A.__init__(self, a) self.b = b def __getstate__(self): print 'B.__getstate' return (A.__getstate__(self), self.b) def __setstate(self, upstate): # This never gets called! print 'B.__setstate', upstate A.__setstate__(self, upstate[0]) self.b = upstate[1] def __repr__(self): return 'B a=%d b=%d' % (self.a, self.b) q = B(1,2) print '---' r = P.loads(P.dumps(q, 0)) print 'q=', q print 'r=', r Now, run it: $ python foo.py B.__init__ A.__init__ --- B.__getstate A.__getstate A.__setstate (1, 2) q= B a=1 b=2, h=46912504218064 r= Traceback (most recent call last): File foo.py, line 44, in module print 'r=', r File foo.py, line 37, in __repr__ return 'B a=%d b=%d' % (self.a, self.b) AttributeError: 'B' object has no attribute 'b' $ ___ 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 3000: Special type for object attributes map keys
It appears to me that if you can make mapping mechanisms faster in Python you can make significant overall speed improvements. I also think the proposed concept could add flexibility to persistence formats and RMI interfaces. My basic idea is to have a constant string type with an interpreter globally unique hash. If the original constant is created in a manner different from string constants, it can be tracked and handled differently by the interpreter. Obviously most object attribute references are done with the dot operator, so I guess the interpreter already has an efficient mapping mechanism. But there must be a crossover with __getattr__ etc, where a map of some sort is used. I imagine that having a global namespace to translate attribute names into integers could be used for several purposes by the interpreter as well as an application exchanging objects with other applications. I imagine these expressions to be supported: * attrname(string) - creates an attrname value from the string * int(attrname) - gets the hash value * string(attrname) - gets the string value Hope this makes sense Henrik P.S. I originally thought of this in a JavaScript context so forgive me if this would make little difference in Python. ___ 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] embedding in multi threaded C/C++
Hi all, I'm working on embedding Python in a multi threaded application but found mostly old or confusing info on this. Can anyone point me to the right direction or send some working examples? Detail: Python 2.5.1, MacOSX Leopard 10.5.1, using Pytohn/C API The application initializes Python in a shared library, which in turn links in more libraries that may or may not use C API commands in parallel. Generally it all works fine, but when two libraries try to access Python code I get seg fault or similar. The closest I got to resolve this is based on this message: http://groups.google.fi/group/comp.lang.python/msg/fe4e114d1e1a741d which suggests starting a new sub interpreter for each task. However, i still get errors like below. (Thread 0 on it's own works fine.) According to the docs PyObject_HasAttrString should always succeeds so I don't understand what happens. Also I get thread mix-up messages randomly even though I double checked the implementation. 2 Threads accessing Python: --- Thread 0 Crashed: 0 org.python.python 0x15a58bcc PyErr_Occurred + 16 (errors.c:77) 1 org.python.python 0x159c642c instance_getattr + 277 (classobject.c:698) 2 org.python.python 0x159f789b PyObject_HasAttrString + 116 (object.c:1069) While Thread 4 is running a process: Thread 4: 0 org.python.python 0x15a43751 PyEval_EvalFrameEx + 794 (ceval.c:852) 1 org.python.python 0x15a49cdc PyEval_EvalCodeEx + 1819 (ceval.c:2831) 2 org.python.python 0x159df537 function_call + 320 (funcobject.c:517) 3 org.python.python 0x159be278 PyObject_Call + 45 (abstract.c:1860) 4 org.python.python 0x159c5ee5 instancemethod_call + 401 (classobject.c:2497) 5 org.python.python 0x159c297c PyObject_CallMethodObjArgs + 223 (abstract.c:1860) Thanks for any advice, George ___ 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] [Distutils] PEP 365 (Adding the pkg_resources module)
Folks: (By the way, it was a pleasure to meet many of you in Real Life for the first time at Pycon.) Here is what I want: 1. The standard Python build tools by default produce machine- parseable package metadata, which can include package dependency information with reasonably well-defined semantics. Oh good! I already have this, since distutils in Python = 2.5 produces .egg-info metadata in an easy-to-parse format. 2. This machine-parseable metadata is widely supported and understood by the Python community. In retrospect, it's too bad that it isn't named .pkg-info instead of .egg-info, in order to avoid the fraught politics around the concept of eggs. A concrete example of such a misunderstanding is the sad fact that many Linux distributions were in the habit of deleting this information from their Python packages, perhaps because they were under the impression that it was obviated by their packaging tools. The major distributions have all stopped doing this now. Unifying the created-by-default PKG-INFO files and the created-by- default .egg-info directories would be nice, too. 3. The standard Python library includes a tool to find and parse this metadata, so that I can write programmatic tests of my dependencies, like this: http://allmydata.org/trac/tahoe/browser/_auto_deps.py?rev=2062 This is one of the improvements that I was anticipating from pkg_resources going into the standard library. 4. The standard Python library includes a tool to find and read resources (other than Python modules) that came bundled in a Python package. Consider, for example, this snippets of code in Nevow: http://divmod.org/trac/browser/trunk/Nevow/setup.py?rev=13786#L10 http://divmod.org/trac/browser/trunk/Nevow/setup.py?rev=13786 http://divmod.org/trac/browser/trunk/Nevow/setup_egg.py?rev=2406 When Nevow uses pkg_resources to import its files such as default.css, then it is able to find at runtime, even if is being imported from a py2exe or py2app zip, or on other platforms where its homegrown setup script and homegrown find my file function fail. So using pkg_resources (and setuptools to install it) makes test_nevow pass on all of the allmydata.org buildslaves: http://allmydata.org/buildbot/waterfall?show_events=false Regards, Zooko ___ 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] pre-checkin test suggestion for python repository
The tabs/spaces checker that is run before doing a svn ci on the python repository spits out an error message about which files have problems. Could someone please update this error message to say something to the effect of run Tools/scripts/reindent.py on every file listed above and rerun your tests to fix this before checking in thanks -gps ___ 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] Bug in Pickle protocol involving __setstate__
On Mon, Mar 3, 2008 at 8:00 AM, Greg Kochanski [EMAIL PROTECTED] wrote: If we have a hierarchy of classes, and we use __getstate__/__setstate__, the wrong version of __setstate__ gets called. Possibly, this is a documentation problem, but here goes: No, it's a typo error :) Take two classes, A and B, where B is the child of A. Construct a B. Pickle it. Unpickle it, and you find that the __setstate__ function for A is called with the result produced by B.__getstate__(). This is wrong. An example follows: import pickle as P class A(object): def __init__(self, a): print 'A.__init__' self.a = a def __getstate__(self): print 'A.__getstate' return self.a def __setstate__(self, upstate): print 'A.__setstate', upstate self.a = upstate class B(A): def __init__(self, a, b): print 'B.__init__' A.__init__(self, a) self.b = b def __getstate__(self): print 'B.__getstate' return (A.__getstate__(self), self.b) def __setstate(self, upstate): Try actually calling this method '__setstate__' instead. # This never gets called! print 'B.__setstate', upstate A.__setstate__(self, upstate[0]) self.b = upstate[1] def __repr__(self): return 'B a=%d b=%d' % (self.a, self.b) q = B(1,2) print '---' r = P.loads(P.dumps(q, 0)) print 'q=', q print 'r=', r Now, run it: $ python foo.py B.__init__ A.__init__ --- B.__getstate A.__getstate A.__setstate (1, 2) q= B a=1 b=2, h=46912504218064 r= Traceback (most recent call last): File foo.py, line 44, in module print 'r=', r File foo.py, line 37, in __repr__ return 'B a=%d b=%d' % (self.a, self.b) AttributeError: 'B' object has no attribute 'b' $ ___ 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/thomas%40python.org -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] map, filter, zip in future_builtins
On 18-Mar-08, at 6:01 PM, Benjamin Peterson wrote: Couldn't you just import imap as map? What do you mean? Import imap as map in future_builtins.c? Like the Python: import itertools map = intertools.map type(map(lambda x: x, range(3))) == map # True Ah, that's a much better idea :P I'll do that.___ 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 365 (Adding the pkg_resources module)
At 03:43 PM 3/18/2008 -0500, Guido van Rossum wrote: Only very few people would care about writing a setup script that works with this bootstrap module; basically only package manager implementers. That's true today, sure, but as soon as it is widely available, others are sure to want to use it too. I just want a bright-line distinction between what is and isn't bootstrappable, rather than a murky region of maybe, if you're not doing anything too complicated. There seems to be a misunderstanding about what I am proposing we do instead. The boostrap installer should only be powerful enough to allow it to be used to install a real package manager like setuptools. Which is why PEP 365 proposed only downloading an archive to a cache directory, and optionally running something from it. It explicitly disavows installation of anything, since the downloaded archive wouldn't have been added to sys.path except for the duration of the bootstrap process, and no scripts were to be installed. (Indeed, apart from the methods it would have used to locate the archive on PyPI, and to determine what to run from inside it, there was nothing particularly egg-specific about the proposed bootstrapping process.) So, to fully egg-neutralize the bootstrapping approach, we need only know how to locate an appropriate archive, and how to determine what to run from it. For the latter, we could use the already-in-2.6 convention of running __main__ from a zipfile or directory. (Too bad distutils source distributions have an extra directory name embedded in them, so one can't just execute them directly. Otherwise, we could've just let people drop in a __main__.py next to setup.py. OTOH, maybe it would be enough to use setuptools' algorithm for finding setup.py to locate __main__.py, and I'm fairly sure *that* can be briefly expressed in the PEP.) The other open question is a naming convention and version detection, so that the bootstrap tool can identify which of the files listed on PyPI is suitable for its use. (Both with regard to the version selection, and file type.) However, if PyPI were to grow support for designating the appropriate files and/or versions in some other way, we wouldn't need a naming convention as such. Without one or the other, the bootstrap tool would have to grow a version parsing scheme of some type, and play guessing games with file extensions. (Which is one reason I limited PEP 365's scope to downloading eggs actually *uploaded* to PyPI, rather than arbitrary packages *linked* from PyPI.) So, if I had to propose something right now, I would be inclined to propose: * using setuptools' version parsing semantics for interpretation of alpha/beta/dev/etc. releases * having a bdist_bootstrap format that's essentially a bdist_dumb .zip file with the internal path prefixes stripped off, making it an importable .zip with a different file extension. (Or maybe just .pyboot.zip?) The filename convention would use setuptools' canonicalization and escaping of names and version numbers, to allow unambiguous machine parsing of the filename. A __main__ module would have to be present for the archive to be run, as opposed to just being downloaded to a temporary directory. * calling the bootstrap module 'bootstrap', as in 'python -m bootstrap projectname optionalversion'. The module would expose an API to allow it to be used programmatically as well as the command line, so that bootstrapped packages can use the bootstrap process to locate dependencies if they so desire. (Today's package management tools, at least, are all based on setuptools, so if it's not present they'll need to download that before beginning their own bootstrapping process.) Apart from keeping the PEP self-contained and short, is there anything in this that you think you would object to? (You may reserve the right, of course, to later not like something in the details of setuptools' version/filename rules, after I've put them into the PEP, or really, anything else. I'm just asking if there's anything that's obviously offensive at this point, before I spend time on a new PEP.) ___ 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] pre-checkin test suggestion for python repository
On Tue, Mar 18, 2008 at 4:43 PM, Gregory P. Smith [EMAIL PROTECTED] wrote: The tabs/spaces checker that is run before doing a svn ci on the python repository spits out an error message about which files have problems. Could someone please update this error message to say something to the effect of run Tools/scripts/reindent.py on every file listed above and rerun your tests to fix this before checking in Done. n ___ 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] logging shutdown (was: Re: [Python-checkins] r61431 - python/trunk/Doc/library/logging.rst)
I think (repeatedly) testing an app through IDLE is a reasonable use case. Would it be reasonable for shutdown to remove logging from sys.modules, so that a rerun has some chance of succeeding via its own import? -jJ On 3/16/08, vinay.sajip [EMAIL PROTECTED] wrote: Author: vinay.sajip Date: Sun Mar 16 22:35:58 2008 New Revision: 61431 Modified: python/trunk/Doc/library/logging.rst Log: Clarified documentation on use of shutdown(). Modified: python/trunk/Doc/library/logging.rst == --- python/trunk/Doc/library/logging.rst(original) +++ python/trunk/Doc/library/logging.rstSun Mar 16 22:35:58 2008 @@ -732,7 +732,8 @@ .. function:: shutdown() Informs the logging system to perform an orderly shutdown by flushing and - closing all handlers. + closing all handlers. This should be called at application exit and no + further use of the logging system should be made after this call. .. function:: setLoggerClass(klass) ___ Python-checkins mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-checkins ___ 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] embedding in multi threaded C/C++
On Mon, Mar 10, 2008, George Fazekas wrote: I'm working on embedding Python in a multi threaded application but found mostly old or confusing info on this. Can anyone point me to the right direction or send some working examples? You should ask on comp.lang.python or the capi-sig list. python-dev is for people working on improving the Python core. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ It is easier to optimize correct code than to correct optimized code. --Bill Harlan ___ 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 3000: Special type for object attributes map keys
On Wed, Mar 5, 2008 at 4:27 PM, Henrik Vendelbo [EMAIL PROTECTED] wrote:
It appears to me that if you can make mapping mechanisms faster in
Python you can make significant
overall speed improvements. I also think the proposed concept could
add flexibility to persistence formats
and RMI interfaces.
My basic idea is to have a constant string type with an interpreter
globally unique hash. If the original constant
is created in a manner different from string constants, it can be
tracked and handled differently by the interpreter.
Part of this is done, but very differently in that all strings used in
code objects are interned (stored in a dictionary so we don't increase
memory by storing multiple string objects which contain the same
string) . So there is partially a mechanism to do what you suggest.
But there would be many places that would need to be modified.
I think we briefly discussed this in the past.
P.S. I originally thought of this in a JavaScript context so forgive
me if this would make little difference in Python.
Your message was a little confusing at first because the terminology
is a little different, but the idea makes sense. It's not clear how
much this would speed up the interpreter. The best way to test your
theory would be to create a patch and measure the performance
difference.
First, you should measure the current speed difference. Something like:
$ ./python.exe -m timeit -s 'd = {1: None}' 'd[1]'
100 loops, best of 3: 0.793 usec per loop
$ ./python.exe -m timeit -s 'd = {1: None}' 'd[1]'
100 loops, best of 3: 0.728 usec per loop
My python is a debug version, so a release version might be faster for
ints. If not, the first task would be to speed up int lookups. :-)
(You should verify more with real world dict sizes.) It is possible
to optimize dicts with int keys since string keys are specialized in
dicts, but ints are not. You would need to look in
Objects/dictobject.c. See http://python.org/dev/faq/ for general
hints on how to get started.
If ints were faster, some of the next steps would be:
* keep the globally unique number (very easy)
* update the source that generates byte codes to use the globally unique number
* store ints in dicts and update all the places for how they use attributes
* update byte code when a module is imported to use the globally unique number
Feel free to ask questions.
Cheers,
n
___
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] platform management
I don't think this is bike-shedding. The debate about AMD64 vs. amd64 vs. x86_64 reminded me that I've been bit more and more frequently by bits of platform-specific knowledge scattered around the standard library. The latest is the code in distutils.unixccompiler that tries to figure out what flags to send to the linker in order to add a dynamic library path lookup to a shared library. There are lots of different ways of figuring out which platform is being used, and they're all over the place. The code in distutils.unixccompiler uses sys.platform[:6], and looks for darwin; the code in urllib.py uses os.name, and expects it to be mac, but later looks for sys.platform == 'darwin'; posixfile believes that platforms come with version numbers (linux2, aix4); pydoc and tarfile have tests for sys.platform == 'mac'. tempfile looks at os.sys.platform *and* os.name. Could well be that all of these are correct (I believe that mac, for instance, refers to the generations of the Mac OS before OS X). But it means that when someone tries to update Python to a new major version release for, say, OS X, it's really easy to miss things. And the fact that the platform version is sometimes included and sometimes not is also problematic; darwin9 is different from darwin8 in some important aspects. It would be nice to (a) come up with a list of standard platform symbols, (b) put those symbols somewhere in the documentation, (c) have one way of discovering them, via sys or os or platform or whichever module, (d) add a standard way of discovering the platform version, and (e) stamp out all the other ways that have crept in over the years. 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] [Distutils] Capsule Summary of Some Packaging/Deployment Technology Concerns
Phillip J. Eby wrote: At 05:10 PM 3/17/2008 -0500, Jeff Rush wrote: 1. Many felt the existing dependency resolver was not correct. They wanted a full tree traversal resulting in an intersection of all restrictions, instead of a first-acceptable-solution approach taking now, which can result in top-level dependencies not being enforced upon lower levels. The latter is faster however. One solution would be to make the resolver pluggable. Patches welcome, on both counts. Personally, Bob and I originally wanted a full-tree intersection, too, but it turned out to be hairier to implement than it seems at first. My guess is that none of the people who want it, have actually tried to implement it without a factorial or exponential O(). But that doesn't mean I'll be unhappy if somebody succeeds. :) I think we'd make significant progress by just intersecting the dependencies we know about as we progress through the dependency tree. For example, if A requires B==2 and C==3, and if B requires C=2,=4, then at the time we install A we'd pick C==3 and also at the time we install B we'd pick C==3. As opposed to the current scheme that would choose C==4 for the latter case. This would allow dependent projects (think applications here) to better control the versions of the full set of libraries they use. Things would still fail (like they do now) if you ran across dependencies that had no intersection or if you encountered a new requirement after the target projected was already installed. If you really wanted to do a full-tree intersection, it seems to me that the problem is detecting all the dependencies without having to spend significant time downloading/building in order to find them out. This could be solved by simply extending the cheeseshop interface to export the set of requirements outside of the egg / tarball / etc. We've done this for our own egg repository by extracting the appropriate meta-data files out of EGG-INFO and putting it into a separate file. This info is also useful for users as it gives them an idea of how much *new* stuff is going to be installed (a la yum, apt-get, etc.) In other words, we attempt to achieve heuristically what's being proposed to do algorithmically. And my guess is that whatever cases the heuristic is failing at, would probably not be helped by an algorithmic approach either. But I would welcome some actual data, either way. With our ETS projects, we've run into problems with the current heuristic. Perhaps we just don't know how to make it work like we want? We have a set of projects that we want to be individually installable (to the extent that we limit cross-project dependencies) but we also want to make it easy to install the complete set. We use a meta-egg for the latter. It's purpose is only to specify the exact versions of each project that have been explicitly tested to work together -- you could almost think of it as a source control system tag. Whereas on the individual projects, we explicitly want to ensure that people get the latest possible release of each required API so the version requirements are wider here. This setup causes problems whenever we release new versions of projects because it seems easy_install ignores the meta-egg exact versions when it gets down into a project and comes across a wider cross-project dependency. We ended up having to give up on the ranges in the cross-project dependencies and synchronize them to the same values in the meta-egg dependencies. There are numerous side-effects of this that we don't like but we haven't found a way around it. Again, though, patches are welcome. :) (Specifically, for the trunk; I don't see a resolver overhaul as being suitable for the 0.6 stable branch.) We're planning to pursue this (for the above mentioned strategy) as soon as we work ourselves out of a bit of a backlog of other things to do. 2. People want a solution for the handling of documentation. The distutils module has had commented out sections related to this for several years. As with so many other things, this gets tossed around the distutils-sig every now and then. A couple of times I've thrown out some options for how this might be done, but then the conversation peters out around the time anybody would have to actually do some work on it. (Me included, since I don't have an itch that needs scratching in this area.) In particular, if somebody wants to come up with a metadata standard for including documentation in eggs, we've got a boatload of hooks by which it could be done. Nothing's stopping anybody from proposing a standard and building a tool, here. (e.g. using the setuptools command hook, .egg-info writer hook, etc.) Enthought has started an effort (it's currently one of two things in our ETSProjectTools project at
Re: [Python-Dev] [Python-checkins] r61577 - in python/trunk: Include/code.h Include/compile.h Include/parsetok.h Include/pythonrun.h Lib/__future__.py Lib/test/test_print.py Misc/ACKS Misc/NEWS Parser
This change breaks all the trunk buildbots: == ERROR: testCompileLibrary (test.test_compiler.CompilerTest) -- Traceback (most recent call last): File S:\buildbots\python\trunk.nelson-windows\build\lib\test\test_compiler.py, line 52, in testCompileLibrary compiler.compile(buf, basename, exec) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\pycodegen.py, line 64, in compile gen.compile() File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\pycodegen.py, line 112, in compile gen = ModuleCodeGenerator(tree) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\pycodegen.py, line 1275, in __init__ self.futures = future.find_futures(tree) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\future.py, line 59, in find_futures walk(node, p1) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\visitor.py, line 106, in walk walker.preorder(tree, visitor) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\visitor.py, line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\visitor.py, line 57, in dispatch return meth(node, *args) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\future.py, line 27, in visitModule if not self.check_stmt(s): File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\future.py, line 37, in check_stmt future feature %s is not defined % name SyntaxError: future feature print_function is not defined From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of eric.smith [EMAIL PROTECTED] Sent: 18 March 2008 19:45 To: [EMAIL PROTECTED] Subject: [Python-checkins] r61577 - in python/trunk: Include/code.h Include/compile.h Include/parsetok.h Include/pythonrun.h Lib/__future__.py Lib/test/test_print.py Misc/ACKS Misc/NEWSParser/parser.c Parser/parsetok.c Python/bltinmodule.c Python/future.c Pyth... Author: eric.smith Date: Wed Mar 19 00:45:49 2008 New Revision: 61577 Added: python/trunk/Lib/test/test_print.py Modified: python/trunk/Include/code.h python/trunk/Include/compile.h python/trunk/Include/parsetok.h python/trunk/Include/pythonrun.h python/trunk/Lib/__future__.py python/trunk/Misc/ACKS python/trunk/Misc/NEWS python/trunk/Parser/parser.c python/trunk/Parser/parsetok.c python/trunk/Python/bltinmodule.c python/trunk/Python/future.c python/trunk/Python/pythonrun.c Log: Backport of the print function, using a __future__ import. This work is substantially Anthony Baxter's, from issue 1633807. I just freshened it, made a few minor tweaks, and added the test cases. I also created issue 2412, which is to check for 2to3's behavior with the print function. I also added myself to ACKS. Modified: python/trunk/Include/code.h == --- python/trunk/Include/code.h (original) +++ python/trunk/Include/code.h Wed Mar 19 00:45:49 2008 @@ -48,11 +48,12 @@ #define CO_FUTURE_DIVISION 0x2000 #define CO_FUTURE_ABSOLUTE_IMPORT 0x4000 /* do absolute imports by default */ #define CO_FUTURE_WITH_STATEMENT 0x8000 +#define CO_FUTURE_PRINT_FUNCTION 0x1 /* This should be defined if a future statement modifies the syntax. For example, when a keyword is added. */ -#if 0 +#if 1 #define PY_PARSER_REQUIRES_FUTURE_KEYWORD #endif Modified: python/trunk/Include/compile.h == --- python/trunk/Include/compile.h (original) +++ python/trunk/Include/compile.h Wed Mar 19 00:45:49 2008 @@ -24,6 +24,8 @@ #define FUTURE_DIVISION division #define FUTURE_ABSOLUTE_IMPORT absolute_import #define FUTURE_WITH_STATEMENT with_statement +#define FUTURE_PRINT_FUNCTION print_function + struct _mod; /* Declare the existence of this type */ PyAPI_FUNC(PyCodeObject *) PyAST_Compile(struct _mod *, const char *, Modified: python/trunk/Include/parsetok.h == --- python/trunk/Include/parsetok.h (original) +++ python/trunk/Include/parsetok.h Wed Mar 19 00:45:49 2008 @@ -27,6 +27,10 @@ #define PyPARSE_WITH_IS_KEYWORD0x0003 #endif +#define PyPARSE_PRINT_IS_FUNCTION 0x0004 + + + PyAPI_FUNC(node *) PyParser_ParseString(const char *, grammar *, int, perrdetail *); PyAPI_FUNC(node *) PyParser_ParseFile (FILE *, const char *, grammar *, int, Modified: python/trunk/Include/pythonrun.h == --- python/trunk/Include/pythonrun.h(original) +++
Re: [Python-Dev] [Distutils] Capsule Summary of Some Packaging/Deployment Technology Concerns
We should probably move this off of Python-Dev, as we're getting into deep details now... At 07:27 PM 3/18/2008 -0500, Dave Peterson wrote: If you really wanted to do a full-tree intersection, it seems to me that the problem is detecting all the dependencies without having to spend significant time downloading/building in order to find them out. This could be solved by simply extending the cheeseshop interface to export the set of requirements outside of the egg / tarball / etc. We've done this for our own egg repository by extracting the appropriate meta-data files out of EGG-INFO and putting it into a separate file. This info is also useful for users as it gives them an idea of how much *new* stuff is going to be installed (a la yum, apt-get, etc.) ...and now we're more directly competing with them, too. The original idea Bob and I had was to do XML files ala Eclipse feature repositories, but then later I realized that for what we were doing, HTML was both adequate and already available. However, I don't see a problem in principle with having header files available for this sort of thing. With our ETS projects, we've run into problems with the current heuristic. Perhaps we just don't know how to make it work like we want? We have a set of projects that we want to be individually installable (to the extent that we limit cross-project dependencies) but we also want to make it easy to install the complete set. We use a meta-egg for the latter. It's purpose is only to specify the exact versions of each project that have been explicitly tested to work together -- you could almost think of it as a source control system tag. I would think that as long as that meta-egg specifies *all* the required versions (right down to recursive dependencies), then there shouldn't be any problem. Maybe it's me who's not understanding something? I would think that you could get the appropriate data by running the tl.eggdeps tool. A number of projects want to provide various types of files besides code in their distributable, and they'd like these to end up in standard locations for that type of file. Think documentation, sample data, web templates, configuration settings, etc. Each of these should be treated differently at installation time depending on platform. On *nix, docs should go in /usr/share/doc whereas we might need to create a C:\Python2.5\docs on Windows. With sample data and templates, you probably just want it accessible outside of the zipped egg so users can easily look at it, add to it, edit it, etc. Configuration settings should be installed with some defaults into a standard configuration directory like /etc on *nix, etc. Basically the issue is that it needs to be easier to include different sets of files into an egg for different actions to be taken during installation or packaging into an OS-specific distribution format. Yes, it would be nice to define a metadata standard for including installable datasets either through copying or symlinking, optionally with entry points for running some code, too. When you install an egg, these things could get added to a post-install to-do list, that you could then read to find out what steps to do, or invoke a tool on to actually do some of those steps. But the docs for easy_install claim that the list of active eggs is maintained in easy-install.pth. Also, if I create my own .pth file, and the user tries to update my version to a new one, will the easy_install tool modify my .pth file to remove the mention of the old version from my sys.path and put the new version in the same .pth file? Or will it now be listed in both places? Or will it only in easy-install.pth? My understanding of the context of the question was that it applied to *system* packaging tools, which would be exclusively maintaining the .pth entries for the packages they installed. i.e., a scenario with *no* easy-install.pth. Setuptools will still detect the presence of their eggs, regardless of the means by which they're added to sys.path. But it would not *maintain* those .pth files. Yes, but as you've already pointed out, they've escaped into a larger ecosystem and this restriction is a severe limitation -- leading to significant frustration. Especially as projects evolve and want to do something more complex than simply install pure Python code. Here at Enthought, we use and ship a number of projects that have extensions and thus dynamic libraries that need to either be modified during installation to work from the user's installed location, or copied elsewhere on the system to avoid the need to modify (which we also can't do via an egg install) env variables, registries, etc. By the way, there *is* experimental shared library building support in setuptools, and I recently heard from Andi Vajda that he was successful in using it in his JCC project to make available a C++ library for linkage from
Re: [Python-Dev] 3.0 buildbots all red
Sounds like a challenge if ever I've heard one -- care to wager a beer on it? (Only applies to buildbots that are connected/online.) Make sure you get a screen shot for OnYourDesktop if/when they *do* go green! Screenshot? I'm going to buy a pack of iron-on transfers and sell t-shirts of it online. All the buildbots were green momentarily after PyCon 2008... and all I got was this lousy t-shirt. Trent. ___ 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] r61577 - in python/trunk: Include/code.h Include/compile.h Include/parsetok.h Include/pythonrun.h Lib/__future__.py Lib/test/test_print.py Misc/ACKS Misc/NEWS Parser
Yes, I know, and I'm looking at it. It doesn't fail on my Linux or Mac OS X boxes. I'm trying to duplicate the problem. I'm going to try it on my Windows box when I get home in about an hour. I'll fix it tonight. I realize there's a beer riding on the buildbots being green! Eric. Trent Nelson wrote: This change breaks all the trunk buildbots: == ERROR: testCompileLibrary (test.test_compiler.CompilerTest) -- Traceback (most recent call last): File S:\buildbots\python\trunk.nelson-windows\build\lib\test\test_compiler.py, line 52, in testCompileLibrary compiler.compile(buf, basename, exec) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\pycodegen.py, line 64, in compile gen.compile() File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\pycodegen.py, line 112, in compile gen = ModuleCodeGenerator(tree) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\pycodegen.py, line 1275, in __init__ self.futures = future.find_futures(tree) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\future.py, line 59, in find_futures walk(node, p1) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\visitor.py, line 106, in walk walker.preorder(tree, visitor) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\visitor.py, line 63, in preorder self.dispatch(tree, *args) # XXX *args make sense? File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\visitor.py, line 57, in dispatch return meth(node, *args) File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\future.py, line 27, in visitModule if not self.check_stmt(s): File S:\buildbots\python\trunk.nelson-windows\build\lib\compiler\future.py, line 37, in check_stmt future feature %s is not defined % name SyntaxError: future feature print_function is not defined From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of eric.smith [EMAIL PROTECTED] Sent: 18 March 2008 19:45 To: [EMAIL PROTECTED] Subject: [Python-checkins] r61577 - in python/trunk: Include/code.h Include/compile.h Include/parsetok.h Include/pythonrun.h Lib/__future__.py Lib/test/test_print.py Misc/ACKS Misc/NEWS Parser/parser.c Parser/parsetok.c Python/bltinmodule.c Python/future.c Pyth... Author: eric.smith Date: Wed Mar 19 00:45:49 2008 New Revision: 61577 Added: python/trunk/Lib/test/test_print.py Modified: python/trunk/Include/code.h python/trunk/Include/compile.h python/trunk/Include/parsetok.h python/trunk/Include/pythonrun.h python/trunk/Lib/__future__.py python/trunk/Misc/ACKS python/trunk/Misc/NEWS python/trunk/Parser/parser.c python/trunk/Parser/parsetok.c python/trunk/Python/bltinmodule.c python/trunk/Python/future.c python/trunk/Python/pythonrun.c Log: Backport of the print function, using a __future__ import. This work is substantially Anthony Baxter's, from issue 1633807. I just freshened it, made a few minor tweaks, and added the test cases. I also created issue 2412, which is to check for 2to3's behavior with the print function. I also added myself to ACKS. Modified: python/trunk/Include/code.h == --- python/trunk/Include/code.h (original) +++ python/trunk/Include/code.h Wed Mar 19 00:45:49 2008 @@ -48,11 +48,12 @@ #define CO_FUTURE_DIVISION 0x2000 #define CO_FUTURE_ABSOLUTE_IMPORT 0x4000 /* do absolute imports by default */ #define CO_FUTURE_WITH_STATEMENT 0x8000 +#define CO_FUTURE_PRINT_FUNCTION 0x1 /* This should be defined if a future statement modifies the syntax. For example, when a keyword is added. */ -#if 0 +#if 1 #define PY_PARSER_REQUIRES_FUTURE_KEYWORD #endif Modified: python/trunk/Include/compile.h == --- python/trunk/Include/compile.h (original) +++ python/trunk/Include/compile.h Wed Mar 19 00:45:49 2008 @@ -24,6 +24,8 @@ #define FUTURE_DIVISION division #define FUTURE_ABSOLUTE_IMPORT absolute_import #define FUTURE_WITH_STATEMENT with_statement +#define FUTURE_PRINT_FUNCTION print_function + struct _mod; /* Declare the existence of this type */ PyAPI_FUNC(PyCodeObject *) PyAST_Compile(struct _mod *, const char *, Modified: python/trunk/Include/parsetok.h == --- python/trunk/Include/parsetok.h (original) +++ python/trunk/Include/parsetok.h Wed Mar 19 00:45:49 2008 @@ -27,6 +27,10 @@ #define PyPARSE_WITH_IS_KEYWORD0x0003 #endif +#define
Re: [Python-Dev] Python 3000: Special type for object attributes map keys
Neal Norwitz wrote: Part of this is done, but very differently in that all strings used in code objects are interned (stored in a dictionary And since two interned strings can be compared by pointer identity, I don't see how this differs significantly from the unique integer idea. If the integers were used to directly index an array instead of being used as dict keys, it might make a difference. The cost would be that every namespace would need to be as big as the number of names in existence, with most of them being extremely sparse. -- Greg ___ 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] r61577 - in python/trunk: Include/code.h Include/compile.h Include/parsetok.h Include/pythonrun.h Lib/__future__.py Lib/test/test_print.py Misc/ACKS Misc/NEWS Parser
I see the problem. Without -ucompiler, test_compiler doesn't compile everything. I'll fix the breakage shortly. Apologies. Eric Smith wrote: Yes, I know, and I'm looking at it. It doesn't fail on my Linux or Mac OS X boxes. I'm trying to duplicate the problem. I'm going to try it on my Windows box when I get home in about an hour. I'll fix it tonight. I realize there's a beer riding on the buildbots being green! Eric. Trent Nelson wrote: This change breaks all the trunk buildbots: == ERROR: testCompileLibrary (test.test_compiler.CompilerTest) -- ___ 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] PyErr_Warn or PyErr_WarnEx
Now that we're aggressively adding Py3k warnings to the trunk, I think it's a good time to get this straightened out. The docs [1] say PyErr_Warn is deprecated in favor of PyErr_WarnEx. However, I have seen both in recent checkins. What is preferred? [1] http://docs.python.org/dev/c-api/exceptions.html Cheers, Benjamin Peterson ___ 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] PEP 3127 (Integer Literal Support and Syntax): %o and %b
I've been double checking the PEP 3127 implementation in py3k and the backport I did to 2.6. The PEP says this about the % operator: The string (and unicode in 2.6) % operator will have 'b' format specifier added for binary, and the alternate syntax of the 'o' option will need to be updated to add '0o' in front, instead of '0'. The %b operator was not added to 3.0, so I'll look into doing that in both 2.6 and 3.0 (which I opened as issue 2416). What should be done for '%#o' formatting in 2.6? The above sentence from the PEP implies it should be modified to add '0o' instead of '0', even in 2.6. But that seems like a bad idea to me. Maybe it should stay as-is, but add a -3 warning? Unfortunately, there'd be no way to change your code to get rid of the warning, short of switching to str.format() or adding a __future__ import (shudder). In 3.0, '%#o' already adds the leading '0o'. ___ 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] PyErr_Warn or PyErr_WarnEx
On Tue, Mar 18, 2008 at 10:07 PM, Benjamin Peterson [EMAIL PROTECTED] wrote: Now that we're aggressively adding Py3k warnings to the trunk, I think it's a good time to get this straightened out. The docs [1] say PyErr_Warn is deprecated in favor of PyErr_WarnEx. However, I have seen both in recent checkins. What is preferred? PyErr_WarnEx should be used. PyErr_Warn is just (see from Include/pyerrors.h): #define PyErr_Warn(category, msg) PyErr_WarnEx(category, msg, 1) If someone wants to remove the macro in 3k, go for it. There are many of these compatibility macros and stub functions left around for binary compatibility. We should try to get rid of those in 3k and shrink the API. n ___ 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] changing regrtest to handle import errors
Neal Norwitz wrote:
[changing to: and subject: ]
On Tue, Mar 18, 2008 at 4:09 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Tue, Mar 18, 2008 at 3:58 PM, neal.norwitz
[EMAIL PROTECTED] wrote:
Get this test to pass (UserList/UserDict no longer exist and caused a
skip).
I think the automatic skip on ImportError is harmful.
We should add a helper function to test_support so that you can write
foobar = test_support.import_optional('foobar')
and it will skip the test if foobar cannot be imported; all other
failing imports should cause the test to *fail*.
Any takers? This should be an easy two-part task.
This would be a great starter project for a new developer.
http://bugs.python.org/issue2409
Let me know if you could use some help. Feel free to contact me on or off
list.
n
This is available in the form of four patches on
http://bugs.python.org/issue2409.
The first adds test_support.optional_import, which I now see is the opposite of
Guido's suggestion (blame the dyslexia). I actually prefer optional_import,
though, since it puts 'import' next to the imported name, but I can add a fix if
it's a problem.
The next two patches refactor the imports of test_{sunaudiodev,winreg}.py to
make the imports easier to work with in the new scheme.
The last patch fixes the stdlib tests to use optional_import at the spots where
I was getting ImportErrors on my box (x86 Linux).
Please test these on your boxes so we can discover all the ImportErrors before
the buildbots do.
Thanks,
Jeff Balogh
___
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] Not backporting PEP 3115 (metaclass __prepare__)
We can't backport the __prepare__ syntax without requiring metaclass definition on the 'class' line. Because the __metaclass__ definition can be at the end of the class in 2.6 we can't find it until after we execute the class and that is too late to use a custom dictionary. I wish I had thought of that yesterday, -Jack ___ 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
