On Wed, Jul 21, 2010 at 2:43 PM, Maciej Fijalkowski wrote:
> On Wed, Jul 21, 2010 at 6:50 PM, Reid Kleckner
> wrote:
>> On Wed, Jul 21, 2010 at 8:11 AM, Tim Golden wrote:
>>> Brett suggested that
>>> the Unladen Swallow merge to trunk was waiting for some work to complete
>>> on the JIT compile
On Mon, Jul 12, 2010 at 8:18 AM, Michael Foord
wrote:
> On 12/07/2010 15:07, Nick Coghlan wrote:
>>
>> On Mon, Jul 12, 2010 at 9:42 AM, Steven D'Aprano
>> wrote:
>>
>>>
>>> On Sun, 11 Jul 2010 09:37:22 pm Eric Smith wrote:
>>>
>
> re2 comparison is interesting from the point of if it shou
On Sun, Jul 11, 2010 at 9:28 AM, Antoine Pitrou wrote:
> On Sun, 11 Jul 2010 13:23:13 +
> Reid Kleckner wrote:
>>
>> I'm also expecting to be doing more work merging unladen-swallow into
>> the py3k-jit branch, so I was wondering if I could get commit
>> privileges for that.
>
> It sounds goo
On Fri, Jul 9, 2010 at 10:28 AM, MRAB wrote:
> anatoly techtonik wrote:
>>
>> On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote:
>>>
>>> Hi all,
>>>
>>> I re-implemented the re module, adding new features and speed
>>> improvements. It's available at:
>>>
>>> http://pypi.python.org/pypi/regex
>>>
>>>
cPickle; don't break cvs2svn, it's not fun
to fix :). I added some basic tests for this support in cPython's
Lib/test/pickletester.py.
There might be room for app-specific optimizations that do this, but
I'm not sure it would work for a general-usage cPickle that needs to
stay
On Fri, Apr 23, 2010 at 11:53 AM, Collin Winter wrote:
> On Fri, Apr 23, 2010 at 11:49 AM, Alexandre Vassalotti
> wrote:
>> On Fri, Apr 23, 2010 at 2:38 PM, Alexandre Vassalotti
>> wrote:
>>> Collin Winter wrote a simple optimization pass for cPickle in Unladen
>
On Fri, Apr 23, 2010 at 11:49 AM, Alexandre Vassalotti
wrote:
> On Fri, Apr 23, 2010 at 2:38 PM, Alexandre Vassalotti
> wrote:
>> Collin Winter wrote a simple optimization pass for cPickle in Unladen
>> Swallow [1]. The code reads through the stream and remove all the
>
On Fri, Mar 12, 2010 at 11:29 AM, wrote:
>
> >> There are major practical problems associated with making such a leap
> >> directly (Google's re2 engine is in C++ rather than C and we'd have
> >> to keep the existing implementation around regardless to handle the
> >> features that re
I'd be thrilled to mentor any
GSoC students interested in working on such a project this summer.
Lastly, anyone interested in working on Python regex performance
should take a look at the regex benchmarks in the standard benchmark
suite [2].
Thanks,
Collin Winter
[1] -
http:
On Wed, Mar 3, 2010 at 2:41 PM, Daniel Stutzbach
wrote:
> On Wed, Mar 3, 2010 at 4:34 PM, Collin Winter
> wrote:
>>
>> I would recommend patching py3k, with a backport to trunk.
>
> After thinking it over, I'm inclined to patch trunk, so I can run the
> Unlade
to implement it as
> a patch to Unladen Swallow, CPython trunk, or CPython py3k?
I would recommend patching py3k, with a backport to trunk.
Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
Hey David,
On Mon, Mar 1, 2010 at 7:29 PM, David Malcolm wrote:
> On Mon, 2010-03-01 at 15:35 -0800, Collin Winter wrote:
[snip]
>> - How would you prefer to build the JIT-less package (current options:
>> via a ./configure flag; or by deleting _llvmjit.so from the
>>
have the JIT included by default so
that it receives as much testing as possible.
Thanks,
Collin Winter
[1] - http://code.google.com/p/unladen-swallow/source/detail?r=1110
[2] - http://code.google.com/p/unladen-swallow/issues/detail?id=136
___
Pytho
On Mon, Feb 22, 2010 at 5:03 PM, Nick Coghlan wrote:
> Dirkjan Ochtman wrote:
>> On Mon, Feb 22, 2010 at 16:09, Collin Winter wrote:
>>> So the consensus is that 2to3 should be pulled out of the main Python
>>> tree? Should the 2to3 hg repository be deleted, then?
&
On Mon, Feb 22, 2010 at 4:27 PM, "Martin v. Löwis" wrote:
>>> The other thing is that we will loose some vcs history and some
>>> history granularity by switching development to the trunk version,
>>> since just the svnmerged revisions will be converted.
>>
>> So the consensus is that 2to3 should
On Mon, Feb 22, 2010 at 3:17 PM, Collin Winter wrote:
> The benchmarks repository is now available at
> http://hg.python.org/benchmarks/. It contains all the benchmarks that
> the Unladen Swallow svn repository contains, including the beginnings
> of a README.txt that describes t
On Sat, Feb 13, 2010 at 2:23 PM, Benjamin Peterson wrote:
> 2010/2/13 "Martin v. Löwis" :
>> I still think that the best approach for projects to use 2to3 is to run
>> 2to3 at install time from a single-source release. For that, projects
>> will have to adjust to whatever bugs certain 2to3 release
On Sun, Feb 21, 2010 at 9:43 PM, Collin Winter wrote:
> Hey Daniel,
>
> On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
> wrote:
>> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter
>> wrote:
>>>
>>> Would it be possible for us to get a Mercurial re
Hey Daniel,
On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach
wrote:
> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter
> wrote:
>>
>> Would it be possible for us to get a Mercurial repository on
>> python.org for the Unladen Swallow benchmarks? Maciej and I would like
On Sun, Feb 21, 2010 at 3:31 PM, Dirkjan Ochtman wrote:
> Hi Collin (and others),
>
> On Sun, Feb 21, 2010 at 15:28, Collin Winter wrote:
>> Would it be possible for us to get a Mercurial repository on
>> python.org for the Unladen Swallow benchmarks? Maciej and I woul
adding some benchmarks to their copy of the Unladen
benchmarks, and we'd like to have as well, and Mercurial seems to be
an ideal solution to this.
Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
too much, given that PEP is not about PyPy at
> all. I'm fine with any wording that is at least correct.
I've updated the language:
http://codereview.appspot.com/186247/diff2/9005:11001/11002. Thanks
for the clarifications.
Collin Winter
_
7| 1.0585x slower |
| unpickle | 28.45 | 0.78| 36.6427x faster |
I'm happy to change the wording to "slower than US on some workloads".
Thanks,
Collin Winter
___
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
To follow up on some of the open issues:
On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter wrote:
[snip]
> Open Issues
> ===
>
> - *Code review policy for the ``py3k-jit`` branch.* How does the CPython
> community want us to procede with respect to checkins on the ``py3k-
code coverage tool, which has interesting
potential, too. I've added a note about this under the "Future Work"
section: http://codereview.appspot.com/186247/diff2/9001:10002/9003
Thanks,
Collin Winter
___
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
Hey MA,
On Fri, Jan 29, 2010 at 11:14 AM, M.-A. Lemburg wrote:
> 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 benchmark
Hey Dirkjan,
[Circling back to this part of the thread]
On Thu, Jan 21, 2010 at 1:37 PM, Dirkjan Ochtman wrote:
> On Thu, Jan 21, 2010 at 21:14, Collin Winter wrote:
[snip]
>> My quick take on Cython and Shedskin is that they are
>> useful-but-limited workarounds for CPython
[Moving to python-ideas; python-dev to bcc]
On Tue, Feb 2, 2010 at 2:02 AM, M.-A. Lemburg wrote:
> Collin Winter wrote:
[snip]
>> If such a restrictive plugin-based scheme had been available when we
>> began Unladen Swallow, I do not doubt that we would have ignored it
>> en
On Mon, Feb 1, 2010 at 11:17 AM, M.-A. Lemburg wrote:
> Collin Winter wrote:
>> I think this idea underestimates a) how deeply the current CPython VM
>> is intertwined with the rest of the implementation, and b) the nature
>> of the changes required by these separate VMs.
bjects; how would those changes be pluggable? Stackless
requires so many modifications that it is effectively a fork; how
would those changes be pluggable?
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
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
rampoline functions from the traceback, parsing CPython's
bytecode in the process. If running under CPython, it assumes that the
bytecode is as it expects. We broke this in Unladen's wordcode switch.
I think parsing bytecode is a bad idea, but any switch to wordcode
should be advertised widely
eally hasn't been used before, and so
there's a fair amount of low-hanging fruit left in LLVM that no-one
has needed to pick yet.
Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
ull vendor merge can
take a while). Right now, we're using an unmodified snapshot of LLVM.
I've added language to the PEP to clarify some of these points:
- No in-tree copies of LLVM/Clang:
http://codereview.appspot.com/186247/diff2/5004:5006/5007
v to understand code generation on multiple platforms was a
distraction from what python-dev is trying to do -- develop Python. V8
still doesn't have x86-64 code generation working on Windows
(http://code.google.com/p/v8/issues/detail?id=330), so I wouldn't
underestimate the time requ
the set of LLVM libraries used by
Unladen Swallow, and we're continuing to investigate reducing on-disk
binary size (http://code.google.com/p/unladen-swallow/issues/detail?id=118
tracks this).
I've updated the PEP to reflect this configuration, since it's what
most users will pick up vi
bytecode iterator (see
http://code.google.com/p/unladen-swallow/source/browse/trunk/Util/PyBytecodeIterator.cc).
Depending on the nature of the changes, the runtime feedback system
might need to be updated, too, but it wouldn't be too difficult, and
the changes sho
Hey Floris,
On Mon, Jan 25, 2010 at 1:25 PM, Floris Bruynooghe
wrote:
> On Mon, Jan 25, 2010 at 10:14:35AM -0800, Collin Winter wrote:
>> I'm working on a patch to completely remove all traces of C++ with
>> configured with --without-llvm. It's a straightforward change,
aring out the success of our design: Google's full-time
engineers are a small minority on the project at this point, and
almost all performance-improving patches are coming from non-Google
developers.
Thanks,
Collin Winter
___
Python-Dev mailin
ence, what are these "obscure platforms" where static
initializers cause problems?
Thanks,
Collin Winter
___
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
Hey Jake,
On Thu, Jan 21, 2010 at 10:48 AM, Jake McGuire wrote:
> 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:
>>>> Pro
Hey Tony,
On Fri, Jan 22, 2010 at 10:11 AM, Tony Nelson
wrote:
> On 10-01-22 02:53:21, Collin Winter wrote:
>> On Thu, Jan 21, 2010 at 11:37 PM, Glyph Lefkowitz
>> wrote:
>> >
>> > On Jan 21, 2010, at 6:48 PM, Collin Winter wrote:
> ...
>> > The
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
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 wo
y orthogonal
to the JIT work). You can see the thread here:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/21d7248e8279b328/2343816abd1bd669
Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
and
> track this down.
We've opened http://code.google.com/p/unladen-swallow/issues/detail?id=124
to track this issue. It should be straight-forward to fix.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
ng -j never improvements.
> Do you think LLVM might suffer from a lot of memory leaks?
I don't know that it suffers from a lot of memory leaks, though we
have certainly observed and fixed quadratic memory usage in some of
the optimization passes. We've fixed all
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
rmance patches are
coming from the non-Google developers on the project (Jeffrey and I
are mostly working on infrastructure), and I believe that pattern will
continue once the py3k-jit branch is established.
Thanks,
Collin Winter
___
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
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``.
>
> +-+---+---+--+
&
/Python/llvm_notes.txt,
which goes into developer-level detail about various optimizations and
subsystems. We have other documentation in the Unladen Swallow wiki
that is being merged into llvm_notes.txt. Simply dropping this code
onto python-dev without a guide to it would be unacce
uot;don't ever use the JIT"
(-j never), "use the JIT when you think you should" (-j whenhot), and
"always the use the JIT" (-j always) options. I'll mention this in the
PEP (we'll clearly need to make this an -X option before merger).
Thanks,
Collin Winter
_
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 t
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
>&
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 :)
e or
inapplicable to Google's needs. Adding a just-in-time compiler to
Python 2.6 while designing our changes for ease of portability to
Python 3 made more sense for our environment, and we believe, is more
applicable to the environments of other Python consumers and
better-suited to the future ro
we could just ignore this point of Python
compatibility, but that's not an option, so we've had to optimize
around it. It's not that hard to do, but it's still extra work.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.o
; Okay. It's probably best for anyone with their Python developer hat on
> (which, in this forum, is all the time for any Python developer) to make
> the status of 3to2 clear when recommending it to people concerned about
> future plans.
Are you implying that we shouldn't recommend
gt; or 4.3.1 on Linux (fails in Python/ast.c). I can send you the build
>>> failures off-list, if you're interested.
>>>
>>> Thanks,
>>> Collin Winter
>>
>> I'm very interested, thanks. That's because I worked only on Windows
>> ma
On Mon, Oct 26, 2009 at 2:43 PM, Antoine Pitrou wrote:
> Collin Winter gmail.com> writes:
> [the Dave Beazley benchmark]
>> The results below are benchmarking py3k as the control, newgil as the
>> experiment. When it says "x% faster", that is a measure of newg
484922 -> 1.723093: 44.21% faster
Significant (t=184.766131, a=0.95)
Stddev: 0.02874 -> 0.02956: 2.78% larger
I'd be interested in multithreaded benchmarks with less-homogenous workloads.
Collin Winter
[1] -
http://code.google.com/p/unladen-swallow/source/browse/tests/performance/bm
E
>
> might be worth it.
I doubt it. You'd save a bit of stack manipulation, but since this
will only appear at the end of a function, I'd be skeptical that this
would make any macrobenchmarks (statistically) significantly faster.
Collin Winter
___
hen extracted using c implementation takes 0.4 seconds.
Are there any applications/frameworks which have zip files on their
critical path, where this kind of (admittedly impressive) speedup
would be beneficial? What was the motivation for writing the C
version?
Collin Winter
> On Sun, Aug 30, 2009 at 6
On Mon, Jun 29, 2009 at 6:59 PM, Jesse Noller wrote:
> Something that's been helping me squirrel out "wacky" and "fun" bugs
> in multiprocessing is running the tests in a loop - sometimes hundreds
> of times. Right now, I hack this up with a bash script, but I'm
> sitting here wondering if adding a
On Thu, Jun 18, 2009 at 7:17 PM, Benjamin Peterson wrote:
[snip]
> Backwards Compatibility Rules
> =
>
> This policy applys to all public APIs. These include the C-API, the standard
> library, and the core language including syntax and operation as defined by
> the
> r
On Tue, May 12, 2009 at 3:06 PM, Antoine Pitrou wrote:
> Hello,
>
> Just food for thought here, but seeing how 3.1 is going to be a real
> featureful
> schedule despite being released shortly after 3.0, wouldn't it make sense to
> tighten future release planning a little? I was thinking something
O compares to gcc's FDO in
terms of overall effectiveness. The results for gcc FDO with our
2009Q1 release are at the bottom of
http://code.google.com/p/unladen-swallow/wiki/Releases.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
ht
ld
failures off-list, if you're interested.
Thanks,
Collin Winter
___
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
th to improve start-up time; so far on this
thread, there's been a lot of theory and not much practice. I'd
approach this iteratively: first replace the dict with a set, then if
that bears fruit, consider a customized data structure; if that bears
fruit, etc.
Good luck, and be sure to let
airly self-contained way of starting on this. If it
>> works, please post the patch on http://bugs.python.org with your
>> results and assign it to me for review.
>>
>> Thanks,
>> Collin Winter
>>
> (I did end up subscribing, just with a different email address :)
>
on? Changing from a dict to a set looks promising,
and should be a fairly self-contained way of starting on this. If it
works, please post the patch on http://bugs.python.org with your
results and assign it to me for review.
Thanks,
Collin Winter
___
Py
On Sat, Apr 4, 2009 at 7:33 AM, Michael Foord wrote:
> Antoine Pitrou wrote:
>>
>> Nick Coghlan gmail.com> writes:
>>
>>>
>>> C. Titus Brown wrote:
>>>
I vote for a separate mailing list -- 'python-tests'? -- but I don't
know exactly how splintered to make the conversation. It pro
On Fri, Apr 3, 2009 at 10:50 AM, Antoine Pitrou wrote:
> Collin Winter gmail.com> writes:
>>
>> - I wish PyBench actually did more isolation.
>> Call.py:ComplexPythonFunctionCalls is on my mind right now; I wish it
>> didn't put keyword arguments and **kwargs i
On Fri, Apr 3, 2009 at 10:28 AM, Michael Foord
wrote:
> Collin Winter wrote:
>> As part of the common standard library and test suite that we agreed
>> on at the PyCon language summit last week, we're going to include a
>> common benchmark suite that all Python imple
On Fri, Apr 3, 2009 at 9:43 AM, Antoine Pitrou wrote:
> Thomas Wouters python.org> writes:
>>
>> Really? Have you tried it? I get at least 5% noise between runs without any
> changes. I have gotten results that include *negative* run times.
>
> That's an implementation problem, not an issue with
On Fri, Apr 3, 2009 at 2:27 AM, Antoine Pitrou wrote:
> Thomas Wouters python.org> writes:
>>
>>
>> Pystone is pretty much a useless benchmark. If it measures anything, it's the
> speed of the bytecode dispatcher (and it doesn't measure it particularly
> well.)
> PyBench isn't any better, in my
On Wed, Apr 1, 2009 at 4:29 PM, John Ehresman wrote:
> I've written a proof of concept patch to add a hook to PyDict_SetItem at
> http://bugs.python.org/issue5654 My motivation is to enable watchpoints in
> a python debugger that are called when an attribute or global changes. I
> know that thi
On Mon, Mar 30, 2009 at 7:44 AM, Jesse Noller wrote:
> During the Language summit this past Thursday, pretty much everyone
> agreed that a python 3 to python 2 tool would be a very large
> improvement in helping developers be able to write "pure" python 3
> code. The idea being a large project suc
xception handling changes ("except Foo as exc")?
Sure, that's easily possible: run 2to3 -f
some_fixer,other_fixer,this_fixer,that_fixer. You can get a full list
of fixers using the --list-fixes option.
Collin Winter
___
Python-Dev
On Fri, Mar 27, 2009 at 5:50 AM, Paul Moore wrote:
> 2009/3/27 Collin Winter :
>> In particular, Windows support is one of those things we'll need to
>> address on our end. LLVM's Windows support may be spotty, or there may
>> be other Windows issues we inadvertent
On Thu, Mar 26, 2009 at 11:26 PM, Alexandre Vassalotti
wrote:
> On Thu, Mar 26, 2009 at 11:40 PM, Collin Winter wrote:
>> In fact, right now I'm adding a last few tests before putting our cPickle
>> patches up on the tracker for further review.
>>
>
> Put me i
anguage
before we even start thinking of tinkering with the language spec.
Assigning meaning to function annotations is something that PEP 3107
explicitly avoids, and I'm not sure Unladen Swallow (or anyone else)
would want to take the plunge into coming up with broadly-acceptable
type sy
2009/3/24 Daniel Stutzbach :
> On Tue, Mar 24, 2009 at 10:13 AM, Mark Dickinson wrote:
>>
>> 2009/3/24 Daniel Stutzbach :
>> > [...]
>> > 100 nanoseconds, py3k trunk:
>> > ceval -> PyObject_GetItem (object.c) -> list_subscript (listobject.c) ->
>> > PyNumber_AsSsize_t (object.c) -> PyLong_AsSsize_
creases the minimum run-time by approx. 25% and the average run-time
> by approx. 40% on my Ubuntu 8.10 box (AMD64, Intel(R) Core(TM)2 CPU
> T7600 @ 2.33GHz).
Note that of the benchmarks tested, PyBench benefits the most from
threaded eval loop designs. Other systems benefit
On Fri, Mar 6, 2009 at 10:01 AM, Michael Haggerty wrote:
> Antoine Pitrou wrote:
>> Le vendredi 06 mars 2009 à 13:44 +0100, Michael Haggerty a écrit :
>>> Antoine Pitrou wrote:
Michael Haggerty alum.mit.edu> writes:
> It is easy to optimize the pickling of instances by giving them
>
I'm working on some performance patches for cPickle, and one of the
bigger wins so far has been replacing the Pickler's memo dict with a
custom hashtable (and hence removing memo's getters and setters). In
looking over this, Jeffrey Yasskin commented that this would break
anyone who was accessing t
On Thu, Feb 19, 2009 at 9:07 PM, Guido van Rossum wrote:
> On Thu, Feb 19, 2009 at 8:38 PM, Brett Cannon wrote:
>> On Thu, Feb 19, 2009 at 19:41, Benjamin Peterson
>> wrote:
>>> As we prepare to merge the io-c branch, the question has come up [1]
>>> about the original Python implementation. Sho
On Thu, Feb 19, 2009 at 7:17 PM, Stephen J. Turnbull
wrote:
> On Python-Ideas, Guido van Rossum writes:
>
> > On Thu, Feb 19, 2009 at 2:12 AM, Greg Ewing wrote:
>
> > > Fifth draft of the PEP. Re-worded a few things slightly
> > > to hopefully make the proposal a bit clearer up front.
> >
> >
On Tue, Feb 3, 2009 at 11:53 AM, Antoine Pitrou wrote:
> Collin Winter gmail.com> writes:
>>
>> Have any of the original objections to Calvin's patch
>> (http://bugs.python.org/issue1706256) been addressed? If not, I don't
>> see anything in these threa
e re-considered, instead of the partial_right idea?
Have any of the original objections to Calvin's patch
(http://bugs.python.org/issue1706256) been addressed? If not, I don't
see anything in these threads that justify resurrecting it.
I still haven't seen any real code presented
On Thu, Jan 29, 2009 at 6:12 AM, Ben North wrote:
> Hi,
>
> I find 'functools.partial' useful, but occasionally I'm unable to use it
> because it lacks a 'from the right' version. E.g., to create a function
> which splits a string on commas, you can't say
>
> # Won't work when called:
> split
FYI, there are options to svn blame and git to skip
whitespace-only changes.
Just-spent-an-hour-fixing-screwed-up-indents-in-changes-to-Python/*.c-ly,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listi
-- all the Python
expression can say is "yes" or "no". We have methods like this at work
and they're very useful.
That said, I see no reason why these things have to be methods. The
self. method boilerplate is cluttering line-noise in this case. I can
easily imagine a modu
On Wed, Jul 16, 2008 at 5:21 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
>>
>>
>> Michael Foord wrote:
>>>
>>> Collin Winter wrote:
>>
>>>> Is any provision being made for a 2to3 fixer/otherwise-automated
>&g
On Tue, Jul 15, 2008 at 6:03 PM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
>>
>> On Tue, Jul 15, 2008 at 6:58 AM, Ben Finney <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Backwards Compatibility
>>> ==
osing the ``fail*`` names avoids the false association
> with either of these.
>
> This is exacerbated by the plain-boolean test using a name of
> ``assert_`` (with a trailing underscore) to avoid a name collision
> with the built-in ``assert`` statement. The corresponding
> ``fail_if`` name has no such issue.
>
> PEP 8 names
> ---
>
> Although `unittest` (and its predecessor `PyUnit`) are intended to be
> familiar to users of other xUnit interfaces, there is no attempt at
> direct API compatibility since the only code that Python's `unittest`
> interfaces with is other Python code. The module is in the standard
> library and its names should all conform with PEP 8 [#PEP-8]_.
>
>
> Backwards Compatibility
> ===
>
> The names to be obsoleted should be deprecated and removed according
> to the schedule for modules in PEP 4 [#PEP-4]_.
>
> While deprecated, use of the deprecated attributes should raise a
> ``DeprecationWarning``, with a message stating which replacement name
> should be used.
Is any provision being made for a 2to3 fixer/otherwise-automated
transition for the changes you propose here?
Collin Winter
___
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
On Wed, Jul 2, 2008 at 1:09 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Agreed. A lot of the pending bugs seem to be related to the version of
>> lib2to3 in the stdlib, rather than the stand-alone product. Neal
>> Norwitz and I have been working to turn parts of 2to3 into a more
>> general
On Wed, Jul 2, 2008 at 12:51 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Why was this test disabled, rather than fixed? That seems a rather
>> poor solution to the problem of it taking longer than desired to run.
>
> I disabled it because I didn't know how to fix it, and created bug
> repor
On Tue, Jul 1, 2008 at 11:32 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 8:36 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
>> <[EMAIL PROTECTED]> wrote:
>>> On Tue, Jul 1, 2008 at 9:04 PM, Brett Cannon <[EMAIL PROTECTED]>
On Tue, Jul 1, 2008 at 7:38 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Tue, Jul 1, 2008 at 9:04 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> I just committed r64651 which is my attempt to add support to
>> fix_imports so that modules that have been split up in 3.0 can be
>> properly fi
1 - 100 of 195 matches
Mail list logo
