Barry Warsaw barry at 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
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 files written
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
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
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 compatibility.
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
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
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? I thought the default encoding in
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:
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 problems and cause
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; e)
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 Unladen
On Wed, Jan 13, 2010 at 19:51, Guido van Rossum gu...@python.org 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 tho...@python.org
Hi! I'm a .signature
On 21/01/2010 15:03, Thomas Wouters wrote:
On Wed, Jan 13, 2010 at 19:51, Guido van Rossum gu...@python.org
mailto:gu...@python.org 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
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 fuzzy...@voidspace.org.uk
On 21/01/2010 15:03, Thomas Wouters
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 hoping
On Thu, Jan 21, 2010 at 8:37 AM, Kortatu glorybo...@gmail.com 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
Hi Dirkjan,
On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Jan 21, 2010 at 02:56, Collin Winter collinwin...@google.com wrote:
Agreed. We are actively working to improve the startup time penalty.
We're interested in getting guidance from the 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
Collin Winter wrote:
Hi Dirkjan,
On Wed, Jan 20, 2010 at 10:55 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Jan 21, 2010 at 02:56, Collin Winter collinwin...@google.com wrote:
Agreed. We are actively working to improve the startup time penalty.
We're interested in getting guidance
On Thu, Jan 21, 2010 at 7:25 AM, Antoine Pitrou solip...@pitrou.net wrote:
32-bit; gcc 4.0.3
+-+---+---+--+ |
Binary size | CPython 2.6.4 | CPython 3.1.1 | Unladen Swallow r988 |
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
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
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,
Reid Kleckner rnk at 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 nuisance
On Thu, Jan 21, 2010 at 9:35 AM, Floris Bruynooghe
floris.bruynoo...@gmail.com 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
On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire mcgu...@google.com wrote:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com
wrote:
Profiling
-
Unladen Swallow integrates with oProfile 0.9.4 and newer [#oprofile]_ to
support
assembly-level profiling on Linux
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
for the
On Wed, Jan 13, 2010 at 19:51, Guido van Rossum gu...@python.org 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
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com 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
On Thu, Jan 21, 2010 at 10:19 AM, Reid Kleckner r...@mit.edu wrote:
On Thu, Jan 21, 2010 at 12:27 PM, Jake McGuire mcgu...@google.com wrote:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com
wrote:
Profiling
-
Unladen Swallow integrates with oProfile 0.9.4 and
On Thu, Jan 21, 2010 at 18:32, Collin Winter collinwin...@google.com 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
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 environment
Dirkjan Ochtman dirkjan at 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,
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 dirk...@ochtman.nl wrote:
For some apps (like Mercurial, which I happen to sometimes hack on),
increased startup time really sucks. We already have our demandimport
Hey Dirkjan,
On Thu, Jan 21, 2010 at 11:16 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Jan 21, 2010 at 18:32, Collin Winter collinwin...@google.com wrote:
I added startup benchmarks for Mercurial and Bazaar yesterday
(http://code.google.com/p/unladen-swallow/source/detail?r=1019) so
Hey Greg,
On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith g...@krypto.org 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
On Thu, Jan 21, 2010 at 3:14 PM, Collin Winter collinwin...@google.com 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
Hey Barry,
On Thu, Jan 21, 2010 at 3:34 AM, Barry Warsaw ba...@python.org 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
2010/1/20 Collin Winter collinwin...@google.com:
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
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 g...@krypto.org 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
2010/1/21 Paul Moore p.f.mo...@gmail.com:
2010/1/20 Collin Winter collinwin...@google.com:
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.
On Thu, Jan 21, 2010 at 3:00 PM, Steve Steiner (listsin)
list...@integrateddevcorp.com 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 g...@krypto.org wrote:
+1
My biggest concern is memory usage but it sounds like
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 file
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
Reid Kleckner wrote:
On Thu, Jan 21, 2010 at 7:25 AM, Antoine Pitrou solip...@pitrou.net wrote:
32-bit; gcc 4.0.3
+-+---+---+--+ |
Binary size | CPython 2.6.4 | CPython 3.1.1 | Unladen Swallow r988 |
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
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. It embeds
Hey Collin,
Thanks for the good answers so far!
On Thu, Jan 21, 2010 at 21:14, Collin Winter collinwin...@google.com 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
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
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 bit of an
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 actual
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter collinwin...@google.com wrote:
[snip]
Incremental builds, however, are significantly slower. The table below shows
incremental rebuild times after touching ``Objects/listobject.c``.
On Thu, Jan 21, 2010 at 4:34 PM, Martin v. Löwis mar...@v.loewis.de 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
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
the
Hi Paul,
On Thu, Jan 21, 2010 at 12:56 PM, Paul Moore p.f.mo...@gmail.com 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
Reid Kleckner wrote:
On Thu, Jan 21, 2010 at 4:34 PM, Martin v. Löwis mar...@v.loewis.de 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
On Thu, Jan 21, 2010 at 2:24 PM, Collin Winter collinwin...@google.com 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
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-mapped
On Thu, Jan 21, 2010 at 10:09 AM, Hanno Schlichting ha...@hannosch.eu 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
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, so that the
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
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 file
Hey Antoine,
On Thu, Jan 21, 2010 at 4:25 AM, Antoine Pitrou solip...@pitrou.net 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
On Thu, Jan 21, 2010 at 10:14 AM, Reid Kleckner r...@mit.edu wrote:
On Thu, Jan 21, 2010 at 9:35 AM, Floris Bruynooghe
floris.bruynoo...@gmail.com 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
Hey Glyph,
On Thu, Jan 21, 2010 at 9:11 AM, Glyph Lefkowitz
gl...@twistedmatrix.com 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
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 issue
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
On Thu, Jan 21, 2010 at 3:49 PM, Barry Warsaw ba...@python.org 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
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 from
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
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:
On Thu, Jan 21, 2010 at 12:20 PM, Collin Winter collinwin...@google.com wrote:
Hey Greg,
On Wed, Jan 20, 2010 at 10:54 PM, Gregory P. Smith g...@krypto.org 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
On Thu, Jan 21, 2010 at 6:16 PM, s...@pobox.com 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?
On Thu, Jan 21, 2010 at 9:19 PM, Jesse Noller jnol...@gmail.com wrote:
On Thu, Jan 21, 2010 at 6:16 PM, s...@pobox.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Noller wrote:
On Thu, Jan 21, 2010 at 6:16 PM, s...@pobox.com 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
-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
On Thu, Jan 21, 2010 at 5:07 PM, David Malcolm dmalc...@redhat.com 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
On Thu, Jan 21, 2010 at 9:49 PM, Tres Seaver tsea...@palladion.com 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
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 this
On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz
gl...@twistedmatrix.com 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
81 matches
Mail list logo
