Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Josiah Carlson writes: > On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell wrote: > > What do you think of LISP, and "car" in particular (apart from > > the stupidly cryptic name)? > Apples and oranges. True, but speaking of Lisp lists, here's some possibly relevant experience. About 10 years

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Josiah Carlson writes: > Lisp lists are really stacks No, they're really (ie, concretely) singly-linked lists. Now, stacks are an abstract data type, and singly-linked lists provide an efficient implementation of stacks. But that's not what linked lists "really are". For example, singly-lin

Re: [Python-Dev] Restore the warning about mktemp now that DeprecationWarnings are silenced

> I mean port it to py3k first and then backport it from trunk to 2.6 and > from py3k to 3.1. If you want to wait then it's probably enough to add a > note to the ticket and I'll fix it later. I haven't followed this discussion, but I'd like to point out that the only changes allowed for 2.6 are b

Re: [Python-Dev] Forking and Multithreading - enemy brothers

Stefan Behnel, 30.01.2010 07:36: > Pascal Chambon, 29.01.2010 22:58: >> I've just recently realized the huge problems surrounding the mix of >> multithreading and fork() - i.e that only the main thread actually >> survived the fork(), and that process data (in particular, >> synchronization primiti

Re: [Python-Dev] Forking and Multithreading - enemy brothers

Pascal Chambon, 29.01.2010 22:58: > I've just recently realized the huge problems surrounding the mix of > multithreading and fork() - i.e that only the main thread actually > survived the fork(), and that process data (in particular, > synchronization primitives) could be left in a dangerously bro

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/30 Scott Dial > > Cesare, just FYI, your Hg repository has lost the execute bits on some > files (namely "./configure" and "./Parser/asdl_c.py"), so it does not > quite build out-of-the-box. > That's probably because I worked on Windows. I have to address this issue. Thanks. > I took th

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/30 > On 10:55 pm, collinwin...@google.com wrote: > >> >> That people are directly munging CPython >> bytecode means that CPython should provide a better, more abstract way >> to do the same thing that's more resistant to these kinds of changes. >> > > It might be helpful to hear more abou

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Terry Reedy wrote: > On 1/29/2010 6:45 PM, "Martin v. Löwis" wrote: >> When PEP 384 gets implemented, you not only get that, but you will also >> be able to use the same extension module for 3.2, 3.3, 3.4, etc, with >> or without U-S. > > Even if CPython changes VC compiler version? In any case, g

Re: [Python-Dev] Restore the warning about mktemp now that DeprecationWarnings are silenced

On Fri, Jan 29, 2010 at 17:37, Ezio Melotti wrote: > On 28/01/2010 8.39, Brett Cannon wrote: >> >> On Wed, Jan 27, 2010 at 15:54, Ezio Melotti >>  wrote: >>> >>> I noticed that in the py3k doc 'mktemp' is marked as deprecated since >>> Python >>> 2.3 [1], but the function is still there and doesn'

Re: [Python-Dev] Restore the warning about mktemp now that DeprecationWarnings are silenced

On 28/01/2010 8.39, Brett Cannon wrote: On Wed, Jan 27, 2010 at 15:54, Ezio Melotti wrote: I noticed that in the py3k doc 'mktemp' is marked as deprecated since Python 2.3 [1], but the function is still there and doesn't raise any warning. Looking at the source I found out that there is a warni

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 8:43 AM, Cesare Di Mauro wrote: > If you use Mercurial, you can grab a local copy this way: > > hg clone https://wpython10.wpython2.googlecode.com/hg/ wpython2-wpython10 > > Wpython is intended to run on any platform where CPython 2.6.4 runs. > Cesare, just FYI, your Hg repository

Re: [Python-Dev] Improved Traceback Module

At 01:24 AM 1/30/2010 +0100, Ludvig Ericson wrote: On 28 jan 2010, at 22:47, P.J. Eby wrote: > At 07:47 PM 1/28/2010 +0100, Benjamin Schweizer wrote: >> >> I like the idea of configuring the list of variables with using a >> convention like __trace__, though this requires me to specify what >>

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 6:45 PM, "Martin v. Löwis" wrote: On Windows, would a C extension author be able to distribute a single binary (bdist_wininst/bdist_msi) which would be compatible with with-LLVM and without-LLVM builds of Python? When PEP 384 gets implemented, you not only get that, but you will al

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 5:55 PM, Collin Winter wrote: Hey Terry, On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedy wrote: Several years, there was serious consideration of switching to a registerbased vm, which would have been even more of a change. Since I learned 1.4, Guido has consistently insisted that t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

> On Windows, would a C extension author be able to distribute a single > binary (bdist_wininst/bdist_msi) which would be compatible with > with-LLVM and without-LLVM builds of Python? When PEP 384 gets implemented, you not only get that, but you will also be able to use the same extension module

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 10:55 pm, collinwin...@google.com wrote: That people are directly munging CPython bytecode means that CPython should provide a better, more abstract way to do the same thing that's more resistant to these kinds of changes. Yes, definitely! Requesting a supported way to do the kind of intr

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 10:47 pm, tjre...@udel.edu wrote: On 1/29/2010 4:19 PM, Collin Winter wrote: On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: Agreed. We originally switched Unladen Swallow to wordcode in our 2009Q1 release, and saw a performance improvement from this across the board. We switched back

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Hey Terry, On Fri, Jan 29, 2010 at 2:47 PM, Terry Reedy wrote: > On 1/29/2010 4:19 PM, Collin Winter wrote: >> >> On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan  wrote: > >> Agreed. We originally switched Unladen Swallow to wordcode in our >> 2009Q1 release, and saw a performance improvement from

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 1/29/2010 4:19 PM, Collin Winter wrote: On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: Agreed. We originally switched Unladen Swallow to wordcode in our 2009Q1 release, and saw a performance improvement from this across the board. We switched back to bytecode for the JIT compiler to

[Python-Dev] Forking and Multithreading - enemy brothers

Hello, I've just recently realized the huge problems surrounding the mix of multithreading and fork() - i.e that only the main thread actually survived the fork(), and that process data (in particular, synchronization primitives) could be left in a dangerously broken state because of such for

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Fri, Jan 29, 2010 at 7:22 AM, Nick Coghlan wrote: > Antoine Pitrou wrote: >> Or you could submit patches piecewise on http://bugs.python.org >> I think the first step would be to switch to 16-bit bytecodes. It would be >> uncontroversial (the increase in code size probably has no negative effec

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Collin Winter wrote: > I added startup benchmarks for Mercurial and Bazaar yesterday > (http://code.google.com/p/unladen-swallow/source/detail?r=1019) so we > can use them as more macro-ish benchmarks, rather than merely starting > the CPython binary over and over again. If you have ideas for bette

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 Antoine Pitrou > Actually, "wordcode" could allow accesses in the eval loop to be done on > aligned words, so as to fetch operands in one step on little-endian CPUs > (instead of recombining bytes manually). > > Regards > > Antoine. > I think that big-endians CPUs can get benefits too

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

I made a mistake talking about the example. Exchange binary operator and unary operator. Cesare 2010/1/29 Cesare Di Mauro > 2010/1/29 Nick Coghlan > > I wouldn't consider changing from bytecode to wordcode uncontroversial - >> the potential to have an effect on cache hit ratios means it needs

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On Thu, Jan 28, 2010 at 9:48 PM, Terry Reedy wrote: > On 1/28/2010 6:30 PM, Josiah Carlson wrote: > >> I would also point out that the way these things are typically done is >> that programmers/engineers have use-cases that are not satisfied by >> existing structures, they explain the issues they

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 Nick Coghlan > I wouldn't consider changing from bytecode to wordcode uncontroversial - > the potential to have an effect on cache hit ratios means it needs to be > benchmarked (the U-S performance tests should be helpful there). > It's quite strange, but from the tests made it seems t

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

On Thu, Jan 28, 2010 at 8:57 PM, Steve Howell wrote: > --- On Thu, 1/28/10, Josiah Carlson wrote: >> [...] in the decade+ that I've been using >> Python and >> needed an ordered sequence; lists were the right solution >> 99% of the >> time [...] > > What do you think of LISP, and "car" in particu

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (01/22/10 - 01/29/10) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2579 open (+34) / 17049 closed (+15) / 19628 total (+49) Open issues with patches: 1049 Average

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Nick Coghlan gmail.com> writes: > > Antoine Pitrou wrote: > > Or you could submit patches piecewise on http://bugs.python.org > > I think the first step would be to switch to 16-bit bytecodes. It would be > > uncontroversial (the increase in code size probably has no negative effect) and > > wo

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Antoine Pitrou wrote: > Or you could submit patches piecewise on http://bugs.python.org > I think the first step would be to switch to 16-bit bytecodes. It would be > uncontroversial (the increase in code size probably has no negative effect) > and > would provide the foundation for all of your op

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 > > One strong suggestion for future releases: Please put a top-level directory > in your archives. It is annoying to expect that only to have an archive > expand into the current directory without creating a directory of its own. > I've been burned often enough that I always check be

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 Antoine Pitrou > Cesare Di Mauro gmail.com> writes: > > > > If python dev community is interested, I can work on a 3.x branch, > porting > > all optimizations I made (and many others that I've planned to implement) > one > > step at the time, in order to carefully check and validate an

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> You can find 7-Zip tools here Cesare> . Thanks. Found a tool named 7za in MacPorts which I was able to install. One strong suggestion for future releases: Please put a top-level directory in your archives. It is annoying to expect that only t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare Di Mauro gmail.com> writes: > > If python dev community is interested, I can work on a 3.x branch, porting > all optimizations I made (and many others that I've planned to implement) one > step at the time, in order to carefully check and validate any change with > expert people monitorin

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 > >Cesare> ... (you can find the wpython 1.0 final here >Cesare> ). > > I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. > What's a 7z file? What tool on my Mac will unpack that? Can I build and > ru

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On 29/01/2010 13:24, s...@pobox.com wrote: Cesare> ... (you can find the wpython 1.0 final here Cesare> ). I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. What's a 7z file? What tool on my Mac will unpack

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> ... (you can find the wpython 1.0 final here Cesare> ). I tried downloading it. Something about wpython10.7z and wpython10_fix.7z. What's a 7z file? What tool on my Mac will unpack that? Can I build and run wpython on my Mac or

[Python-Dev] car, cdr

Steve Howell yahoo.com> writes: > > What do you think of LISP, and "car" in particular (apart from the stupidly > cryptic name)? The question is not directed to me but I would say it's a brain-dead data structure. (pointed pairs did allow me to create C++ template classes with a variable number

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

2010/1/29 > >Cesare> I think that wpython as a proof-of-concept have done its work, >Cesare> showing its potentials. > > If you haven't alreayd is there any chance you can run the Unladen Swallow > performance test suite and post the results? The code is separate from U-S > and should w

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

Cesare> I think that wpython as a proof-of-concept have done its work, Cesare> showing its potentials. If you haven't alreayd is there any chance you can run the Unladen Swallow performance test suite and post the results? The code is separate from U-S and should work with wpython:

Re: [Python-Dev] patch to make list.pop(0) work in O(1) time

Am 28.01.2010 05:30, schrieb Steve Howell: > If you want tools that are easy to use correctly, make them bug-free and > document their behavior. If you want tools that are easy to use well, then > make them perform better. I am not sure how my patch contradicts either of > these goals. > > You

Re: [Python-Dev] scripts, applets, and applications (Was Re: PyCon Keynote)

David Lyon wrote: Eric Smith wrote: This discussion probably belongs on the distutils list. Yes, the discussion should be. Except that distutils doesn't have very much support for doing applets or applications. So it's logical to see why most posts which ask the same question, often go unan

Re: [Python-Dev] default of returning None hurts performance?

Hi Antoine, Wpython already addressed this with two new opcodes. RETURN_CONST constant_index which is an equivalent of: LOAD_CONST constant_index RETURN_VALUE and with: CALL_PROC_RETURN_CONST function_arguments, constant_index which is an equivalent of: CALL_FUNCTION function_arguments POP_