Re: [Python-Dev] Py_ssize_t support for ctypes arrays and pointers
Trent Nelson schrieb: On Fri, Mar 20, 2009 at 08:00:46PM +0100, Thomas Heller wrote: Since I do not have a machine with so much memory: Does one of the buildbots allow to run tests for this feature, or do I have to wait for the snakebite farm? Will you be at PyCon? The wait might not be as bad as you think ;-) No, I will not. But I've heard some rumors... -- Thanks, 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] Multiprocessing on Solaris
Sorry, I mistakenly said without issue and then copied the issues below. I meant to say not without issues. _multiprocessing does *not* build on Solaris 8. Hmm. They are all warnings - did you omit the actual error message? The lack of CMSG_LEN seems to suggest that control messages are not supported on Solaris 8, or that you need to include an additional header file to get them. Is Solaris 8 really a supported platform? If so, I can investigate the changes he suggested. The concept of supported platform doesn't really exist - there is no way to obtain support. If it works, it works, if it doesn't, it doesn't. So if you want it fixed, provide a patch - else we can drop the issue. I think multiprocessing is misguided in hard-coding these settings into setup.py. As we can see, the necessary features are available on some versions of Solaris, but not on others. It would be better if autoconf tests were written, and the entire configuration removed from setup.py. 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] GSoC: Replace MS Windows Console with Unicode UI
2) IDLE does much better but its support seems to still be imcomplete. Upgrade tk/tkinter/IDLE (wherever the problems lie) and make IDLE's shell an alternate UI. That is certainly *no* good SoC project. Instead, just report it as a *specific* bug report (rather than saying it seems incomplete). 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] Multiprocessing on Solaris
Martin v. Löwis wrote: Sorry, I mistakenly said without issue and then copied the issues below. I meant to say not without issues. _multiprocessing does *not* build on Solaris 8. Hmm. They are all warnings - did you omit the actual error message? The lack of CMSG_LEN seems to suggest that control messages are not supported on Solaris 8, or that you need to include an additional header file to get them. Sorry, I was trying to keep the amount of noise to a minimum, but those particular implicit function declarations ultimately lead to linking errors for lack of those same symbols: *** WARNING: renaming _multiprocessing since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.7/_multiprocessing.so: symbol CMSG_SPACE: referenced symbol not found Is Solaris 8 really a supported platform? If so, I can investigate the changes he suggested. The concept of supported platform doesn't really exist - there is no way to obtain support. If it works, it works, if it doesn't, it doesn't. So if you want it fixed, provide a patch - else we can drop the issue. I have no personal interest in the matter. I just happened to have access to an older Solaris just for this sort of testing. If someone has a patch, then I would be glad to test it, but otherwise, I am not going to invest any time on this. The patch given by the OP is clearly undesirable since status quo works just fine for a modern Solaris install. I think multiprocessing is misguided in hard-coding these settings into setup.py. As we can see, the necessary features are available on some versions of Solaris, but not on others. It would be better if autoconf tests were written, and the entire configuration removed from setup.py. I agree, but I am not familiar enough with the set of features that multiprocessing is implicitly depending on and how to test for them on all of the platforms. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] GSoC: Core Python development tools
C. Titus Brown wrote: On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote: I do think you should be prepared for pushback from python-dev on any such ideas ;). Don't get too ambitious about writing up *your* way of fixing things, but rather make sure you and the students are prepared to adapt to what people on python-dev think. Mind you, ultimately the people doing the work should make the decisions, but input from python-dev is usually pretty useful even when it's contradictory! Everything I've seen from Daniel so far seems to be about either making things we already do more efficient, or else providing additional features in ways that don't make the tools any more confusing for others already used to a particular way of doing things. So he seems to be navigating this particular minefield pretty well so far. Then again, I may be a little biased - some of the recent bug tracker changes are things I had wished for in the past, but never chipped in any code to help make them happen :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue workflow doc is now live
Brett Cannon wrote: I sent this out as a Google Doc a while back, but I just did a proof-reading, converted it, and pushed it live to the python.org http://python.org: http://www.python.org/dev/workflow/ . So now people who ever triage issues have a guide to follow if they are not sure how to set things. Does that mean PEP 3 should be Withdrawn or does it mean it should be replaced? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue workflow doc is now live
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 23, 2009, at 8:31 AM, Nick Coghlan wrote: Brett Cannon wrote: I sent this out as a Google Doc a while back, but I just did a proof-reading, converted it, and pushed it live to the python.org http://python.org: http://www.python.org/dev/workflow/ . So now people who ever triage issues have a guide to follow if they are not sure how to set things. Does that mean PEP 3 should be Withdrawn or does it mean it should be replaced? It should probably be replaced with Brett's document. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSceCZXEjvBPtnXfVAQKMoQQApOowWiXtfS9p1+barzrEwbFJ89tE3Tmy LW14lbgDxMXc+nx/Y1z+0L8r8eRThrbuiLr8qtM7VWiEmlUz8msHovNL6AR+oppy lyAk8ex9sc/GAnZXQ6i3b2FBo1evHr3zbQzUgcbNlVW1iyLsjGPUiG0Ay2A+AmyM ZWJXGCbJ89g= =PuKR -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] Integrate BeautifulSoup into stdlib?
Tres Seaver wrote: Given that the out-of-the-box Python install already has facilities for retrieving text over the net and executing that text, the notion of locking down a machine to include only the bits installed in the stock Python install is just security theatre; such a machine shouldn't have Python installed at all (nor a C compiler, etc.) Indeed, in the real world this locking down is done at the firewall level. As for packaging in this scenario, that's what private package servers are for... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Integrate BeautifulSoup into stdlib?
Lie Ryan wrote: Some companies have /very/ strict policies on running anything on live server, including scripts you write yourself. The problem is if the script goes awry, it might disturb the stability or even security of the server. Yes, we as a profession right software and have responsibilities. Get over it. It's what dev servers, uat, backups and dr are for... I see no relation between this and packaging other than that any packaging story needs to support privtae distribution servers. When the server administrator is already freaked out about adding an script developed by in-house employee, what about adding an external module? Then he's a muppet, plain and simple. If he's not, then he will have tested the whole setup before hand and got signoff from the developers and users who are responsbile for doing so. All of this has very little to do with packaging. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] packaging (was Integrate BeautifulSoup into stdlib?)
Nick Coghlan wrote: Network connectivity isn't a given, even today. Indeed, now that is an important consideration. Packaging systems need to support offline modes. Buildout already does... If someone else decides to create a MinimalPython which consists solely of something like easy_install and whatever is needed to run it (i.e. the opposite of the fat bundles from folks like ActiveState and Enthought), then more power to them. But I don't believe the official releases from python.org should go that way. My frustration is that some of the big standard libraries are locked to python releases meaning they carry around bugs for longer and are harder to contribute to than necessary... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Integrate BeautifulSoup into stdlib?
Paul Moore wrote: I am not. What I *am* doing is saying (obliquely, I admit) is that for a package management system to be decent enough for stripping down the stdlib to not be an issue, it has to address these points (which clearly it can't). Sure it can, either by supporting offline bundles or by having sets of packages that are marked as Python Approved! or some such and so all have the same license. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Integrate BeautifulSoup into stdlib?
R. David Murray wrote: I disagree. One of the jobs I've had is release management for internal software projects that depend on various external pieces. Release integration tested against specific versions of those external packages, and those were the packages that needed to wind up on the system when the release was installed. I've done systems depending on both perl and python, and let me tell you, python is way, _way_ easier to manage. With python, I have a dependency on a particular python version, and then maybe one or two add on packages. Well, python already has tools available to do exactly this.: buildout from a private egg repository will do exactly what you're after. However, its built on top of setuptools, which is flawed, and it's not blessed as official core python, so there's lots of room for improvement! Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] packaging (was Integrate BeautifulSoup into stdlib?)
Chris Withers wrote: Nick Coghlan wrote: Network connectivity isn't a given, even today. Indeed, now that is an important consideration. Packaging systems need to support offline modes. Buildout already does... If someone else decides to create a MinimalPython which consists solely of something like easy_install and whatever is needed to run it (i.e. the opposite of the fat bundles from folks like ActiveState and Enthought), then more power to them. But I don't believe the official releases from python.org should go that way. My frustration is that some of the big standard libraries are locked to python releases meaning they carry around bugs for longer and are harder to contribute to than necessary... Possibly so, but there are conflicting requirements and Python can't satisfy them all without getting more complex. Some people want an all batteries and kitchen sink included distro that they can treat as a single component for configuration control purposes. Others, like you, want the libraries to be separated out to allow separate fixes. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
Martin v. Löwis wrote: In some environments, each new component must be approved. Once python is approved, the standard library is OK, but adding 7 packages from pypi requires 7 more sets of approvals. True, but as I mentioend elsewhere, I myself haven't done a python project where I only needed python and the standard lib for many years... I was always able to get what I need through aptitude. Yes, well known for its ability to run on Windows and Mac OS... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Integrate BeautifulSoup into stdlib?
Trent Mick wrote: Apologies for jumping in mid-thread here. FYI: We're (where we == ActiveState here) looking at spending more effort on Python of late. Some of our thoughts are on add modules: whether added to the ActivePython core or easily addable via an equivalent to ActivePerl's ppm (package manager) is still be batted around. Buildout is the closest thing python has to sanity at the moment. I'm curious as to people's thoughts. I'll also be at PyCon in Chicago getting thoughts. I'll be there, look forward to it. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Multiprocessing on Solaris
Martin v. Löwis wrote: I think multiprocessing is misguided in hard-coding these settings into setup.py. As we can see, the necessary features are available on some versions of Solaris, but not on others. It would be better if autoconf tests were written, and the entire configuration removed from setup.py. I guess multiprocessing doesn't use autoconf tests for historical reasons. It's ancestor -- the pyprocessing package -- was using hard coded values, too. I've started with a autoconf file for the multiprocessing backport package. The tests should produce the same set of definitions but I'm not able to test it on different platforms expect Linux. http://python-multiprocessing.googlecode.com/svn/trunk/configure.ac 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] packaging (was Integrate BeautifulSoup into stdlib?)
Steve Holden wrote: Some people want an all batteries and kitchen sink included distro that they can treat as a single component for configuration control purposes. Others, like you, want the libraries to be separated out to allow separate fixes. Yes, but while the batteries included option can be rolled from the no batteries version, the reverse is not true. The current package management systems can't even figure out that a version of a standard lib library is what came with Python 2.x.y rather than a bugfixed version that's been later installed (pyunit springs to mind as a potential candidate here...) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Multiprocessing on Solaris
On Mon, Mar 23, 2009 at 10:31 AM, Christian Heimes li...@cheimes.de wrote: Martin v. Löwis wrote: I think multiprocessing is misguided in hard-coding these settings into setup.py. As we can see, the necessary features are available on some versions of Solaris, but not on others. It would be better if autoconf tests were written, and the entire configuration removed from setup.py. I guess multiprocessing doesn't use autoconf tests for historical reasons. It's ancestor -- the pyprocessing package -- was using hard coded values, too. I've started with a autoconf file for the multiprocessing backport package. The tests should produce the same set of definitions but I'm not able to test it on different platforms expect Linux. http://python-multiprocessing.googlecode.com/svn/trunk/configure.ac Christian Christian is correct, it's purely for historical reasons. I have no particular stake in keeping it as is other than the fact that there are higher priorities in the bug queue (and improving the tests) than the build functionality. Christian - I would appreciate it if we could coordinate/track this on the tracker too - I had no idea you were doing this in the back port, and I don't think we want the two code bases to diverge that much. This is definitely something which could be hacked on during the sprints though. There's been a lot of movement in the *BSD space around defining these values and providing the faculties needed for mp to work. -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
On Mon, Mar 23, 2009 at 10:26:54PM +1000, Nick Coghlan wrote: - C. Titus Brown wrote: - On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote: - I do think you should be prepared for pushback from python-dev on any - such ideas ;). Don't get too ambitious about writing up *your* way of - fixing things, but rather make sure you and the students are prepared to - adapt to what people on python-dev think. Mind you, ultimately the - people doing the work should make the decisions, but input from - python-dev is usually pretty useful even when it's contradictory! - - Everything I've seen from Daniel so far seems to be about either making - things we already do more efficient, or else providing additional - features in ways that don't make the tools any more confusing for others - already used to a particular way of doing things. So he seems to be - navigating this particular minefield pretty well so far. - - Then again, I may be a little biased - some of the recent bug tracker - changes are things I had wished for in the past, but never chipped in - any code to help make them happen :) Oh, I heartily endorse his suggestions! I just want to make sure that we make maximum use of students (and their code doesn't get tossed at the end of the summer, which has serious morale consequences ;) --t -- C. Titus Brown, c...@msu.edu ___ 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] GSoC: Core Python development tools
Oh, I heartily endorse his suggestions! I just want to make sure that we make maximum use of students (and their code doesn't get tossed at the end of the summer, which has serious morale consequences ;) This is my concern as well. One of my past students pitched a core project and ended up spending most of his SoC time in the PEP process (http://www.python.org/dev/peps/pep-0368/). Given how frustrating the experience was for him, I'd rather have future SoC students be able to focus on code. Let's at least have rough consensus on brainstormed ideas before they hit the ideas page. Existing PEPs that have had a time to air and evolve are much better for this reason. ___ 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] Multiprocessing on Solaris
Jesse Noller wrote: Christian - I would appreciate it if we could coordinate/track this on the tracker too - I had no idea you were doing this in the back port, and I don't think we want the two code bases to diverge that much. You could not have known about the idea because I started the experiment about an hour ago. ;) I needed a playground to test and save the files of the experiment. The multiprocessing backport sounded like a good place. 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] Integrate BeautifulSoup into stdlib?
2009/3/23 Chris Withers ch...@simplistix.co.uk: Paul Moore wrote: I am not. What I *am* doing is saying (obliquely, I admit) is that for a package management system to be decent enough for stripping down the stdlib to not be an issue, it has to address these points (which clearly it can't). Sure it can, either by supporting offline bundles or by having sets of packages that are marked as Python Approved! or some such and so all have the same license. OK, I'll drop out of the discussion at this point. We clearly have such different experience that we aren't understanding each others' points - and the misunderstandings aren't moving the discussion forwards. 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
[Python-Dev] speeding up PyObject_GetItem
In Python 2.5, list objects were special-cased to skip PyObject_GetItem and go straight to PyList_GET_ITEM. That special case gave made other sequences 20% slower than lists for getitem operations. The special case was removed in Python 3 (haven't checked 2.6). Today I was tracing through how PyObject_GetItem works, trying to figure it why it's so much slower, to see if we can get back some of that speed without special-casing just one type. Below is a rough sketch of what PyObject_GetItem does for the common case of a sequence with a valid positive integer parameter, and my observations on where there is room for improvement. I'm willing to write patches and test them, but I wanted to get some general feedback first. After all, it may be the way it is for A Very Good Reason that I'm not aware of. ;-) The code paths for PyObject_SetItem and PyObject_DelItem are essentially the same, so any speed improvments to one could easily be applied to the other two operations. PyObject_GetItem ob i ob==NULL # can't be null anyway i==NULL # can't be null anyway is mapping? ob is sequence? ob PyIndex_Check i tp_as_number i tp_flags i tp_as_number-nb_index i PyNumber_AsSsize_t i PyNumber_Index i i==NULL # still can't be null PyLong_Check i i==NULL # still can't be null PyLong_Check i # redundant = v v == -1 PySequence_GetItem ob v ob==NULL # still can't be null is sequence? ob# redundant sq_item? ob sq_item ob v I think there are two avenues for speed improvement, both of which involve removing redundancy: 1) Assume the index is a PyLong until proven otherwise The PyIndex_Check in PyObject_GetItem looks pretty useless. If it returns false, PyObject_GetItem throws a type error. If we skipped the PyIndex_Check when it would have returned false, PyNumber_AsSsize_t would later call PyIndex_Check and throw a type error. Unless I'm missing something, this is a clear win and makes the code simpler. In PyNumber_AsSsize_t, we could speed up the common case by trying PyLong_Check first, and if it fails then calling PyNumber_Index. This change would make the common case faster, but make the code a few lines longer. 2) Remove some of the exessive checking for NULL unless Py_DEBUG is defined Many of the routines in abstract.c check their parameters for NULL, as a sanity check, and throw a SystemError if NULL is detected. I'm tempted to suggest making these checks only when Py_DEBUG is defined, but I suspect if you wanted it that way, you would have changed it already. ;) Assuming you really want the NULL checks in production Python, there are 5 checks for NULL even though there are only two parameters. Seems like overkill? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.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] Integrate BeautifulSoup into stdlib?
Chris Withers chris at simplistix.co.uk writes: Well, python already has tools available to do exactly this.: buildout from a private egg repository will do exactly what you're after. However, its built on top of setuptools, which is flawed, and it's not blessed as official core python, so there's lots of room for improvement! Could you explain how buildout is an improvement over other systems? Its documentation seems full of generic wording (parts etc.) that I can't make sense of. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Non-Core project: IDLE
On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy tjre...@udel.edu wrote: IDLE needs lots of attention -- more than any one experienced person is likely to have I'm willing to step up as a student for this but I still have to write a good proposal for it. My actual concern is about mentor availability, is someone around interested on being an IDLE mentor ? Regards, -- -- Guilherme H. Polo Goncalves ___ 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] GSoC: Replace MS Windows Console with Unicode UI
Glenn Linderman wrote: One can set CMD into Unicode mode (chcp 65001)... not sure how Python reacts to that either. But even then... I tried that and others have reported doing so on python-list but no one has gotten that to work. CMD will only use fixed-width fonts, and none of the standard XP ones seem to contain all of Unicode. Not sure if that has improved on Vista or 7, as they don't run here. It _would_ be nice to get this resolved, somehow. Definitely. tjr ___ 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] Integrate BeautifulSoup into stdlib?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Antoine Pitrou wrote: Chris Withers chris at simplistix.co.uk writes: Well, python already has tools available to do exactly this.: buildout from a private egg repository will do exactly what you're after. However, its built on top of setuptools, which is flawed, and it's not blessed as official core python, so there's lots of room for improvement! Could you explain how buildout is an improvement over other systems? Its documentation seems full of generic wording (parts etc.) that I can't make sense of. It has a couple of differentiators from a stock distutils or setuptools-based installation: - Distributions are compiled and installed as eggs, but in a directory which is neither on the sys.path nor one of those marked as a 'site' directory. zc.buildout *does* use the dependency information, if present in setup.py, to fetch dependent distributions (like easy_install with the --multi-version option). - Scripts generated from the eggs get a generated prologue which sets up the sys.path expressing the requirements spelled out for that script. - It externalizes much of the how to build it information out of 'setup.py' into a separate INI-style configuration file, - It uses recipes as extensions, which enable a lot of tasks which are unsupported or poorly supported by distutils / setuptools (e.g., installing non-Python software using configure-make-make install, generating config files, etc.) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJx9+q+gerLs4ltQ4RAlheAJ0Wq98Q3+SwgeaZthN2FrVYLyle2wCg3NiG QX6ojgLlSmBJY1g48gMLimM= =pkMq -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] GSoC: Core Python development tools
C. Titus Brown wrote: Given the relative paucity of core Python GSoC ideas, I think you should go for both of these, *especially* if you have a mentor up front. So, write 'em up, add 'em to the GSoC page, and let's see who we get... If we get good applications for both, then I think we can fund both of them. Great, thanks a lot for the feedback :) I do think you should be prepared for pushback from python-dev on any such ideas ;). Don't get too ambitious about writing up *your* way of fixing things, but rather make sure you and the students are prepared to adapt to what people on python-dev think. Mind you, ultimately the people doing the work should make the decisions, but input from python-dev is usually pretty useful even when it's contradictory! Pushback? Luxury! :) Thanks for the great advice, but I'd actually love negative input on this. Better to find out early that there's no way out of the bikeshedding tar pit than to waste a slot (and the student's time). I think many people don't speak up for or against GSoC proposals because they don't have time to mentor / discuss details. This particular proposal is doomed if nobody voices the itches to be scratched. So I'm kinda taunting python-dev with a huge proposal that goes around generalities and tries to make the case for joining efforts with PIDA ;) Skipping to Suggestions and the Food for thought example might help in deciding whether the wall of text is worth a look... Best regards, Daniel == Helper Python core development tools. There's some amount of repetitive, required steps to work on Python development. This proposal is about improving the workflow of core developers, probably with small glue scripts. As each developer has his own personal workflow, these helper scripts should be optional, easy to extend and aimed at the most common tasks. Of course, there may be no real demand for optimizing the workflow. Avoiding the use of a GSoC slot for unnecessary projects is very important, so if you think it's a wast of resources, please speak up :) Justification Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development. Other obvious steps, like handling issue properties (e.g. Resolution), posting a message that tells in which revs the issue was fixed of or even checking for changes in tabs versus spaces, also require a bit of time. Regardless of obviousness, forgetting one item (or getting it wrong) in the development checklist happens from time to time. If there are ways to factor these repetitive, required tasks out from a core dev's concerns, it can only help the development process. Non-code developers could also benefit from this kind of tool, and could contribute in a more efficient way to Python development, with higher code/ticket quality. Quoting the tracker cleanup proposal: Optimizing the application of main/core developers' time to Python issues is a no-brainer. Being able to add volunteers to the productive time pool is also very desirable. Pre-Requisites Identifying which tasks and steps should be optimized cannot be left to the student nor to the mentor, it must be a collective effort. Clear goals must be set before someone try to implement them. Sure, there are many descriptions of workflows in past python-dev (and python-list) threads, but the GSoC is about code. Methods It's up to the mentors/student team. I suggest offering early releases for the scripts and maybe test repositories, trackers, Rietveld instance, etc., as ways of making sure the resulting code will be useful and used by the target public. I believe most tools should be developed in a generic way, so that they could fit in other projects and workflows. IMHO, this would make the resulting scripts much more valuable. Student Besides some experience with Python and tools of the trade (VCSs, bug trackers, etc.), the most important requisite is being able to listen to the community and taking criticism well. Mentors Ali Afshar from PIDA is willing to mentor if the 'generic tools' way is accepted. Since it's about reusing development tools inside an IDE, any of these helper scripts could be integrated into PIDA, the only pre-requisite being that they'd not be too deeply linked to the Python infrastructure. With a small bit of concern about this, it'd be easy to extend/fork the resulting tools to use with other trackers, VCSs, test runners and code review tools. I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way. At least one core Python developer should mentor, preferably one that knows how to interact well with python-dev. Any project focused on how people work is prone to flamefests, so diverting most heat away from the student might be a necessary skill.
Re: [Python-Dev] GSoC: Core Python development tools
Daniel (ajax) Diniz ajaksu at gmail.com writes: Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development. Well, really, rather than trying to improve svnmerge, we should try to find a way forward to switch to Merc... oops, I mean what will turn out to be the best DVCS for our needs :-) I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way. Food for thought example (sorry, not quite how a core dev works): [...] SVN exporting current working copy to: ../month_delta Does it work when using an hg/bzr/git mirror? There's already hg and git support in Rietveld's upload.py, so this should be possible. ___ 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] GSoC: Core Python development tools
Thanks for the feedback, Antoine! Antoine Pitrou wrote: Daniel (ajax) Diniz ajaksu at gmail.com writes: Sometimes, non-obvious bits like the right sequence of svnmerge commands, the right way to link a Rietveld code review to a given issue or checking for correct autoconf version might get in the way of real development. Well, really, rather than trying to improve svnmerge, we should try to find a way forward to switch to Merc... oops, I mean what will turn out to be the best DVCS for our needs :-) That was a little bait for input ;) But the real point is that, regardless of underlying VCS, there is a choice between having all core developers know by heart the right switches and order of steps to correctly checkout/update -( branch locally) - fix - diff - commit - merge - solve conflicts and offering a little, well-documented script that takes care of the switches and sequence of steps. Maybe a 'untangle svnmerge-created history' tool would help too? :) I am also available to help with the Python workflow part, and there's an early effort to integrate Rietveld and our bug tracker under way. Food for thought example (sorry, not quite how a core dev works): [...] SVN exporting current working copy to: ../month_delta Does it work when using an hg/bzr/git mirror? There's already hg and git support in Rietveld's upload.py, so this should be possible. Given that the pyfix script is completely imaginary ATM, yes, it works as well with hg/bzr/git/perforce/CVS/darcs as it does with SVN :) In a more serious note, the PIDA offer puts anyvc[1] on the table. So we could support different VCSs as upload.py does it, or aim for a more pluggable way, probably based on anyvc. Either way, them scripts should be simple and follow the Unix way, so e.g. pyfix --export would actually call anyvc --export or pyvcs --export. Cheers, Daniel [1] http://pypi.python.org/pypi/anyvc ___ 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] GSoC: Core Python development tools
Hi, Daniel (ajax) Diniz ajaksu at gmail.com writes: But the real point is that, regardless of underlying VCS, there is a choice between having all core developers know by heart the right switches and order of steps to correctly checkout/update -( branch locally) - fix - diff - commit - merge - solve conflicts and offering a little, well-documented script that takes care of the switches and sequence of steps. Well, it seems to me that most of these steps are separated by manual intervention (e.g. compile and run the test suite to check that everything works smoothly), so there's no real point in making a script out of them. The real issues with svnmerge are its occasional bugs or failures (it forgot some changesets when merging in the io-c branch!), its slowness, and its limitations (which are really inherent to the SVN model: e.g., if someone commits to the branch you have just started doing an svnmerge to, you have to revert everything and start over with the latest updates). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
On Mon, Mar 23, 2009 at 5:03 PM, Antoine Pitrou solip...@pitrou.net wrote: Hi, Daniel (ajax) Diniz ajaksu at gmail.com writes: But the real point is that, regardless of underlying VCS, there is a choice between having all core developers know by heart the right switches and order of steps to correctly checkout/update -( branch locally) - fix - diff - commit - merge - solve conflicts and offering a little, well-documented script that takes care of the switches and sequence of steps. Well, it seems to me that most of these steps are separated by manual intervention (e.g. compile and run the test suite to check that everything works smoothly), so there's no real point in making a script out of them. The real issues with svnmerge are its occasional bugs or failures (it forgot some changesets when merging in the io-c branch!), Any chance you were not using the latest svnmerge when you did that merge ? I've had problems like this when using older versions. its slowness, and its limitations (which are really inherent to the SVN model: e.g., if someone commits to the branch you have just started doing an svnmerge to, you have to revert everything and start over with the latest updates). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves ___ 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] GSoC: Core Python development tools
Guilherme Polo ggpolo at gmail.com writes: Any chance you were not using the latest svnmerge when you did that merge ? I've had problems like this when using older versions. Well, actually, Benjamin did the merge, so perhaps he can give more info. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
2009/3/23 Antoine Pitrou solip...@pitrou.net: Guilherme Polo ggpolo at gmail.com writes: Any chance you were not using the latest svnmerge when you did that merge ? I've had problems like this when using older versions. Well, actually, Benjamin did the merge, so perhaps he can give more info. I was using the latest svnmerge.py from the SVN trunk. (maybe it's broken?) -- Regards, Benjamin ___ 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] Non-Core project: IDLE
Guilherme Polo wrote: On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy tjre...@udel.edu wrote: IDLE needs lots of attention -- more than any one experienced person is likely to have I'm willing to step up as a student for this but I still have to write a good proposal for it. My actual concern is about mentor availability, is someone around interested on being an IDLE mentor ? If I could, I would, and would have said so. But I have only read about tk and have not actually used it. If I did decide to dive into it, you'd be mentoring me ;-). What I can and would do is give ideas for changes, read and comment on a proposal, and user test patched versions. Terry ___ 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 PEP consistent aliases for names that don't currently conform
On Tue, Mar 3 at 19:25:21 Guido van Rossum gu...@python.org wrote: On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote: On Tue, Mar 3, 2009 at 05:13, rdmur...@bitdance.com wrote: On Tue, 3 Mar 2009 at 06:01, Ivan Krsti?~G wrote: On Mar 2, 2009, at 7:08 PM, Steve Holden wrote: ?PS.: so is datetime.datetime a builtin then? :) ?Another historic accident. Like socket.socket. :-( ?A pity this stuff wasn't addressed for 3.0. Way too late now, though. A pity indeed. It may be too late to rename the existing accidents, but why not add consistently-named aliases (socket.Socket, datetime.DateTime, etc) and strongly encourage their use in new code? Or make the old names aliases for the new names and start a PendingDeprecationWarning on the old names so they can be switched in the distant future? +1, if it's not done in a rush and only for high-visibility modules -- let's start with socket and datetime. We need a really long lead time before we can remove these. I recommend starting with a *silent* deprecation in 3.1 combined with a PR offensive for the new names. I've uploaded a patch for the datetime module with respect to this issue at http://bugs.python.org/issue5530 . I would appreciate it if experienced developers could take a look at it and provide some feedback. Since I've only been hacking on CPython for about a month, please be kind! I'm happy to make changes to this. As it stands now, the patch changes the current objects to have CapWords names, and subclasses these objects to provide objects with the old names. Use of methods (including __new__) of the derived objects causes PendingDeprecations (if one has warning filters appropriately set). A warning: this patch requires the patch to the test refactoring at Issue 5520 to completely apply. It will fail one test without the patch at Issue 5516. Both of these are (inexpertly) linked from the roundup page for this issue. I hope this will be helpful. cheers, Jess Austin ___ 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] Integrate BeautifulSoup into stdlib?
In some environments, each new component must be approved. Once python is approved, the standard library is OK, but adding 7 packages from pypi requires 7 more sets of approvals. True, but as I mentioend elsewhere, I myself haven't done a python project where I only needed python and the standard lib for many years... I was always able to get what I need through aptitude. Yes, well known for its ability to run on Windows and Mac OS... Is it? I had never heard before that aptitude works well on Windows (although it does work on OSX). In any case, I rarely need to install Python packages on Windows or Mac, so this causes no problem to me. If I need something on Windows, I usually download the Windows installer for 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] speeding up PyObject_GetItem
Daniel Stutzbach wrote: 1) Assume the index is a PyLong until proven otherwise The PyIndex_Check in PyObject_GetItem looks pretty useless. If it returns false, PyObject_GetItem throws a type error. If we skipped the PyIndex_Check when it would have returned false, PyNumber_AsSsize_t would later call PyIndex_Check and throw a type error. Unless I'm missing something, this is a clear win and makes the code simpler. In PyNumber_AsSsize_t, we could speed up the common case by trying PyLong_Check first, and if it fails then calling PyNumber_Index. This change would make the common case faster, but make the code a few lines longer. If this part can be done without losing any of the information currently in the error messages, then it sounds like a decent idea. 2) Remove some of the exessive checking for NULL unless Py_DEBUG is defined Many of the routines in abstract.c check their parameters for NULL, as a sanity check, and throw a SystemError if NULL is detected. I'm tempted to suggest making these checks only when Py_DEBUG is defined, but I suspect if you wanted it that way, you would have changed it already. ;) Assuming you really want the NULL checks in production Python, there are 5 checks for NULL even though there are only two parameters. Seems like overkill? The main problem is that many of these methods are not only used internally, but are *also* part of the public C API made available to extension modules. We want misuse of the latter to trigger exceptions, not segfault the interpreter. In theory you *could* create dual versions of the APIs, one without the NULL check for internal use and one with the NULL check for the public API, but that would get unmaintainable pretty fast (not to mention speeding up the internal calls at the expense of potentially slowing down calls from extension modules). Redundant NULL checks within a single function are more promising candidates for removal, but I don't believe that is happening here. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Multiprocessing on Solaris
I've started with a autoconf file for the multiprocessing backport package. The tests should produce the same set of definitions but I'm not able to test it on different platforms expect Linux. http://python-multiprocessing.googlecode.com/svn/trunk/configure.ac If you want to see how it fares on the various systems which we have build slaves for, feel free to create a branch, and then manually ask the slaves to build branches/yourbranch. Or, just commit it into the trunk, and see how it does. 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] GSoC: Replace MS Windows Console with Unicode UI
On approximately 3/23/2009 12:12 PM, came the following characters from
the keyboard of Terry Reedy:
Glenn Linderman wrote:
One can set CMD into Unicode mode (chcp 65001)... not sure how Python
reacts to that either. But even then...
I tried that and others have reported doing so on python-list but no one
has gotten that to work.
http://support.microsoft.com/kb/247815
http://www.microsoft.com/downloads/details.aspx?familyid=22e69ae4-7e40-4807-8a86-b3d36fab68d3displaylang=en
(python 3)
import ctypes
k=ctypes.WinDLL('kernel32')
x = k.SetConsoleOutputCP(65001)
if x!= 1:
print(x was , x )
exit( 1 )
print (''.join(chr(i) for i in range(0x410, 0x430)).encode('utf-8'))
produces a nice b'\xd0\x90\d0\x91' stream of hex representations of
UTF-8 encoded Unicode characters...
The only thing that seems to be missing is that Python won't emit them
to the screen that way.
So surely some python-dev that is smarter than me, could provide that
magic incantation. Will go search, but that isn't in my current
knowledge banks.
--
Glenn -- http://nevcal.com/
===
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
___
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] GSoC: Core Python development tools
Everything I've seen from Daniel so far seems to be about either making things we already do more efficient, or else providing additional features in ways that don't make the tools any more confusing for others already used to a particular way of doing things. So he seems to be navigating this particular minefield pretty well so far. Yes, I'm also quite grateful for the contributions I have received from Daniel. I hope he'll stay around for some time without exhausting. 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] Integrate BeautifulSoup into stdlib?
Martin v. Löwis wrote: In some environments, each new component must be approved. Once python is approved, the standard library is OK, but adding 7 packages from pypi requires 7 more sets of approvals. True, but as I mentioend elsewhere, I myself haven't done a python project where I only needed python and the standard lib for many years... I was always able to get what I need through aptitude. Yes, well known for its ability to run on Windows and Mac OS... Is it? I had never heard before that aptitude works well on Windows (although it does work on OSX). I'm actually not quite sure if that was a sarcastic response to Chris's original sarcasm, or if the original sarcasm just didn't cross the language barrier very well... In any case, I rarely need to install Python packages on Windows or Mac, so this causes no problem to me. If I need something on Windows, I usually download the Windows installer for it. I believe that was Chris's point as well - unlike Linux, getting new packages directly from third parties rather than from a distro provided repository is still the norm on Windows and OS X. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
The real issues with svnmerge are its occasional bugs or failures (it forgot some changesets when merging in the io-c branch!), its slowness, and its limitations (which are really inherent to the SVN model: e.g., if someone commits to the branch you have just started doing an svnmerge to, you have to revert everything and start over with the latest updates). I think addressing the slowness should surely be in scope for SoC: I would hope that rewriting it to only use a single session should provide some speedup (i.e. through the Python bindings, rather than the command line). Of course, such a project might better be mentored at subversion than Python. Regards, Martin P.S. I don't believe your claim that it forgot changesets. Could it be that it simply forgot adding files, and that it did so because you already had the files in the sandbox, so that the merging failed? P.P.S. Are you sure you have to re-merge when somebody commits something unrelated to the branch? Or just when somebody else merges as well? ___ 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] Integrate BeautifulSoup into stdlib?
I was always able to get what I need through aptitude. Yes, well known for its ability to run on Windows and Mac OS... Is it? I had never heard before that aptitude works well on Windows (although it does work on OSX). I'm actually not quite sure if that was a sarcastic response to Chris's original sarcasm, or if the original sarcasm just didn't cross the language barrier very well... The former, in this case. I believe that was Chris's point as well - unlike Linux, getting new packages directly from third parties rather than from a distro provided repository is still the norm on Windows and OS X. Sure. However, I don't think that Chris' proposed solution (whatever that is) would improve my life - it would likely make things worse for me (already the introduction of eggs made the life worse for Debian package maintainers, at least initially - i.e. for a few years). 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] GSoC: Core Python development tools
Martin v. Löwis wrote: P.P.S. Are you sure you have to re-merge when somebody commits something unrelated to the branch? Or just when somebody else merges as well? The latter is the only one I've ever had problems with (and that was due to me forgetting to update before merging rather than someone else actually doing a concurrent merge). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC: Core Python development tools
Martin v. Löwis martin at v.loewis.de writes: P.S. I don't believe your claim that it forgot changesets. Could it be that it simply forgot adding files, and that it did so because you already had the files in the sandbox, so that the merging failed? It's more weird actually, it actively forgot some changes in some files but some other changes in the /same/ files did get merged. P.P.S. Are you sure you have to re-merge when somebody commits something unrelated to the branch? Or just when somebody else merges as well? Perhaps only the latter, I'm not sure actually. (but it can also happen that the unrelated commit modifies some files you were merging changes in...) ___ 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] Non-Core project: IDLE
On Mon, Mar 23, 2009 at 5:39 PM, Terry Reedy tjre...@udel.edu wrote: Guilherme Polo wrote: On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy tjre...@udel.edu wrote: IDLE needs lots of attention -- more than any one experienced person is likely to have I'm willing to step up as a student for this but I still have to write a good proposal for it. My actual concern is about mentor availability, is someone around interested on being an IDLE mentor ? If I could, I would, and would have said so. But I have only read about tk and have not actually used it. If I did decide to dive into it, you'd be mentoring me ;-). What I can and would do is give ideas for changes, read and comment on a proposal, and user test patched versions. That is very nice Terry. Do you have some specific ideas that you want to share publicly (or in private) about IDLE ? Your expectations about what should be addressed first, or areas that should be improved.. you know, anything. The proposal I'm planning will include IDLE but it will also include some Tkinter, since it depends on it and bugs on the later can affect the former as you know. I was planning to first target the lack of tests of both IDLE and Tkinter, I believe that by adding tests (and doing it nicely) may change how future changes are applied (I'm thinking about having them getting new tests for new features, fixes, etc as it happens for other areas in Python) and will make easier to maintain them. My other target is to check the open tickets in the bug tracker regarding IDLE and Tkinter too, I have been much more active on the later so the former will take some more time to test/think/make a decision. I will be able to test these changes under Linux and on plain Windows XP, Vista and the 7 but differences between different system configurations may also affect IDLE, so any help you can provide will be very much appreciated. Hopefully someone with a mac will be able to provide some help here too. Terry -- -- Guilherme H. Polo Goncalves ___ 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] GSoC: Core Python development tools
P.S. I don't believe your claim that it forgot changesets. Could it be that it simply forgot adding files, and that it did so because you already had the files in the sandbox, so that the merging failed? It's more weird actually, it actively forgot some changes in some files but some other changes in the /same/ files did get merged. I see. Provided there is somebody willing to work on this, it might be interesting to reproduce it. P.P.S. Are you sure you have to re-merge when somebody commits something unrelated to the branch? Or just when somebody else merges as well? Perhaps only the latter, I'm not sure actually. (but it can also happen that the unrelated commit modifies some files you were merging changes in...) That should not be a problem, unless the to-be-merged changes directly conflict. Just svn-update, then try committing again. It's actually also possible to recover from overlapping merges also: just re-run svnmerge with --record-only (-M); this assumes nobody else has merged the very same changes concurrently. 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] Integrate BeautifulSoup into stdlib?
Martin v. Löwis wrote: In some environments, each new component must be approved. Once python is approved, the standard library is OK, but adding 7 packages from pypi requires 7 more sets of approvals. True, but as I mentioend elsewhere, I myself haven't done a python project where I only needed python and the standard lib for many years... I was always able to get what I need through aptitude. Yes, well known for its ability to run on Windows and Mac OS... Is it? I had never heard before that aptitude works well on Windows (although it does work on OSX). Hmm, sorry, let me clarify: sarcasm Yes, well known for its ability to run on Windows and Mac OS... /sarcasm ;-) aptitude also won't help when: - your customer is deploying onto managed machines running RHEL - debian has an outdated and/or broken version of your package. The latter is a standard problem with Zope/Apache/Postgres in debian and causes much gnashing of teeth by people trying to support them. The Debian guys love buggering around with other people's packaging, not caring that it makes supporting stuff so much harder. In any case, I rarely need to install Python packages on Windows or Mac, so this causes no problem to me. If I need something on Windows, I usually download the Windows installer for it. Yeah, 20 windows installers for different python packages whose versions may or may not conflict also seems a little silly ;-) A cross-plaftorm, platform agnostic, python-centric package management system is what's needed. Setuptools comes close, but I wonder if it's impossible to get it to do the last bits of what's needed (uninstall being the big one, and knowing what version of what package you have installed!) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] Non-Core project: IDLE
Guilherme Polo wrote: On Wed, Mar 18, 2009 at 8:53 PM, Terry Reedy tjre...@udel.edu wrote: IDLE needs lots of attention -- more than any one experienced person is likely to have I'm willing to step up as a student for this but I still have to write a good proposal for it. My actual concern is about mentor availability, is someone around interested on being an IDLE mentor ? You might want to talk to Bruce Sherwood, as VPython suffered through a bunch of Idle problems. I got the impression he had a person or two who were his Idle experts (so I am thinking they might be the mentors you are looking for). In any case, even a charter of unit tests to 50% coverage of Idle would be a huge improvement. I've run after specific bugs in Idle, but don't really know the lay of the land. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speeding up PyObject_GetItem
Nick Coghlan wrote: The main problem is that many of these methods are not only used internally, but are *also* part of the public C API made available to extension modules. We want misuse of the latter to trigger exceptions, not segfault the interpreter. But is it worth slowing everything down to check for this one particular error, among all the myriad ways a malfunctioning extension module can cause a crash? -- 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] Core projects for Summer of Code
I don't disagree, I just don't want to volunteer projects for something they don't want. Right, there must be clear indication that they are willing to accept the work when it's done. Note also that some of the largest Python-based projects, Django, I have a working port of Django to Py3k, however, the Django authors are not interested in integrating it. The same could easily happen to other ports. I can accept that, and just wait a couple of years until they are ready. The GSoC student can't really wait that long. OTOH, it could be part of the student's application to get in contact with a potential mentor, and we could prioritize porting projects assuming the package authors indicate sufficient intent to accept the results of the porting. 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] Core projects for Summer of Code
Maybe I'm misunderstanding you but I didn't mean to say that this version should work on both python 2.x and python 3.x. Ideally, there would be a PIL distribution for 2.x only and another one for 3.x only. I don't know what Fredrik thinks, but I would not consider this ideal. Ideally, there would be a single source that can be installed to both 2.x and 3.x. This is much better than two source trees, as the latter would require porting of changes back and forth. The only thing is that people (myself included) will only be comfortable with the PIL for 3.x version if it comes with the blessings of Fredrik, i.e. if I were you I'd try pushing this with Fredrik. I don't think a GSoC project can possibly help with that. 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] tracker status options
2009/3/22 Tennessee Leeuwenburg tleeuwenb...@gmail.com Hi Daniel, That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. It's the latter; it's pending feedback. -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] tracker status options
That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. It's the latter; it's pending feedback. Which latter (there seem to be multiple pairs in Tennessee's message)? In any case, it's not really pending feedback. Instead, it means if there is no feedback really soon, it will get closed. So closure is impending and imminent. 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] Issue workflow doc is now live
I sent this out as a Google Doc a while back, but I just did a proof-reading, converted it, and pushed it live to the python.org http://python.org http://python.org: http://www.python.org/dev/workflow/ . So now people who ever triage issues have a guide to follow if they are not sure how to set things. Does that mean PEP 3 should be Withdrawn or does it mean it should be replaced? It should probably be replaced with Brett's document. I say replace as well. Will then dev/workflow be removed? I don't think we need two copies (possibly inconsistent)? So if dev/workflow stays, PEP 3 should be withdrawn. 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] Issue workflow doc is now live
On Mon, Mar 23, 2009 at 17:01, Martin v. Löwis mar...@v.loewis.de wrote: I sent this out as a Google Doc a while back, but I just did a proof-reading, converted it, and pushed it live to the python.org http://python.org http://python.org: http://www.python.org/dev/workflow/ . So now people who ever triage issues have a guide to follow if they are not sure how to set things. Does that mean PEP 3 should be Withdrawn or does it mean it should be replaced? It should probably be replaced with Brett's document. I say replace as well. Will then dev/workflow be removed? I don't think we need two copies (possibly inconsistent)? So if dev/workflow stays, PEP 3 should be withdrawn. Sorry I wasn't clear; that's what I meant by replace; withdraw PEP 3 and have a note pointing to /dev/workflow, not turn /dev/workflow into a new version of PEP 3. -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] Issue workflow doc is now live
On Mon, Mar 23, 2009 at 05:36, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 23, 2009, at 8:31 AM, Nick Coghlan wrote: Brett Cannon wrote: I sent this out as a Google Doc a while back, but I just did a proof-reading, converted it, and pushed it live to the python.org http://python.org: http://www.python.org/dev/workflow/ . So now people who ever triage issues have a guide to follow if they are not sure how to set things. Does that mean PEP 3 should be Withdrawn or does it mean it should be replaced? It should probably be replaced with Brett's document. I say replace as well. -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] [Roundup-devel] PSF GSoC slot for Roundup?
Daniel (ajax) Diniz wrote: Hi, I'm about to submit a proposal for the PSF to use one GSoC slot for the Python bug tracker. I've collected a few items I think might be interesting for Roundup itself, most of which are valid RFEs for our tracker. Feel free to add more ideas to the list below. I very much like the idea of Roundup participating in the GSoC. As I mentioned off-list, I'm likely to mentor another project on boost.org (specifically, boost.python). While I would certainly like to help, I'm not sure to what degree I would be able to. This may also depend on the proposal itself. Is there a place I need to sign up to be considered as a potential mentor ? I'd like to know what people think should be prioritized should Roundup get one or part of a GSoC slot. BTW, if anyone wants to submit a separate proposal for Roundup and is willing to mentor it, posts to python-dev are welcome. There are many interesting points on your wishlist. In particular, I like a common theme that emerges from some of those: Enhancing Roundup to be useful as a development tool. I have started to work on a new tracker template, specifically targeted at development (with a schema including 'milestone', and 'task'). It might be interesting to consider how this could be enhanced, for example to integrate with versioning tools such as subversion (for which Richard already worked out bindings), CVS, GIT, etc. Or, integrate with automated build and test infrastructure (buildbot comes to mind). Another topic for improvement is performance / optimization: * Improve caching and instance sharing across multiple (web) requests * Fuse multiple SQL queries to reduce the number of RDBMS calls * ... I'm sure there are a great many things to be worked on. Thanks for proposing Roundup to be part in GSoC ! Stefan -- Stefan Seefeld CodeSourcery ste...@codesourcery.com (650) 331-3385 x718 ___ 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] tracker status options
On Tue, Mar 24, 2009 at 11:00 AM, Martin v. Löwis mar...@v.loewis.dewrote: That would be great. It occurs to me that if we wanted to use Stage settings, it would be easy to search for issues which are not closed by literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. It's the latter; it's pending feedback. Which latter (there seem to be multiple pairs in Tennessee's message)? In any case, it's not really pending feedback. Instead, it means if there is no feedback really soon, it will get closed. So closure is impending and imminent. I think this indicates that the flag in not sufficiently self-descriptive. My understanding, and I think the understanding of some others, is that this flag indicates a suspension of development pending additional feedback, rather the impending conclusion of development pending further feedback. In some of my earlier emails to this list, other developers were happy to mark issues that were being deferred as a result of requiring further specification or clarification as pending feedback, which is quite the opposite of imminent closure. While some may feel that the use of this flag is unambiguously used to signify imminent closure, I respectfully point out the recent occasions where confusion has occurred, and not just from a single individual. Perhaps some developers have a well-established workflow and interpret these flag in a particular, consistent fashion, however part of the purpose of the issue tracker is to allow a diverse group to work on development as a group. On that basis, I feel that more documentation, and clearer terminology, is required in order to support the bug resolution process. I have identified some gaps in the workflow process which impact me personally in classifying issues. These issues will not impact on all developers; clearly they will be entirely superfluous, perhaps even confusing, for some individuals. However the impact still remains for some. There appears to be a general agreement that ability to distinguish between issues on the following bases would be useful: * Whether the nature of the requirement is still under debate or whether it is well-understood * Whether the issue is up for grabs by any developer or whether responsibility lies with an individual or group already * Whether the issue is ready for more serious consideration by more experienced or core developers Since these issues relate primarily to the long-standing, dubious or complex issues which are not fully resolved, often of lower priority, it is apparent that more experienced developers will not find a lot of use in the addition of further flag, but I don't see that their workflow would be frustrated either. I'm happy to put my time an effort into classification of low-priority issues, classification, and code development for areas which would probably not otherwise receive much attention. However, to do this effectively, I need to be able to set up additional parameters against the issues to support the search requirements needed. Doing this on the development tracker seems to be the best approach, seeing as there seems to be some closely-held positions regarding the existing set of flags -- it would be quite inappropriate to disrupt existing workflows for the more experienced and core developers without demonstrating the value of new flags. However, I do feel that adding flags is of very clear value to the development process overall. My suggestion remains to add two additional attributes, either as stage or status options (personally I still feel 'status' is appropriate, but I don't mind where they go): * Under discussion * Under development This would flag Open issues as being up for grabs by any developer, Under discussion as something which is not ready for a developer to start work on a solution and which is still being worked out. Under development similarly means that everyone who needs to be involved is already involved. Issues that were under discussion or under development would drop back to Open after a month of inactivity. Issues which could not be advanced without further feedback would be marked as suspended pending feedback, and never drop back to Open. The current pending feedback which appears to be used to indicate imminent closure should perhaps be altered to pending closure. Thus, Open indicated triage is required. The default view on the issue tracker should be all issues not closed. The default view for a triage nurse would be show me everything that is open. I'm all for more debate on options for these new flags, but I haven't heard a whole lot of alternatives to date... Cheers, -Tennessee
Re: [Python-Dev] Integrate BeautifulSoup into stdlib?
On Tue, Mar 24, 2009 at 6:47 AM, Martin v. Löwis mar...@v.loewis.de wrote: already the introduction of eggs made the life worse for Debian package maintainers, at least initially - i.e. for a few years. It still is, FWIW, David ___ 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] tracker status options
On Mon, 23 Mar 2009 at 16:20, Tennessee Leeuwenburg wrote: literally searching for 'not closed' rather than 'open'. I think it's also unclear whether the 'pending' stage means 'suspended pending additional user feedback' or 'resolution of this issue is impending'. My understanding was that it meant 'pending additional feedback' in the sense of awaiting, rather than imminent. I understood from posts I saw go by earlier from Daniel that 'pending' meant 'close pending unless there is feedback to the contrary' (and I just used it that way). It sounds like that is indeed correct but not universally known, and thus I would suggest that at a minimum this status be changed to 'close pending' to make it clearer. -- R. David Murray http://www.bitdance.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] an unimportant question, ...
This is all over now, but I do think that the change from char to int was made for alignment reasons. I don't know, but I could certainly imagine that aligned memcpy calls are faster. I can't explain why I still put the 3-byte savings comment in SVN -- perhaps I was in a hurry. On Sun, Mar 22, 2009 at 12:38 PM, Christian Tismer tis...@stackless.com wrote: On 3/22/09 8:01 PM, Martin v. Löwis wrote: Now, the internals are very clear to me. What I don't understand is where the three saved bytes should be. If you look at the various patches in http://bugs.python.org/issue576101 then there is a three-byte saving in all versions from 1 to 6. Consequentially, the API was changed in those versions (but only starting from version 5, i.e. the first version created by Guido). For some reason, the saving was then removed from the patch that got actually committed (#7). I guess the comment just stayed. Yes, funny, actually. At least, I don't find any comment why the char was turned into an int, after all. Are char pointers not on a word boundary problematic on some platforms? Or was it maybe to just keep the string layout on many common platforms compatible, in order to save rebuilding so many windows extension modules? If the latter is true and the only reason, I vote for reclaiming the three bytes. Maybe it saves a tree or two. Maybe it hurts very little if done for Python 3000. In any case, use the version that saves the most energy. :-) not kidding - ciao -- chris -- Christian Tismer :^) mailto:tis...@stackless.com tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.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] Integrate BeautifulSoup into stdlib?
Chris Withers writes: aptitude also won't help when: - your customer is deploying onto managed machines running RHEL True. - debian has an outdated and/or broken version of your package. True, but just as for the package system you are advocating, it's quite easy to set up your apt to use third-party repositories of Debian-style packages. The question is whether those repositories exist. Introducing yet another, domain-specific package manager will make it less likely that they do, and it will cause more work for downstream distributors like Debian and RH. The latter is a standard problem with Zope/Apache/Postgres in debian and causes much gnashing of teeth by people trying to support them. The Debian guys love buggering around with other people's packaging, not caring that it makes supporting stuff so much harder. Well, I can't speak for the Debian Zope/Apache/Postgres maintainers, but I assure you the Emacs maintainers do care. But their hands are full trying to implement what you keep proposing as a solution, viz., a batteries-included distribution built on top of a package system. If you don't like Debian, fine, as an upstream vendor, I don't either. But an awful lot of my users *do* like[1] Debian (or Ubuntu or another Debian-derived distro). I see no alternative to cooperating with them (though I sometimes complain loudly throughout the processwink). If you want to see where the kind of thing you propose can lead, take a look at the Debian Emacs Policy document, which is designed to deal with one fork that takes the batteries-included approach, and another that has gone a long way in the direction of unbundling packages. Note that while Python doesn't have a political fork of the kind that Emacs does, it *does* have multiple blessed technical forks, and your suggestion involves the creation of yet more forks (ie, the distributions with bundled packages, versus those without). Whether the technical differences among Python implementations and packaging strategies will lead to the kind of issues that form the background of the Debian Emacs Policy, I don't know. But you don't know either. A cross-plaftorm, platform agnostic, python-centric package management system is what's needed. That's what you (think you[2]) need, but that statement rudely ignores the stated requirements of many other users. What you are doing here is divisive, not unifying. Setuptools comes close, but I wonder if it's impossible to get it to do the last bits of what's needed (uninstall being the big one, and knowing what version of what package you have installed!) Why wonder, when you can try an implementation and report the results? I guess you mean you hope somebody else will do the work (not only of development, but of maintaining the package repository). Well, somebody else has *already* done the work, but unfortunatelywink they defined the work in their own way. The result is the batteries-included stdlib. Footnotes: [1] For values of like including but not limited to see no superior alternative to. [2] If your users include Debian and RHEL users, you may find that they are not so happy with yet more PMS. ___ 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
