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 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
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 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
>
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
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_
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
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
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
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 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
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 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 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 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 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 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? 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
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 :)
>
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
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
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
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
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 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
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
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
___
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
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
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
; 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
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
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
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 :)
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
>&
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
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
_
/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
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``.
>
> +-+---+---+--+
&
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 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
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
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
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/
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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.
[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
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
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
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
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-
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
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
_
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
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
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 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
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 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 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 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?
&
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
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
>>
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
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
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 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
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, 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
>
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, 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
>>>
>>>
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 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 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
,
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 7/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > Is it intentional that Python 2.5 is (currently) shipping with
> > distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3)
> > shipped with distutils 2.4.1?
lable object which returns a TestCase or TestSuite instance.
It is not documented which of these tests takes priority: is the
classmethod "a test method within a test case class" or is it a
callable? The same issue applies to staticmethods as well.
Once I get answers to these questions,
gt;
> Consider the parallel to PEP 343's __enter__ and __exit__ methods - __exit__
> is allowed to assume that it will only be called if __enter__ succeeded,
> because that is part of the semantics of the with statement.
I can accept that.
Any thoughts on the other four items?
Coll
, it's better to use the False
spelling.
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
e developing
day-to-day in a 2.x environment are going to be so terribly interested
in "is this 3.x compliant?" that downloading a separate tool would be
an undue burden.
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
ntax error, allusions to MATLAB and assembly indirection
syntax not withstanding.
Ignoring the syntax, I'm -1 on the 2-argument form, especially since
it can only be used in an expression context; getattr() can be kept
around for this.
I'm +0 on the idea, -1 on the m
connection to pointer indirection
> meshes well with the idea of indirectly figuring out what attribute to
> access at runtime.
There's a connection, but I'd say it's the wrong one. In C, "x->y"
dereferences x, while in Python, "x->y" would dereferenc
of the if/while/etc suite and the first lineno of
the "else" suite and then search between those two for the "else"
statement.
Thoughts?
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
nd then performing multiple dynamic attribute
> accesses using those view objects.
This changes my vote: +1 on including attrview(), -1 on the syntax proposal.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
nstances have a
'body' attribute, which is a sequence of statements.
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 2/14/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Collin Winter schrieb:
> > 2) It turned out that {BinOp, BoolOp,AugAssign,etc}.op were already
> > singleton instances of their respective classes. I've changed
> > asdl_c.py to no longer
1 - 100 of 195 matches
Mail list logo
