Re: [Python-Dev] Possible patch for functools partial - Interested?
On 05/08/10 03:57, Steve Holden wrote: Steven D'Aprano wrote: [...] Similarly, if you wanted p1==p2, why not write p1 = partial(operator.add) p2 = p1 I thought the OP gave a use-case. He's generating jobs (partial applied to a callable and arguments), and wanted to avoid duplicated jobs. I think it is reasonable to expect that partial(operator.add, 2) compares equal to partial(operator.add, 2). I don't think he's suggesting it should compare equal to partial(lambda x,y: x+y, 2). Which absence, presumably, also mildly disappoints you? it disappoints me this does not compare equal: add3 = lambda a, b, c: a + b + c a = partial(partial(add3, 1), 2) b = partial(partial(add3, 2), 1) print a == b :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
Lie Ryan writes: it disappoints me this does not compare equal: add3 = lambda a, b, c: a + b + c a = partial(partial(add3, 1), 2) b = partial(partial(add3, 2), 1) print a == b :-) But it's not even true for floating point.wink ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
On Wed, 12 May 2010 06:34:50 pm Stephen J. Turnbull wrote: Lie Ryan writes: it disappoints me this does not compare equal: add3 = lambda a, b, c: a + b + c a = partial(partial(add3, 1), 2) b = partial(partial(add3, 2), 1) print a == b :-) But it's not even true for floating point.wink All humour aside, let's not ruin the chances of this patch being accepted by overloading it. I think there is a good use-case for partial objects to compare equal if they were constructed with arguments that compare equal. That's a nice, conservative change that is unlikely to lead to bugs, unlike some of the more clever proposals that rely on mathematical equivalences that don't hold for Python objects. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible patch for functools partial - Interested?
On 5/11/2010 11:54 PM, Cameron Simpson wrote: I know for functions == and is currently are equivalent, but we should be really finicky here about intent, especially since a few messages in the thread is contemplate testing function for equivalence to one degree or other. At which point == and is aren't the same any more. As I stated above, I make no effort to address equivalence of the functions, nor of the arguments. I am addressing identity of the partial object, which I am defining as identity of the functions + identity of the args + equivalence of the keyword arguments after a deterministic process has been applied. ___ 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] HEADS UP: Compilation risk with new GCC 4.5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Zlib-devel] HEADS UP: Apparent bad compilation under (just released) GCC 4.5.0 http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-May/002267.html GCC Bugzilla Bug 40838 gcc shouldn't assume that the stack is aligned http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 Short history: new GCC 4.5.0 (released a month ago), when compiling with - -O3, is adding MMX/SSE instructions that requires stack aligned to 16 byte. This is wrong, since x86 ABI only requires stack aligned to 4 bytes. If you compile EVERYTHING with GCC 4.5.0, you are safe (I guess!), but if your environment has mixed compiled code (for instance, the OS libraries), you can possibly core dump. If you have an old compiled Python and you update libs compiled with GCC 4.5.0, you can crash in the process. Psyco is showing the issue, but it is not the culprit. It only leaves - -correctly- the stack in not 16-byte alignment. But there are plenty of examples of crashes not related to python+psyco. Proposal: add -fno-tree-vectorize to compilation options for 2.7/3.2. Warm 2.3/2.4/2.5/2.6/3.0/3.1 users. Or warm users compiling with GCC 4.5.0. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS+qpcZlgi5GaxT1NAQLAjgP/anZ5C2lED190++ffcluApF3ASF20iSnH t21ynHxrz2fgkPeOxeGRAqGEGCc3jZ0UuXchECcLLzFhI8WQS8K766EOgOKdwZLV WCt0ohWZ0FfsJZX4J5Y73x39uhjShbnl6SSek2uEvPi/tua/R4W/kVXrAZ0ZZR6/ vRqSUXpdolM= =5K+S -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] HEADS UP: Compilation risk with new GCC 4.5.0
Jesus Cea wrote: Proposal: add -fno-tree-vectorize to compilation options for 2.7/3.2. Will this actually help? Won't there still be a problem if any extension module is compiled with GCC 4.5.0 without that option, regardless of the options used to build Python itself? 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] HEADS UP: Compilation risk with new GCC 4.5.0
On May 12, 2010, at 9:13 AM, Jesus Cea wrote: Short history: new GCC 4.5.0 (released a month ago), when compiling with - -O3, is adding MMX/SSE instructions that requires stack aligned to 16 byte. This is wrong, since x86 ABI only requires stack aligned to 4 bytes. If you compile EVERYTHING with GCC 4.5.0, you are safe (I guess!), but if your environment has mixed compiled code (for instance, the OS libraries), you can possibly core dump. If you have an old compiled Python and you update libs compiled with GCC 4.5.0, you can crash in the process. Psyco is showing the issue, but it is not the culprit. It only leaves - -correctly- the stack in not 16-byte alignment. But there are plenty of examples of crashes not related to python+psyco. Proposal: add -fno-tree-vectorize to compilation options for 2.7/3.2. Warm 2.3/2.4/2.5/2.6/3.0/3.1 users. Or warm users compiling with GCC 4.5.0. While assuming the stack is 16byte aligned is undeniably an ABI- violation in GCC, at this point, it's surely simpler to just go along: the new unofficial ABI for x86 is that the stack must always be left in 16-byte alignment... So, just change psyco to always use 16-byte-aligned stackframes. GCC has used 16byte-aligned stackframes for a heck of a long time now (so if the stack starts 16byte aligned on entry to a function it will stay that way on calls). So usually the only way people run into unaligned stacks is via hand-written assembly code or JIT compilers. I think you'll be a lot happier just modifying Psyco than making everyone else in the world change their compiler flags. James ___ 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] HEADS UP: Compilation risk with new GCC 4.5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/10 15:32, Nick Coghlan wrote: Jesus Cea wrote: Proposal: add -fno-tree-vectorize to compilation options for 2.7/3.2. Will this actually help? Won't there still be a problem if any extension module is compiled with GCC 4.5.0 without that option, regardless of the options used to build Python itself? When I do a python setup.py install, the options used to compile the module are the same that used to compile python itself. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS+qzn5lgi5GaxT1NAQJ5BgQAimvcMssT57iuuLpaI9P9GXKGZf9VUAzj F4XJM/lT4Qtzu22jecIvEej0MyiMR/4qHvns8lgqLXn/30pkYrkmYcjxFigpM7Bl rOKMYeAr3ki8dN87APkoiMKOJHByXlEUZu+BowCOXcUCtGYcENLwQ+STr1NyCsUB IINfh1pJ2Nc= =GiUG -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] HEADS UP: Compilation risk with new GCC 4.5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/10 15:39, James Y Knight wrote: While assuming the stack is 16byte aligned is undeniably an ABI-violation in GCC, at this point, it's surely simpler to just go along: the new unofficial ABI for x86 is that the stack must always be left in 16-byte alignment... You can not rule out other software embedding python inside, or callbacks from foreign code. For instance, Berkeley DB library can do callbacks to Python code. So, just change psyco to always use 16-byte-aligned stackframes. GCC has used 16byte-aligned stackframes for a heck of a long time now (so if the stack starts 16byte aligned on entry to a function it will stay that way on calls). So usually the only way people run into unaligned stacks is via hand-written assembly code or JIT compilers. Not all the universe is GCC based. For instance, Solaris system libraries are not compiled using GCC. The world is bigger that Linux/GCC. I think you'll be a lot happier just modifying Psyco than making everyone else in the world change their compiler flags. Would be nice if GCC 4.5.1 would solve this :). They are objectivelly breaking the x86 ABI. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS+q0rplgi5GaxT1NAQK98wP+NJoqNCpvjemP4Gv7y1G/iPkQgjuidslT uiPxDcN9Eprcluc+mGTBu6N+fCTj09xYhUCD1wWhoJq2dRyoA8b+XC1fCSyL4VXc mzsy0rGmKeQh4lyAw+7agFCqryd6n+/oyl+9aOT6YkzyLFjQd4KDEcGNZ0h+6PAf 4jtx1+p3k0c= =TzTY -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] HEADS UP: Compilation risk with new GCC 4.5.0
On May 12, 2010, at 10:01 AM, Jesus Cea wrote: On 12/05/10 15:39, James Y Knight wrote: While assuming the stack is 16byte aligned is undeniably an ABI-violation in GCC, at this point, it's surely simpler to just go along: the new unofficial ABI for x86 is that the stack must always be left in 16-byte alignment... You can not rule out other software embedding python inside, or callbacks from foreign code. For instance, Berkeley DB library can do callbacks to Python code. So? When calling callback functions, the Berkeley DB library won't un-16byte-align the stack, will it? (Assuming it's been compiled with gcc in the last 10 years) Not all the universe is GCC based. For instance, Solaris system libraries are not compiled using GCC. The world is bigger that Linux/ GCC. If the Solaris compilers don't use 16byte-aligned stackframes, and GCC on Solaris/x86 also assumes 16byte-aligned stacks, I guess GCC on Solaris/x86 is pretty broken indeed. But for Linux/x86, stacks have been de-facto 16byte aligned for so long, you can *almost* excuse the ABI violation as unimportant. But anyways, psyco should keep the stackframes 16byte aligned regardless, for performance reasons: even when accessing datatypes for which unaligned access doesn't crash, it's faster when it's aligned. James ___ 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] HEADS UP: Compilation risk with new GCC 4.5.0
Short history: new GCC 4.5.0 (released a month ago), when compiling with -O3, is adding MMX/SSE instructions that requires stack aligned to 16 byte. This is wrong, since x86 ABI only requires stack aligned to 4 bytes. I think this is debatable. It depends on the operating system also; ultimately, it is the OS vendor who specifies the C ABI for their systems. On Linux, in absence of a vendor, the ABI is what the kernel and gcc define it to be. 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] Possible patch for functools partial - Interested?
On Fri, May 7, 2010 at 17:02, Antoine Pitrou solip...@pitrou.net wrote: It would be more useful to provide equality, hashing and repr to partial itself, rather than a subclass. Feel free to propose a patch :) Hi! I've done that. I've opened a feature request: http://bugs.python.org/issue8699 The patch is also at Rietveld: http://codereview.appspot.com/1179044 I'm a beginner, so my patch is probably far from perfect, but I'd appreciate any help, and will try to correct my mistakes. Thanks, Daniel Urban ___ 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] HEADS UP: Compilation risk with new GCC 4.5.0
On Wed, May 12, 2010 at 6:39 AM, James Y Knight f...@fuhm.net wrote: I think you'll be a lot happier just modifying Psyco than making everyone else in the world change their compiler flags. Aye, there's the rub. Nobody's happier modifying Psyco. :) But that just means people will gradually have to stop using psyco in favor of maintainable JITs. Gcc's not going to change its stack requirements just because some people think they know what the ABI should be better than the people defining the ABI. Btw, this has been a problem since at least gcc-4.4. ___ 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] bugs.python.org down?
On 5/11/2010 7:16 PM, Antoine Pitrou wrote: Apparently the tracker has been unresponding for some time now, although port 80 still accepts connections. As I reported before, there have been on and off problems for days. Messages like (minutes ago) upon trying to login: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g Server at bugs.python.org Port 80 Now I retry and it works. ___ 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] bugs.python.org down?
On Wed, 12 May 2010 13:09:11 -0400, Terry Reedy tjre...@udel.edu wrote: On 5/11/2010 7:16 PM, Antoine Pitrou wrote: Apparently the tracker has been unresponding for some time now, although port 80 still accepts connections. As I reported before, there have been on and off problems for days. Messages like (minutes ago) upon trying to login: Service Temporarily Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache/2.2.9 (Debian) mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.9 OpenSSL/0.9.8g Server at bugs.python.org Port 80 Now I retry and it works. That last was us restarting roundup, which cured the problem at least temporarily. We've added a robots.txt file to hopefully slow down the bot hits (which are the bulk of the traffic on the tracker) once they bother to notice it. I'm not convinced that hit count load is the problem, but it might be. -- R. David Murray 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
[Python-Dev] configuring the buildbot to skip some tests?
I've got parc-tiger-1 up and running again. It's failing on test_tk, which makes sense, because it's running as a background twisted process, and thus can't access the window server. I should configure that out. I'm looking for documentation on how to configure the build slave so that it skips this test. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python on Windows with CoApp
Howdy folks, Quick e-mail at 34,000ft (aren't wifi-enabled flights great?) to mention a new initiative that's been started by Microsoft called CoApp (Common Opensource Application Publishing Platform). The aim is simple: make open source software rock on Windows ;-) It's probably easiest to think of it as a Microsoft-endorsed-but-community-run open source distribution for Windows, akin to all the various package managers for Linux distributions and ports/packages for the *BSDs. There are specific user and developer experiences we'll be addressing -- like making it easy to install and use open source software, or use it within your own project (open source or not). CoApp will affect Python in one of two ways. Once there's a clear-cut specification for open source projects to follow, Python can either decide to follow it, or not. The same applies to all open source packages, actually. For those that follow it, great! If not, no problem -- the plan is to shallow-fork such projects via launchpad and the CoApp community will take responsibility for getting releases of open source projects into CoApp shape. It's in its infancy at the moment -- it took the chap (Garrett Serack) who's spearheading it at Microsoft about six months to get it all signed off by the lawyers and platform/server VPs. So, for those of you out there who are Windows-inclined, now's a perfect time to get involved to help shape the direction of CoApp going forward. The website/wiki is http://coapp.org/ and the launchpad project site is http://launchpad.net/coapp (which is where the mailing list is hosted). We're actually having a 'CoApp Development Summit' tomorrow and Friday in Seattle (that Microsoft's graciously sponsored). The event will be accessible via Live Meeting for those that are interested: http://coapp.org/Project_Planning/CoApp_Design_and_Development_Summit Regards, Trent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 7 updated
Does anyone know of a way to teach vim that C sources in a python checkout should have 4-space indents without changing the defaults for other C files? I use this in my vimrc: indentation: use detectindent plugin if possible set autoindent set smartindent try let g:detectindent_preferred_expandtab = 1 let g:detectindent_preferred_tabsize = 8 let g:detectindent_preferred_indent = 4 source $VIMRUNTIME/plugin/detectindent.vim au BufNewFile,BufRead * .* DetectIndent catch set smarttab set expandtab set tabstop=8 set shiftwidth=4 set softtabstop=4 set textwidth=80 endtry *** And this is plugin/detectindent.vim: Name: detectindent (global plugin) Version: 1.0 Author:Ciaran McCreesh ciaranm at gentoo.org Updates: http://dev.gentoo.org/~ciaranm/vim/ Purpose: Detect file indent settings License: You may redistribute this plugin under the same terms as Vim itself. Usage: :DetectIndent to prefer expandtab to noexpandtab when detection is impossible: :let g:detectindent_preferred_expandtab = 1 to set a preferred indent level when detection is impossible: :let g:detectindent_preferred_indent = 4 Requirements: Untested on Vim versions below 6.2 fun! SIDIsCommentStart(line) comments isn't reliable if ft == c || ft == cpp return -1 != match(a:line, '/\*') else return 0 endif endfun fun! SIDIsCommentEnd(line) if ft == c || ft == cpp return -1 != match(a:line, '\*/') else return 0 endif endfun fun! SIDDetectIndent() let l:has_leading_tabs= 0 let l:has_leading_spaces = 0 let l:shortest_leading_spaces_run = 0 let l:longest_leading_spaces_run = 0 let l:idx_end = line($) let l:idx = 1 while l:idx = l:idx_end let l:line = getline(l:idx) try to skip over comment blocks, they can give really screwy indent settings in c/c++ files especially if SIDIsCommentStart(l:line) while l:idx = l:idx_end ! SIDIsCommentEnd(l:line) let l:line = getline(l:idx) let l:idx = l:idx + 1 endwhile let l:idx = l:idx + 1 continue endif let l:leading_char = strpart(l:line, 0, 1) if l:leading_char == \t let l:has_leading_tabs = 1 elseif l:leading_char == only interested if we don't have a run of spaces followed by a tab. if -1 == match(l:line, '^ \+\t') let l:has_leading_spaces = 1 let l:spaces = strlen(matchstr(l:line, '^ \+')) if l:shortest_leading_spaces_run == 0 || \ l:spaces l:shortest_leading_spaces_run let l:shortest_leading_spaces_run = l:spaces endif if l:spaces l:longest_leading_spaces_run let l:longest_leading_spaces_run = l:spaces endif endif endif let l:idx = l:idx + 1 endwhile if l:has_leading_tabs ! l:has_leading_spaces tabs only, no spaces set noexpandtab if exists(g:detectindent_preferred_tabsize) let shiftwidth = g:detectindent_preferred_indent let tabstop = g:detectindent_preferred_indent endif elseif l:has_leading_spaces ! l:has_leading_tabs spaces only, no tabs set expandtab let shiftwidth = l:shortest_leading_spaces_run elseif l:has_leading_spaces l:has_leading_tabs spaces and tabs set noexpandtab let shiftwidth = l:shortest_leading_spaces_run , time to guess how big tabs are if l:longest_leading_spaces_run 2 let tabstop = 2 elseif l:longest_leading_spaces_run 4 let tabstop = 4 else let tabstop = 8 endif else no spaces, no tabs if exists(g:detectindent_preferred_tabsize) let shiftwidth = g:detectindent_preferred_indent let tabstop = g:detectindent_preferred_indent endif if exists(g:detectindent_preferred_expandtab) set expandtab endif endif endfun command! -nargs=0 DetectIndent call SIDDetectIndent() ___ 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
