Re: [Python-Dev] Distutils2 scripts
On Wed, 20 Oct 2010 20:01:56 -0500 Ron Adam r...@ronadam.com wrote: On Ubuntu, I use python, python2.7, python3.1, python3.2 and that is what I type to use that particular version. The -m option seems to me to be the easiest to do and works with all of these. python2.7 -m setup python3.2 -m setup Having pysetup or pysetupX.Y executables would be much more practical with shell auto-completion, though. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] maximum recursion depth exceeded in lib\pstats.py
Hi all, There's a bug in Python 2.6, module lib\pstats.py, line 150. I'm pretty sure, however that it also exists in other versions, as I don't think that profiler differs very much between them. Let me paste a little piece of surrounding code: class Stats: () def add(self, *arg_list): if not arg_list: return self if len(arg_list) 1: self.add(*arg_list[1:]) #Line 150, the problem is right here! other = arg_list[0] (... do some processing with first item from arg_list ...) This is the code for adding profiling stats from multiple files (names are on arg_list) so that they can be displayed in cumulated and readable form. As you can see it chops off the first item from the list and then uses recursion to process the rest of it. It's no wonder then that when you profiled a little too many function calls, you're bound to see RuntimeError with 'maximum recursion depth exceeded' message when you try using this. IMO this should be done with iteration instead, like: def add(self, *arg_list): if not arg_list: return self for other in arg_list: #Preserved variable name only for sake of comparison with previous snippet (... do some processing with each item from arg_list, merging results in some rightful manner ...) Kind regards, Adam Bielanski. ___ 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] maximum recursion depth exceeded in lib\pstats.py
On 21/10/2010 12:20, Adam Bielański wrote: Hi all, There's a bug in Python 2.6, module lib\pstats.py, line 150. I'm pretty sure, however that it also exists in other versions, as I don't think that profiler differs very much between them. Let me paste a little piece of surrounding code: class Stats: () def add(self, *arg_list): if not arg_list: return self if len(arg_list) 1: self.add(*arg_list[1:]) #Line 150, the problem is right here! other = arg_list[0] (... do some processing with first item from arg_list ...) This is the code for adding profiling stats from multiple files (names are on arg_list) so that they can be displayed in cumulated and readable form. As you can see it chops off the first item from the list and then uses recursion to process the rest of it. It's no wonder then that when you profiled a little too many function calls, you're bound to see RuntimeError with 'maximum recursion depth exceeded' message when you try using this. IMO this should be done with iteration instead, like: def add(self, *arg_list): if not arg_list: return self for other in arg_list: #Preserved variable name only for sake of comparison with previous snippet (... do some processing with each item from arg_list, merging results in some rightful manner ...) Without looking at the details your diagnosis and suggested fix seem good. Please raise an issue on the Python bug tracker - preferably with patch and test. http://bugs.python.org/ All the best, Michael Foord Kind regards, Adam Bielanski. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils2 scripts
On 10/21/2010 4:44 AM, Antoine Pitrou wrote: On Wed, 20 Oct 2010 20:01:56 -0500 Ron Adamr...@ronadam.com wrote: On Ubuntu, I use python, python2.7, python3.1, python3.2 and that is what I type to use that particular version. The -m option seems to me to be the easiest to do and works with all of these. python2.7 -m setup python3.2 -m setup Having pysetup or pysetupX.Y executables would be much more practical with shell auto-completion, though. I agree. I also don't see any confusion about which python a pysetupX.Y would use. Or for that matter a plain pysetup. It would be the one that a plain python would get you. Eric. ___ 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] hg migration schedule
Okay, we're getting somewhere here. I've been conferring with Georg on when we can do the conversion. He's done some testing with the buildbot setup, which seems to be mostly done. He also completed preliminary ports of the hooks used in the SVN repository. He managed to convince me that we're at a point where it would be good to post some kind of schedule, so here we go. 2010-11-13: availability of a test repo I'm working towards finally having a test repository that's close to what we'll have for the final repository. I hope to have it done sooner than by Nov 13, so it seems like a fairly realistic date. I'm not promising we'll also have docs done by then, but good documentation will be my focus as soon as I'm done with the test repository. I should also mention that I'll be visiting the US east cost (Boston and NYC) from Nov 13 to Nov 21, so I probably won't be spending much time on this that week. 2010-12-12: final conversion (tentative) Georg would really like the conversion to be done by the end of the year, and it seems that this is within reach. The aim here is not to disturb the 3.2 release process too much, of course, while still giving Georg more powerful tools to manage what's left of the release process. We're currently tracking progress in a todo.txt file in the pymigr repo [1] (and in the #python-dev IRC channel), so if you want to help out, you're more than welcome! We're also going to need at least one more big fight about workflow/organizational issues, but I'd like to hold off on that until after we have a test repo that can actually demonstrate the issues that are relevant to that discussion. Cheers, Dirkjan [1] http://hg.python.org/pymigr/file/tip/todo.txt ___ 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] hg migration schedule
Yay! I am so looking forward to dissing SVN... On Thu, Oct 21, 2010 at 6:32 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: Okay, we're getting somewhere here. I've been conferring with Georg on when we can do the conversion. He's done some testing with the buildbot setup, which seems to be mostly done. He also completed preliminary ports of the hooks used in the SVN repository. He managed to convince me that we're at a point where it would be good to post some kind of schedule, so here we go. 2010-11-13: availability of a test repo I'm working towards finally having a test repository that's close to what we'll have for the final repository. I hope to have it done sooner than by Nov 13, so it seems like a fairly realistic date. I'm not promising we'll also have docs done by then, but good documentation will be my focus as soon as I'm done with the test repository. I should also mention that I'll be visiting the US east cost (Boston and NYC) from Nov 13 to Nov 21, so I probably won't be spending much time on this that week. 2010-12-12: final conversion (tentative) Georg would really like the conversion to be done by the end of the year, and it seems that this is within reach. The aim here is not to disturb the 3.2 release process too much, of course, while still giving Georg more powerful tools to manage what's left of the release process. We're currently tracking progress in a todo.txt file in the pymigr repo [1] (and in the #python-dev IRC channel), so if you want to help out, you're more than welcome! We're also going to need at least one more big fight about workflow/organizational issues, but I'd like to hold off on that until after we have a test repo that can actually demonstrate the issues that are relevant to that discussion. Cheers, Dirkjan [1] http://hg.python.org/pymigr/file/tip/todo.txt ___ 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 (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] My work on Python3 and non-ascii paths is done
On Oct 20, 2010, at 02:11 AM, Victor Stinner wrote: I plan to fix Python documentation: specify the encoding used to decode all byte string arguments of the C API. I already wrote a draft patch: issue #9738. This lack of documentation was a big problem for me, because I had to follow the function calls to get the encoding. That's exactly what I was looking for! Thanks. I think you've learned a huge amount of good information that's difficult to find, so writing it up in a more permanent and easy to find location will really help future Python developers! -Barry signature.asc Description: 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] hg migration schedule
On Thu, Oct 21, 2010 at 06:32, Dirkjan Ochtman dirk...@ochtman.nl wrote: Okay, we're getting somewhere here. I've been conferring with Georg on when we can do the conversion. He's done some testing with the buildbot setup, which seems to be mostly done. He also completed preliminary ports of the hooks used in the SVN repository. He managed to convince me that we're at a point where it would be good to post some kind of schedule, so here we go. 2010-11-13: availability of a test repo I'm working towards finally having a test repository that's close to what we'll have for the final repository. I hope to have it done sooner than by Nov 13, so it seems like a fairly realistic date. I'm not promising we'll also have docs done by then, but good documentation will be my focus as soon as I'm done with the test repository. I should also mention that I'll be visiting the US east cost (Boston and NYC) from Nov 13 to Nov 21, so I probably won't be spending much time on this that week. I am currently slated to start my PSF grant in January when I will rewrite the dev docs, so I can help with the workflow documentation starting then. -Brett 2010-12-12: final conversion (tentative) Georg would really like the conversion to be done by the end of the year, and it seems that this is within reach. The aim here is not to disturb the 3.2 release process too much, of course, while still giving Georg more powerful tools to manage what's left of the release process. We're currently tracking progress in a todo.txt file in the pymigr repo [1] (and in the #python-dev IRC channel), so if you want to help out, you're more than welcome! We're also going to need at least one more big fight about workflow/organizational issues, but I'd like to hold off on that until after we have a test repo that can actually demonstrate the issues that are relevant to that discussion. Cheers, Dirkjan [1] http://hg.python.org/pymigr/file/tip/todo.txt ___ 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/brett%40python.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] [Python-checkins] r85733 - in python/branches/py3k: Doc/library/logging.rst Lib/logging/__init__.py
+``Filters` can be used by ``Handlers`` and ``Loggers`` for more ↑ missing ` here. Regards ___ 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] My work on Python3 and non-ascii paths is done
On Thu, Oct 21, 2010 at 12:00:40PM -0400, Barry Warsaw wrote: On Oct 20, 2010, at 02:11 AM, Victor Stinner wrote: I plan to fix Python documentation: specify the encoding used to decode all byte string arguments of the C API. I already wrote a draft patch: issue #9738. This lack of documentation was a big problem for me, because I had to follow the function calls to get the encoding. This will be truly excellent! That's exactly what I was looking for! Thanks. I think you've learned a huge amount of good information that's difficult to find, so writing it up in a more permanent and easy to find location will really help future Python developers! One further thing I'd be interested in is if you could document any best practices from this experience. Things like, surrogateescape is a good/bad default in these cases, When is parallel functions for bytes and str better than a single polymorphic function? That way when other modules are added to the stdlib, things can be more consistent. -Toshio pgp6M2nRKwOkl.pgp Description: 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
[Python-Dev] 3.1.3 and 2.7.1 release schedule
In the interest of getting 3.1.3 and 2.7.1 out by next year, here's a tentative release schedule: November 13th - RC1 November 27th - RC2 December 11th - Final I'll jump for it if there are no objections. -- 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] python-2.6.6 coredump running newspipe
Any ideas what could cause this or how to fix this? It could be a compiler bug; try disabling optimization. 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] Distutils2 scripts
Eric Smith wrote: Or for that matter a plain pysetup. It would be the one that a plain python would get you. If 'pysetup' is simply a shell script that invokes 'python -m setup' using the current search path, I guess that's true. On Windows, however, it seems to me that the current 'python setup.py' scheme has advantages, since it lets you simply invoke 'setup.py' and rely on file associations to get you the current python. Supporting either 'python -m setup' or 'pysetup' out of the box would require install-time path hacking of the sort that some people are uncomfortable about. -- 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] 3.1.3 and 2.7.1 release schedule
On Oct 21, 2010, at 05:57 PM, Benjamin Peterson wrote: In the interest of getting 3.1.3 and 2.7.1 out by next year, here's a tentative release schedule: November 13th - RC1 November 27th - RC2 December 11th - Final Sounds like you're planning to get finals out this year, not next :). +1 from me! -Barry signature.asc Description: 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] Distutils2 scripts
On 10/21/2010 07:13 PM, Greg Ewing wrote: Eric Smith wrote: Or for that matter a plain pysetup. It would be the one that a plain python would get you. If 'pysetup' is simply a shell script that invokes 'python -m setup' using the current search path, I guess that's true. On Windows, however, it seems to me that the current 'python setup.py' scheme has advantages, since it lets you simply invoke 'setup.py' and rely on file associations to get you the current python. Supporting either 'python -m setup' or 'pysetup' out of the box would require install-time path hacking of the sort that some people are uncomfortable about. Terek said this in the first post of this thread... I just wanted to make sure that once distutils2 is back in the stdlib, it's OK for us to add that script in the distribution. When it's in the stdlib, the -m option should work just like any other script run from the stdlib. What path hacking are you thinking of? Ron ___ 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
