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

On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz wrote: > > On Jan 21, 2010, at 6:48 PM, Collin Winter wrote: > > Hey Glyph, > > There's been a recent thread on our mailing list about a patch that > dramatically reduces the memory footprint of multiprocess concurrency > by separating reference co

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

On Jan 21, 2010, at 6:48 PM, Collin Winter wrote: > Hey Glyph, > There's been a recent thread on our mailing list about a patch that > dramatically reduces the memory footprint of multiprocess concurrency > by separating reference counts from objects. We're looking at possibly > incorporating th

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

On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver wrote: > IIUC, optimizing your application using standard (non-JITed) profiling > tools would still be a win for the app when run under the JIT, because > your are going to be trimming code / using better algorithms, which will > tend to provide "orthag

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

On Thu, Jan 21, 2010 at 5:07 PM, David Malcolm wrote: > To what extent would it be possible to use (conditionally) use full > ahead-of-time compilation as well as JIT? It would be possible to do this, but it doesn't have nearly the same benefits as JIT compilation, as Alex mentioned. You could d

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jake McGuire wrote: > Hmm. So cProfile doesn't break, but it causes code to run under a > completely different execution model so the numbers it produces are > not connected to reality? > > We've found the call graph and associated execution time in

Re: [Python-Dev] PyCon Keynote

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Noller wrote: > On Thu, Jan 21, 2010 at 6:16 PM, wrote: >> How about explaining why you're not going to give Collin a pony? >> >> Skip > > You're on to something, but the question is: > > 1> How do we get a pony to atlanta > 2> Later deliver

Re: [Python-Dev] PyCon Keynote

On Thu, Jan 21, 2010 at 9:19 PM, Jesse Noller wrote: > On Thu, Jan 21, 2010 at 6:16 PM,   wrote: >> >> How about explaining why you're not going to give Collin a pony? >> >> Skip > > You're on to something, but the question is: > > 1> How do we get a pony to atlanta > 2> Later deliver it to Mounta

Re: [Python-Dev] PyCon Keynote

On Thu, Jan 21, 2010 at 6:16 PM, wrote: > > How about explaining why you're not going to give Collin a pony? > > Skip You're on to something, but the question is: 1> How do we get a pony to atlanta 2> Later deliver it to Mountain View 3> Get it to review patches? ___

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

On Thu, Jan 21, 2010 at 12:20 PM, Collin Winter wrote: > Hey Greg, > > On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith wrote: >> I think having a run time flag (or environment variable for those who like >> that) to disable the use of JIT at python3 execution time would be a good >> idea. > >

Re: [Python-Dev] PyCon Keynote

How about explaining why you're not going to give Collin a pony? Skip ___ 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-ar

Re: [Python-Dev] newgil for python 2.5.4

Done: http://bugs.python.org/issue7753 Porting to 2.7 was easier since it didn't involve putting the changesets listed in issue 4293. The performance numbers in the bug are more accurate than the ones I previously posted. Turns out the system python is not a good baseline. The improvement from th

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

On Jan 21, 2010, at 04:07 PM, Jeffrey Yasskin wrote: >I could imagine a problem if Python+LLVM link in one libstdc++, and an >extension module links in a different one, even if no C++ objects are >passed across the boundary. Does that cause problems in practice? We'd >have the same problems as fro

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

On Thu, Jan 21, 2010 at 3:49 PM, Barry Warsaw wrote: > Martin's follow up reminds me what the issues with C++ here are.  They center > around which C++ compilers you use on which platforms.  Solaris, and to some > extent Windows IIRC, were the most problematic for the work I was doing 3+ > years a

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

On Jan 21, 2010, at 02:46 PM, Jeffrey Yasskin wrote: >LLVM's under the University of Illinois/NCSA license, which is >BSD-like: http://www.opensource.org/licenses/UoI-NCSA.php or >http://llvm.org/releases/2.6/LICENSE.TXT. Cool. This is a GPL compatible license, so it would presumably not change

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

On Jan 21, 2010, at 12:42 PM, Collin Winter wrote: Hi Collin, >I don't believe that introducing the Unladen Swallow JIT will make >maintaining a stable ABI per PEP 384 more difficult. We've been careful about >not exporting any C++ symbols via PyAPI_FUNC(), so I don't believe that will >be an iss

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

Hey Glyph, On Thu, Jan 21, 2010 at 9:11 AM, Glyph Lefkowitz wrote: > It would be hard for me to put an exact number on what I would find > acceptable, but I was really hoping that we could get a *reduced* memory > footprint in the long term. > > My real concern here is not absolute memory usage

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

On Thu, Jan 21, 2010 at 10:14 AM, Reid Kleckner wrote: > On Thu, Jan 21, 2010 at 9:35 AM, Floris Bruynooghe > wrote: >> I just compiled with the --without-llvm option and see that the >> binary, while only an acceptable 4.1M, still links with libstdc++.  Is >> it possible to completely get rid of

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

Hey Antoine, On Thu, Jan 21, 2010 at 4:25 AM, Antoine Pitrou wrote: >> The increased memory usage comes from a) LLVM code generation, analysis >> and optimization libraries; b) native code; c) memory usage issues or >> leaks in LLVM; d) data structures needed to optimize and generate >> machine c

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On Thu, 2010-01-21 at 22:21 +0100, "Martin v. Löwis" wrote: > > Where the default *file system encoding* is used (i.e. text files are > > written or read without specifying an encoding) > > I think you misunderstand the notion of the *file system encoding*. > It is *not* a "file encoding", but the

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

On 1/21/2010 1:09 PM, Hanno Schlichting wrote: > - Who holds the copyright, is there a foundation or is there a risk of > the project getting into trouble because of copyright issues? > - What licence is the code and the tools under and what affect does > that have on the code generated by the JIT

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

On Thu, 2010-01-21 at 23:42 +0100, "Martin v. Löwis" wrote: > > With my "downstream distributor of Python" hat on, I'm wondering if it > > would be feasible to replace the current precompiled .pyc/.pyo files in > > marshal format with .so/.dll files in platform-specific shared-library > > format, s

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

On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting wrote: > I'm a relative outsider to core development (I'm just a Plone release > manager), but'll allow myself a couple of questions. Feel free to > ignore them, if you think they are not relevant at this point :-) I'd > note that I'm generally e

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

> With my "downstream distributor of Python" hat on, I'm wondering if it > would be feasible to replace the current precompiled .pyc/.pyo files in > marshal format with .so/.dll files in platform-specific shared-library > format, so that the pre-compiled versions of the stdlib could be > memory-map

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

On Thu, Jan 21, 2010 at 2:24 PM, Collin Winter wrote: > I'll also update the PEP with these benchmark results, since they're > important to a lot of people. Done; see http://codereview.appspot.com/186247/diff2/4:8/9 for the wording change and new startup data. Collin Winter _

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

Reid Kleckner wrote: > On Thu, Jan 21, 2010 at 4:34 PM, "Martin v. Löwis" wrote: >>> How large is the LLVM shared library? One surprising data point is that the >>> binary is much larger than some of the memory footprint measurements given >>> in >>> the PEP. >> Could it be that you need to strip

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

Hi Paul, On Thu, Jan 21, 2010 at 12:56 PM, Paul Moore wrote: > I'm concerned about the memory and startup time penalties. It's nice > that you're working on them - I'd like to see them remain a priority. > Ultimately a *lot* of people use Python for short-running transient > commands (not just ad

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

On Wed, 2010-01-20 at 14:27 -0800, Collin Winter wrote: [snip] > At a high level, the Unladen Swallow JIT compiler works by translating a > function's CPython bytecode to platform-specific machine code, using data > collected at runtime, as well as classical compiler optimizations, to improve > t

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

On Thu, Jan 21, 2010 at 4:34 PM, "Martin v. Löwis" wrote: >> How large is the LLVM shared library? One surprising data point is that the >> binary is much larger than some of the memory footprint measurements given in >> the PEP. > > Could it be that you need to strip the binary, or otherwise remo

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

On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter wrote: [snip] > Incremental builds, however, are significantly slower. The table below shows > incremental rebuild times after touching ``Objects/listobject.c``. > > +-+---+---+--+ > | Incr make

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

> Sure, though it sounds quite similar to what they were mentioning with: > "the creation of hermetic Python "binaries", with all necessary modules > preloaded" I wondered whethe this hermetic binary would also include the result of JIT compilation - if so, it would go beyond freeze, and contain a

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

Martin v. Löwis wrote: >> There is "freeze": >> http://wiki.python.org/moin/Freeze >> >> Which IIRC Robert Collins tried in the past, but didn't see a huge gain. >> It at least tries to compile all of your python files to C files and >> then build an executable out of that. > > "to C files" is a b

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

> On Wed, Jan 20, 2010 at 10:54:11PM -0800, Gregory P. Smith wrote: >> I think having a run time flag (or environment variable for those who like >> that) to disable the use of JIT at python3 execution time would be a good >> idea. > > Another approach could be to compile two binaries, 'python' wh

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

Hey Collin, Thanks for the good answers so far! On Thu, Jan 21, 2010 at 21:14, Collin Winter wrote: > We used to run the Mercurial correctness tests at every revision, but > they were incredibly slow and a bit flaky under CPython 2.6. Bazaar's > tests were faster, but were flakier, so we ended u

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

> There is "freeze": > http://wiki.python.org/moin/Freeze > > Which IIRC Robert Collins tried in the past, but didn't see a huge gain. > It at least tries to compile all of your python files to C files and > then build an executable out of that. "to C files" is a bit of an exaggeration, though. I

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

> How large is the LLVM shared library? One surprising data point is that the > binary is much larger than some of the memory footprint measurements given in > the PEP. Could it be that you need to strip the binary, or otherwise remove unneeded debug information? Regards, Martin _

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

Reid Kleckner wrote: > On Thu, Jan 21, 2010 at 7:25 AM, Antoine Pitrou wrote: >>> 32-bit; gcc 4.0.3 >>> >>> +-+---+---+--+ | >>> Binary size | CPython 2.6.4 | CPython 3.1.1 | Unladen Swallow r988 | >>> +=+===+=

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

> 1. What are the implications for PEP 384 (Stable ABI) if U-S is added? I haven't studied U-S yet, but I'd hope that there might be no implications. No basic API should change, and everything the JIT compiler does should be well shielded from the object API (which PEP 384 deals with). > 2. What

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

> Where the default *file system encoding* is used (i.e. text files are > written or read without specifying an encoding) I think you misunderstand the notion of the *file system encoding*. It is *not* a "file encoding", but the file *system* encoding, i.e. the encoding for file *names*, not for f

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

On Thu, Jan 21, 2010 at 3:00 PM, Steve Steiner (listsin) wrote: > > On Jan 21, 2010, at 3:20 PM, Collin Winter wrote: > >> Hey Greg, >> >> On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith wrote: >>> +1 >>> My biggest concern is memory usage but it sounds like addressing that is >>> already in y

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

2010/1/21 Paul Moore : > 2010/1/20 Collin Winter : >> Hello python-dev, [...] >> We're looking forward to discussing this with everyone. > > I'll comment on a number of points here - I've read the thread but > it'd get too complex trying to quote specific items. [...] One thing I forgot to mention

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

On Jan 21, 2010, at 3:20 PM, Collin Winter wrote: > Hey Greg, > > On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith wrote: >> +1 >> My biggest concern is memory usage but it sounds like addressing that is >> already in your mind. I don't so much mind an additional up front constant >> and per

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

2010/1/20 Collin Winter : > Hello python-dev, > > I've just committed the initial draft of PEP 3146, proposing to merge > Unladen Swallow into CPython's source tree and roadmap. The initial > draft is included below. I've also uploaded the PEP to Rietveld at > http://codereview.appspot.com/186247,

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

Hey Barry, On Thu, Jan 21, 2010 at 3:34 AM, Barry Warsaw wrote: > On Jan 20, 2010, at 11:05 PM, Jack Diederich wrote: > >>Does disabling the LLVM change binary compatibility between modules >>targeted at the same version?  At tonight's Boston PIG we had some >>binary package maintainers but most

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

On Thu, Jan 21, 2010 at 3:14 PM, Collin Winter wrote: >> P.S. Is there any chance of LLVM doing something like tracing JITs? >> Those seem somewhat more promising to me (even though I understand >> they're quite hard in the face of Python features like stack frames). > > Yes, you could implement a

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

Hey Greg, On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith wrote: > +1 > My biggest concern is memory usage but it sounds like addressing that is > already in your mind.  I don't so much mind an additional up front constant > and per-line-of-code hit for instrumentation but leaks are unacceptab

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

Hey Dirkjan, On Thu, Jan 21, 2010 at 11:16 AM, Dirkjan Ochtman wrote: > On Thu, Jan 21, 2010 at 18:32, 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

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

On Thu, Jan 21, 2010 at 09:32:23AM -0800, Collin Winter wrote: > Hi Dirkjan, > > On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman wrote: > > For some apps (like Mercurial, which I happen to sometimes hack on), > > increased startup time really sucks. We already have our demandimport > > code (I

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

Dirkjan Ochtman ochtman.nl> writes: > > What I personally would consider interesting for the PEP is a (not too > big) section evaluating where other Python-performance efforts are at. > E.g. does it make sense to propose a u-s merge now when, by the time > 3.3 (or whatever) is released, there'll

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

On Thu, Jan 21, 2010 at 12:25:59PM +, Antoine Pitrou wrote: > > We seek guidance from the community on > > an acceptable level of increased memory usage. > > I think a 10-20% increase would be acceptable. > I'm just a user of the core interpreter but the bottleneck in using python in my envir

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

On Thu, Jan 21, 2010 at 18:32, 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 ag

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

On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner wrote: > On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire wrote: >> On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter >> wrote: >>> Profiling >>> - >>> >>> Unladen Swallow integrates with oProfile 0.9.4 and newer [#oprofile]_ to >>> support >>

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

On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter wrote: > Profiling > - > > Unladen Swallow integrates with oProfile 0.9.4 and newer [#oprofile]_ to > support > assembly-level profiling on Linux systems. This means that oProfile will > correctly symbolize JIT-compiled functions in its repor

Re: [Python-Dev] PyCon Keynote

On Wed, Jan 13, 2010 at 19:51, Guido van Rossum wrote: > Please mail me topics you'd like to hear me talk about in my keynote > at PyCon this year. Your thoughts on "lean stdlib" (obviously not too lean) vs. "fat stdlib" might be interesting. Cheers, Dirkjan

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On Thu, 2010-01-21 at 00:06 +0100, "Martin v. Löwis" wrote: > > Why only set an encoding on these streams when they're directly > > connected to a tty? > > If you are sending data to the terminal, you can be fairly certain > that the locale's encoding should be used. It's a convenience feature > f

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

On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire wrote: > On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter > wrote: >> Profiling >> - >> >> Unladen Swallow integrates with oProfile 0.9.4 and newer [#oprofile]_ to >> support >> assembly-level profiling on Linux systems. This means that oProf

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

On Thu, Jan 21, 2010 at 9:35 AM, Floris Bruynooghe wrote: > I just compiled with the --without-llvm option and see that the > binary, while only an acceptable 4.1M, still links with libstdc++.  Is > it possible to completely get rid of the C++ dependency if this option > is used?  Introducing a C+

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

Reid Kleckner mit.edu> writes: > > > This is positively humongous. Is there any way to shrink these numbers > > dramatically (I'm talking about the release builds)? Large executables or > > libraries may make people anxious about the interpreter's memory > > efficiency; and they will be a nuisanc

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

Hi, I'm a relative outsider to core development (I'm just a Plone release manager), but'll allow myself a couple of questions. Feel free to ignore them, if you think they are not relevant at this point :-) I'd note that I'm generally enthusiastic and supportive of the proposal :) As a data point,

Re: [Python-Dev] PyCon Keynote

Hmmm. A list of favorite restaurants? OK, more seriously: Your favourite python tools. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.or

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

My 2 cents: For environments like Plone that has a lot of code and uses a lot of memory the current speed increases is probaly not worth it if the memory increases as much as it does now. It would for almost all cases mean you need to skimp on data caching instead, which would probably slow down t

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

On Thu, Jan 21, 2010 at 7:25 AM, Antoine Pitrou wrote: >> 32-bit; gcc 4.0.3 >> >> +-+---+---+--+ | >> Binary size | CPython 2.6.4 | CPython 3.1.1 | Unladen Swallow r988 | >> +=+===+===+=

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

Collin Winter wrote: > Hi Dirkjan, > > On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman wrote: >> On Thu, Jan 21, 2010 at 02:56, Collin Winter wrote: >>> Agreed. We are actively working to improve the startup time penalty. >>> We're interested in getting guidance from the CPython community as t

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

On Wed, Jan 20, 2010 at 10:54:11PM -0800, Gregory P. Smith wrote: > I think having a run time flag (or environment variable for those who like > that) to disable the use of JIT at python3 execution time would be a good > idea. Another approach could be to compile two binaries, 'python' which is sm

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

Hi Dirkjan, On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman wrote: > On Thu, Jan 21, 2010 at 02:56, Collin Winter wrote: >> Agreed. We are actively working to improve the startup time penalty. >> We're interested in getting guidance from the CPython community as to >> what kind of a startup sl

Re: [Python-Dev] PyCon Keynote

On Thu, Jan 21, 2010 at 8:37 AM, Kortatu wrote: > Hi! > > For me, could be very interesting something about Unladen Swallow, and your > opinion about JIT compilers. FWIW, there will be a separate talk about Unladen Swallow at PyCon. I for one would like to hear Guido talk about something else :)

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

On Jan 21, 2010, at 7:25 AM, Antoine Pitrou wrote: >> We seek guidance from the community on >> an acceptable level of increased memory usage. > > I think a 10-20% increase would be acceptable. It would be hard for me to put an exact number on what I would find acceptable, but I was really hop

Re: [Python-Dev] PyCon Keynote

Hi! For me, could be very interesting something about Unladen Swallow, and your opinion about JIT compilers. Unfortunately, I can't go to PyCon, are you going to upload the keynote presentation? Cheers. 2010/1/21 Michael Foord > On 21/01/2010 15:03, Thomas Wouters wrote: > > > > On Wed, Jan 1

Re: [Python-Dev] PyCon Keynote

On 21/01/2010 15:03, Thomas Wouters wrote: On Wed, Jan 13, 2010 at 19:51, Guido van Rossum > wrote: Please mail me topics you'd like to hear me talk about in my keynote at PyCon this year. How about something completely different... ? Your history of Pytho

Re: [Python-Dev] PyCon Keynote

On Wed, Jan 13, 2010 at 19:51, Guido van Rossum wrote: > Please mail me topics you'd like to hear me talk about in my keynote > at PyCon this year. I'd like to hear you lay to rest that nonsense about you retiring :> -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature

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

On Wed, Jan 20, 2010 at 02:27:05PM -0800, Collin Winter wrote: > Platform Support > [...] > In order to support hardware and software platforms where LLVM's JIT > does not work, Unladen Swallow provides a ``./configure > --without-llvm`` option. This flag carves out any part of Unl

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

Hello, > If we have done any original work, it is by accident. :-) > The increased memory usage comes from a) LLVM code generation, analysis > and optimization libraries; b) native code; c) memory usage issues or > leaks in LLVM; d) data structures needed to optimize and generate > machine code

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

Michael Foord wrote: As always: It's better not to rely on such defaults and explicitly provide the encoding as parameter where possible. >>> Sure. I do worry that developers will still rely on the default behavior >>> assuming that Python 3 "fixes their encoding pr

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On 21/01/2010 12:00, M.-A. Lemburg wrote: Michael Foord wrote: On 21/01/2010 11:15, M.-A. Lemburg wrote: Michael Foord wrote: On 20/01/2010 21:37, M.-A. Lemburg wrote: The only supported default encodings in Python are: Python 2.x: ASCII Python 3.x: UTF-

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

Michael Foord wrote: > On 21/01/2010 11:15, M.-A. Lemburg wrote: >> Michael Foord wrote: >> >>> On 20/01/2010 21:37, M.-A. Lemburg wrote: >>> The only supported default encodings in Python are: Python 2.x: ASCII Python 3.x: UTF-8 >>> Is this true?

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On 21/01/2010 11:15, M.-A. Lemburg wrote: Michael Foord wrote: On 20/01/2010 21:37, M.-A. Lemburg wrote: The only supported default encodings in Python are: Python 2.x: ASCII Python 3.x: UTF-8 Is this true? I thought the default encoding in Python 3 was platform speci

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

On 20/01/2010 23:46, MRAB wrote: Martin v. Löwis wrote: The only supported default encodings in Python are: Python 2.x: ASCII Python 3.x: UTF-8 Is this true? For 3.x: yes. However, the default encoding is much less relevant in 3.x, since Python will never implicitly use the default encoding,

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

On Jan 20, 2010, at 10:09 PM, Benjamin Peterson wrote: >> Does disabling the LLVM change binary compatibility between modules >> targeted at the same version?  At tonight's Boston PIG we had some >> binary package maintainers but most people (including myself) only >> cared about source compatibil

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

On Jan 20, 2010, at 11:05 PM, Jack Diederich wrote: >Does disabling the LLVM change binary compatibility between modules >targeted at the same version? At tonight's Boston PIG we had some >binary package maintainers but most people (including myself) only >cared about source compatibility.I a

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

On 21/01/2010 06:54, Gregory P. Smith wrote: +1 My biggest concern is memory usage but it sounds like addressing that is already in your mind. I don't so much mind an additional up front constant and per-line-of-code hit for instrumentation but leaks are unacceptable. Any instrumentation da

Re: [Python-Dev] Proposed downstream change to site.py in Fedora (sys.defaultencoding)

Michael Foord wrote: > On 20/01/2010 21:37, M.-A. Lemburg wrote: >> The only supported default encodings in Python are: >> >> Python 2.x: ASCII >> Python 3.x: UTF-8 >> > > Is this true? I thought the default encoding in Python 3 was platform > specific (i.e. cp1252 on Windows). That means

Re: [Python-Dev] Mailing List archive corruption?

Barry Warsaw python.org> writes: > WTF? I think the archives were recently regenerated, so there's probably a > fubar there. CC'ing the postmasters. > Is someone still working on this? I see no updates coming in to the Python-dev archive on mail.python.org, though I do see them on Gmane (for