Hi,
Stefan Brunthaler started a thread on python-dev about a couple of patches
he has written for CPython as part of his PhD. It seems that he has
implemented inline caching for CPython.
http://comments.gmane.org/gmane.comp.python.devel/115362
http://en.wikipedia.org/wiki/Inline_caching
Sorry, this should have gone to cython-dev, not python-dev ...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Thu, Jul 22, 2010 at 6:50 PM, Eric Smith e...@trueblade.com wrote:
Thanks for writing this, Tim.
On 7/21/10 11:11 AM, Tim Golden wrote:
The issue of a __format__ equivalent for bytes was also raised as was the
idea of object methods to render an object as string or bytes, which could
be
Hi,
I guess it would be a good idea to quickly outline my inline caching
approach, so that we all have a basic understanding of how it works.
If we take for instance the BINARY_ADD instruction, the interpreter
evaluates the actual operand types and chooses the matching operation
implementation at
stefan brunthaler, 23.07.2010 08:48:
I guess it would be a good idea to quickly outline my inline caching
approach, so that we all have a basic understanding of how it works.
Yes, that certainly makes it easier to discuss.
If we take for instance the BINARY_ADD instruction, the interpreter
On 22 Jul, 2010, at 15:40, Barry Warsaw wrote:
Abstract
PEP 3147 [1]_ described an extension to Python's import machinery that
improved the sharing of Python source code, by allowing more than one
byte compilation file (.pyc) to be co-located with each source file.
This PEP
This sounds like wpython (a CPython derivative with a wider set of byte code
commands) could benefit from it.
I am aware of the wpython project of Cesare di Mauro. I change the
instruction format from bytecode to wordcode, too (because it allows
for more efficient instruction decoding).
2010/7/23 Stefan Behnel stefan...@behnel.de
stefan brunthaler, 23.07.2010 08:48:
If we take for instance the BINARY_ADD instruction, the interpreter
evaluates the actual operand types and chooses the matching operation
implementation at runtime, i.e., operands that are unicode strings
will
On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote:
Note that I'll revert Doc/distutils as well, but I need to check first
with Ronald a few Mac OS X points.
Not just a few point, the revert completely broke universal builds on OSX. I'm
working on a fix.
Ronald
On 23 Jul, 2010, at 10:12, Ronald Oussoren wrote:
On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote:
Note that I'll revert Doc/distutils as well, but I need to check first
with Ronald a few Mac OS X points.
Not just a few point, the revert completely broke universal builds on OSX.
I'm
2010/7/23 Ronald Oussoren ronaldousso...@mac.com:
On 23 Jul, 2010, at 10:12, Ronald Oussoren wrote:
On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote:
Note that I'll revert Doc/distutils as well, but I need to check first
with Ronald a few Mac OS X points.
Not just a few point, the revert
On 23 Jul, 2010, at 10:47, Tarek Ziadé wrote:
2010/7/23 Ronald Oussoren ronaldousso...@mac.com:
On 23 Jul, 2010, at 10:12, Ronald Oussoren wrote:
On 22 Jul, 2010, at 14:01, Tarek Ziadé wrote:
Note that I'll revert Doc/distutils as well, but I need to check first
with Ronald a few
On Jul 22, 2010, at 03:58 PM, Ronald Oussoren wrote:
I guess this is not an explicit goal of this PEP, but the structure is
very close to supporting multiple system architectures at the same
time. I regularly develop code that needs to run on Windows, Linux
and OSX and it is very convenient to
On Thu, Jul 22, 2010 at 13:00, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 22 Jul 2010 08:51:57 +0100
Brett Cannon br...@python.org wrote:
That's an option. I just remember Tim bringing up something about that
approach that didn't quite work as a complete replacement for __del__.
On 07/22/2010 01:34 PM, Georg Brandl wrote:
Timings (seconds to run the test suite):
re 26.689 26.015 26.008
regex 26.066 25.797 25.865
So, I thought there wasn't a difference in performance for this use case
(which is compiling a lot of regexes and matching most of them only a
few
On Thu, Jul 22, 2010 at 14:48, Antoine Pitrou solip...@pitrou.net wrote:
Hello all,
PEP 360 - “Externally Maintained Packages” seems to have outdated
contents.
First of all, I don't think Optik and wsgiref are externally
maintained anymore (both seem unmaintained by their original
On Fri, Jul 23, 2010 at 1:00 AM, David Cournapeau courn...@gmail.com wrote:
On Thu, Jul 22, 2010 at 10:08 PM, stefan brunthaler
sbruntha...@gmail.com wrote:
Is the source code under an open source non-copyleft license?
I am (unfortunately) not employed or funded by anybody, so I think
that I
On 23 Jul, 2010, at 11:02, Barry Warsaw wrote:
On Jul 22, 2010, at 03:58 PM, Ronald Oussoren wrote:
I guess this is not an explicit goal of this PEP, but the structure is
very close to supporting multiple system architectures at the same
time. I regularly develop code that needs to run on
On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote:
I'd be open to adding the
platform name to the tag, but I'd probably define it as part of the
implementation field, e.g. foo.cpython-linux2-32m.so. Or maybe
start with the platform name, e.g. foo.linux2-cpython-32m. This
isn't a strong
On Fri, Jul 23, 2010 at 12:40 AM, Barry Warsaw ba...@python.org wrote:
Python implementations *MAY* include additional flags in the file name
tag as appropriate. For example, on POSIX systems these flags will
also contribute to the file name:
* ``--with-pydebug`` (flag: ``d``)
*
On Thu, Jul 22, 2010 at 19:19, P.J. Eby p...@telecommunity.com wrote:
At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote:
At EuroPython, I sat down with Brett and we propose an approach
how namespace packages get along with import hooks. I reshuffled
the order in which things get done a
On 23 Jul, 2010, at 11:54, Barry Warsaw wrote:
On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote:
I'd be open to adding the
platform name to the tag, but I'd probably define it as part of the
implementation field, e.g. foo.cpython-linux2-32m.so. Or maybe
start with the platform name,
On Fri, Jul 23, 2010 at 8:16 PM, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
The performance trade-off should make regex slower with sufficiently small
compiled regex cache, when a lot of time is wasted on compilation. But as
the cache gets larger (and, for fairness, of the same size in both
On 7/23/2010 11:57 AM, Brett Cannon wrote:
On Thu, Jul 22, 2010 at 19:19, P.J. Eby p...@telecommunity.com
mailto:p...@telecommunity.com wrote:
At 01:51 PM 7/22/2010 +0100, Martin v. Löwis wrote:
At EuroPython, I sat down with Brett and we propose an approach
how
Ronald Oussoren ronaldousso...@mac.com writes:
On 23 Jul, 2010, at 11:54, Barry Warsaw wrote:
What about the architecture (i386, amd64)? With every increase in length I
start to get more concerned. We could encode the platform and architecture,
but that gets into cryptic territory.
Am 23.07.2010 11:16, schrieb Hrvoje Niksic:
On 07/22/2010 01:34 PM, Georg Brandl wrote:
Timings (seconds to run the test suite):
re 26.689 26.015 26.008
regex 26.066 25.797 25.865
So, I thought there wasn't a difference in performance for this use case
(which is compiling a lot of
ACTIVITY SUMMARY (2010-07-16 - 2010-07-23)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2826 open (+62) / 18349 closed (+21) / 21175 total (+83)
Open issues with patches: 1151
On Mon, Jul 12, 2010 at 02:13, Jesse Noller jnol...@gmail.com wrote:
On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum gu...@python.org
wrote:
[snip]
Great points Jesse! Since I really don't have the time or expertise to
make a judgment on this PEP, I hereby appoint you chair of the
At 11:57 AM 7/23/2010 +0100, Brett Cannon wrote:
On Thu, Jul 22, 2010 at 19:19, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
What does is not a package actually mean in that context?
The module is a module but not a package.
Um... that's not any clearer. Are you
On Fri, Jul 23, 2010 at 1:58 AM, stefan brunthaler
ste...@brunthaler.net wrote:
Do I understand correctly that you modify the byte code of modules/functions
at runtime?
Yes. Quickening is runtime only optimization technique that rewrites
instructions from a generic instruction to an optimized
Thanks, everyone who followed up here and on the tracker. I am
readying the patch for check in, but as I look back through the
messages, I don't really see anyone's answer to the question in the
subject:
* Include datetime.py in stdlib or not?
I hope this means an implied yes, include. Since
2010/7/23 Alexander Belopolsky alexander.belopol...@gmail.com:
Thanks, everyone who followed up here and on the tracker. I am
readying the patch for check in, but as I look back through the
messages, I don't really see anyone's answer to the question in the
subject:
* Include datetime.py
2010/7/23 stefan brunthaler ste...@brunthaler.net
This sounds like wpython (a CPython derivative with a wider set of byte
code
commands) could benefit from it.
I am aware of the wpython project of Cesare di Mauro.
wpython has reached 1.1 final version. If you are interested, you can
How do you generate the specialized opcode implementations?
I have a small code generator written in Python that uses Mako
templates to generate C files that can be included in the main
interpreter. It is a data driven approach that uses type information
gathered by gdb and check whether given
wpython has reached 1.1 final version. If you are interested, you can find
it here: http://code.google.com/p/wpython2/ and you can download the new
slides that cover the improvements over 1.0 alpha.
Thanks for the hint, I will definitely check your new slides.
Did you used wpython wordcode
On Fri, Jul 23, 2010 at 11:26 AM, stefan brunthaler
ste...@brunthaler.net wrote:
I'm guessing from your comments below about cross-module inlining that
you generate a separate .c file with the specialized opcode bodies and
then call through to them via a table of function pointers indexed by
I think I was wrong, but now I understand. The inlining you want is
to get the nb_add body, not the opcode body.
Exactly. This would increase performace by quite a bit -- I will start
experimentation with that stuff a.s.a.p.
The example you've given brings up a correctness issue. It seems
On Jul 23, 2010, at 12:54 PM, Barry Warsaw wrote:
On Jul 23, 2010, at 11:48 AM, Ronald Oussoren wrote:
I'd be open to adding the
platform name to the tag, but I'd probably define it as part of the
implementation field, e.g. foo.cpython-linux2-32m.so. Or maybe
start with the platform name,
On Jul 23, 2010, at 01:46 PM, sch...@gmail.com wrote:
Doesn't anybody else think this is lost work for very little gain? My
/usr/lib/python2.6/site-packages directory consumes 200MB on disk. I
couldn't care less if my /usr/lib/python2.5/site-packages consumed the
same amount of disk space...
On Jul 23, 2010, at 08:56 PM, Nick Coghlan wrote:
On Fri, Jul 23, 2010 at 12:40 AM, Barry Warsaw ba...@python.org
wrote:
Python implementations *MAY* include additional flags in the file
name tag as appropriate. For example, on POSIX systems these flags
will also contribute to the file name:
Is there any money to pay for the forthcoming 10th birthday party for
this issue? Is the OP still alive?
Kindest regards.
Mark Lawrence.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 23 July 2010 23:26, Mark Lawrence breamore...@yahoo.co.uk wrote:
Is there any money to pay for the forthcoming 10th birthday party for this
issue? Is the OP still alive?
I'm not sure the sarcasm helps much. What do you suggest should be
done with the request? Nobody has provided a patch, so
I am changing the subject from http://bugs.python.org/issue231540,;
because if there was a prize for a non-descriptive subject, OP would
win it.
There must be a good reason why traditional software development tools
such as debugger, profiler and coverage are mostly neglected in
python. Terry
On 24/07/2010 00:09, Paul Moore wrote:
On 23 July 2010 23:26, Mark Lawrencebreamore...@yahoo.co.uk wrote:
Is there any money to pay for the forthcoming 10th birthday party for this
issue? Is the OP still alive?
I'm not sure the sarcasm helps much. What do you suggest should be
done with the
On 7/23/2010 6:26 PM, Mark Lawrence wrote:
Is there any money to pay for the forthcoming 10th birthday party for
this issue? Is the OP still alive?
This reminds me of some low priority items on my todo list ;-)
Hmmm. Right now there are 756 open feature requests out of 2779 open
issues.
This regards the following feature request.
http://bugs.python.org/issue2001
Summery:
The pydoc gui enhancement patch adds a navigation bar on each page with
features that correspond to abilities that are currently available to help.
ie.. a get field, to get help on an item, a find
On 24 July 2010 01:39, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 24/07/2010 00:09, Paul Moore wrote:
On 23 July 2010 23:26, Mark Lawrencebreamore...@yahoo.co.uk wrote:
Is there any money to pay for the forthcoming 10th birthday party for
this
issue? Is the OP still alive?
I'm not
On Fri, Jul 23, 2010 at 5:18 PM, Simon de Vlieger si...@ikanobori.jp wrote:
On 24 July 2010 01:39, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 24/07/2010 00:09, Paul Moore wrote:
On 23 July 2010 23:26, Mark Lawrencebreamore...@yahoo.co.uk wrote:
Is there any money to pay for the
On Thu, Jul 22, 2010 at 9:24 AM, gregory.smi...@sympatico.ca wrote:
I agree with the idea, but a far less radical change is needed to get the
desired result.
The basic idea is this: it should be possible to use any name as an
identifier in the syntax, including names
like 'while' and
On Fri, Jul 23, 2010 at 18:39, Mark Lawrence breamore...@yahoo.co.ukwrote:
On 24/07/2010 00:09, Paul Moore wrote:
On 23 July 2010 23:26, Mark Lawrencebreamore...@yahoo.co.uk wrote:
Is there any money to pay for the forthcoming 10th birthday party for
this
issue? Is the OP still alive?
On Sat, 24 Jul 2010 12:42:12 pm Brian Curtin wrote:
First off, thanks for your time. One thing I don't feel is very
beneficial is to focus so much on the number of issues you are able
to close, because that number by itself is too high-level. Closing 10
issues might not be better than closing
On Sat, 24 Jul 2010 09:39:49 am Mark Lawrence wrote:
I'm on the verge of giving up my time because the whole system is a
complete and utter waste of my time.
[...]
Mark, you have entirely avoided the issues Paul raised. It's one thing
to fire off a snarky email implying that the Python
52 matches
Mail list logo
