On Sun, Jan 30, 2011 at 11:33 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Maybe also
* Read and cache the directory contents and search it ourselves
instead of making a system call for every possible name.
I wouldn't do that - I would expect that this is actually slower than
I tried to find any research on this subject, but I couldn't find any,
so I'll be daring and vulnerable and just try it out to see what your
thoughts
are.
I single stepped a simple loop in Python to see where the efficiency
bottlenecks are.
I was impressed by the optimizations already in
Jurjen N.E. Bos, 31.01.2011 10:17:
I single stepped a simple loop in Python to see where the efficiency
bottlenecks are.
What version of CPython did you try that with? The latest py3k branch?
Stefan
___
Python-Dev mailing list
Python-Dev@python.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team, I'm quite happy to announce
the second release candidate of Python 3.2.
Python 3.2 is a continuation of the efforts to improve and stabilize the
Python 3.x line. Since the final release of Python 2.7, the
Jurjen N.E. Bos wrote:
I was impressed by the optimizations already in there, but I still dare
to suggest an optimization that from my estimates might shave off a few
cycles, speeding up Python about 5%.
The idea is simple: change the byte code argument values from two bytes
to one.
On 2011-01-30 21:43, Martin v. Löwis wrote:
Am 30.01.2011 17:54, schrieb Alexander Belopolsky:
On Sun, Jan 30, 2011 at 11:35 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
..
We should find a compromise between speed (limit the number of system
calls) and the usability of Python
What version of CPython did you try that with? The latest py3k branch?
I had a quick look at 3.2, 2.5 and 2.7 and got the impression that
the savings is more if the interpreter loop is faster: the fewer
instructions there are, the bigger a 3 instruction difference would
make.
The
I just did it: my first python source code hack.
I replaced the NEXTARG and PEEKARG macros in ceval.c using a cast to
short pointer, and lo and behold, a crude measurement indicates one
to two percent speed increase.
That isn't much, but it is virtually for free!
Here are the macro's I
On Mon, 31 Jan 2011 00:08:25 -0800
Guido van Rossum gu...@python.org wrote:
(Basically I am biased to believe that stat() is a pretty slow system
call -- this may just be old NFS lore though.)
I don't know about NFS, but starting a Python interpreter located on a
Samba share from a Windows VM
On Mon, 31 Jan 2011 13:28:39 +0100
Jurjen N.E. Bos jurjen@hetnet.nl wrote:
I just did it: my first python source code hack.
I replaced the NEXTARG and PEEKARG macros in ceval.c using a cast to
short pointer, and lo and behold, a crude measurement indicates one
to two percent speed
2011/1/31 Antoine Pitrou solip...@pitrou.net
On Mon, 31 Jan 2011 13:28:39 +0100
Jurjen N.E. Bos jurjen@hetnet.nl wrote:
I just did it: my first python source code hack.
I replaced the NEXTARG and PEEKARG macros in ceval.c using a cast to
short pointer, and lo and behold, a crude
On 1/31/2011 5:31 AM, Steven D'Aprano wrote:
Jurjen N.E. Bos wrote:
I was impressed by the optimizations already in there, but I still
dare to suggest an optimization that from my estimates might shave off
a few cycles, speeding up Python about 5%.
The idea is simple: change the byte code
2011/1/31 Terry Reedy tjre...@udel.edu
On 1/31/2011 5:31 AM, Steven D'Aprano wrote:
Jurjen N.E. Bos wrote:
I was impressed by the optimizations already in there, but I still
dare to suggest an optimization that from my estimates might shave off
a few cycles, speeding up Python about 5%.
On Jan 31, 2011, at 7:45 AM, Antoine Pitrou wrote:
On Mon, 31 Jan 2011 13:28:39 +0100
Jurjen N.E. Bos jurjen@hetnet.nl wrote:
I just did it: my first python source code hack.
I replaced the NEXTARG and PEEKARG macros in ceval.c using a cast to
short pointer, and lo and behold, a crude
On Jan 30, 2011, at 05:35 PM, Victor Stinner wrote:
And the real question is: should we change that before 3.2 final? If we
don't change that in 3.2, it will be harder to change it later (but it
is still possible).
I don't see how you possibly can without re-entering beta. Mucking with the
Reviewers: ,
Please review this at http://codereview.appspot.com/4080047/
Affected files:
M Tools/msi/msi.py
M Tools/msi/msilib.py
Index: Tools/msi/msi.py
===
--- Tools/msi/msi.py(revision 88279)
+++
On Mon, Jan 31, 2011 at 04:43, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 31 Jan 2011 00:08:25 -0800
Guido van Rossum gu...@python.org wrote:
(Basically I am biased to believe that stat() is a pretty slow system
call -- this may just be old NFS lore though.)
I don't know about NFS,
Hi,
2011/1/31 techto...@gmail.com:
Reviewers: ,
Please review this at http://codereview.appspot.com/4080047/
[...]
It looks good, but did you create an item in the issue tracker?
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Is there a bugs.python.org issue for this?
http://codereview.appspot.com/4080047/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more beneficial to development as it doesn't require switching
On Mon, Jan 31, 2011 at 14:45, techto...@gmail.com wrote:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more beneficial to development as it doesn't require switching from
console to browser for submitting changes.
Ok, why don't you contribute to Mercurial instead?
Am 31.01.2011 21:45, schrieb techto...@gmail.com:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Jan 28, 2011 at 10:34 PM, Christian Heimes li...@cheimes.de wrote:
Am 28.01.2011 20:29, schrieb Raymond Hettinger:
At the very least, we should add some prominent instructions for getting the
command line version up and running.
/me pops out of Guido's time machine and says: execute
Ok. Here is the patch. I used Orca to reverse installer tables of
Mercurial MSI and inserted similar entry for Python.
Also available for review at: http://codereview.appspot.com/4023055
--
anatoly t.
Index: Tools/msi/msi.py
===
---
On Mon, Jan 31, 2011 at 15:13, anatoly techtonik techto...@gmail.comwrote:
Ok. Here is the patch. I used Orca to reverse installer tables of
Mercurial MSI and inserted similar entry for Python.
Also available for review at: http://codereview.appspot.com/4023055
--
anatoly t.
That's the
On Mon, Jan 31, 2011 at 11:24 PM, Brian Curtin brian.cur...@gmail.com wrote:
On Mon, Jan 31, 2011 at 15:13, anatoly techtonik techto...@gmail.com
wrote:
Ok. Here is the patch. I used Orca to reverse installer tables of
Mercurial MSI and inserted similar entry for Python.
Also available for
On Mon, Jan 31, 2011 at 15:43, anatoly techtonik techto...@gmail.comwrote:
On Mon, Jan 31, 2011 at 11:24 PM, Brian Curtin brian.cur...@gmail.com
wrote:
On Mon, Jan 31, 2011 at 15:13, anatoly techtonik techto...@gmail.com
wrote:
Ok. Here is the patch. I used Orca to reverse installer
On Mon, Jan 31, 2011 at 10:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more beneficial to development as it doesn't require switching from
console to
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote:
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review system provides a better space for discussion if we
On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 31.01.2011 21:45, schrieb techto...@gmail.com:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no
On Mon, Jan 31, 2011 at 15:50, anatoly techtonik techto...@gmail.comwrote:
On Mon, Jan 31, 2011 at 10:54 PM, Antoine Pitrou solip...@pitrou.net
wrote:
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
On Mon, 31 Jan 2011 23:50:18 +0200
anatoly techtonik techto...@gmail.com wrote:
On Mon, Jan 31, 2011 at 10:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
Another thing to consider: on App Engine (which despite of all its
architectural weirdness uses a -- mostly -- standard Linux filesystem
for the Python code of the app) someone measured that importing from a
zipfile is much faster than importing from the filesystem. I would
imagine this
2011/1/31 anatoly techtonik techto...@gmail.com:
On Mon, Jan 31, 2011 at 10:54 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more beneficial to development as
2011/1/31 anatoly techtonik techto...@gmail.com:
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote:
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review
Brian Curtin wrote:
On Mon, Jan 31, 2011 at 15:43, anatoly techtonik techto...@gmail.com
mailto:techto...@gmail.com wrote:
That's the easy part. It doesn't cover any of the real issues with doing
this.
Please be more specific. It will also help if you integrate this part
while it's still hot.
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote:
To me polluting tracker with the
issues that are neither bugs nor feature requests only makes bug
triaging process and search more cumbersome.
Anatoly, your constant efforts to try to force python-dev to adapt to
What's the rationale of this change? It certainly doesn't remove the
dependency from win32com.client (i.e. the code continues to depend on
win32com).
http://codereview.appspot.com/4080047/
___
Python-Dev mailing list
Python-Dev@python.org
Am 31.01.2011 22:13, schrieb anatoly techtonik:
Ok. Here is the patch. I used Orca to reverse installer tables of
Mercurial MSI and inserted similar entry for Python.
This doesn't do uninstallation correctly.
Regards,
Martin
___
Python-Dev mailing
If you don't want to receive a stupid answer, why don't you read the
link and say what you don't like in this approach in a constructive
manner?
As I understand it, there used to be patc...@python.org. I'm not sure
why this was discontinued, so perhaps someone more senior should chime
in.
On Mon, Jan 31, 2011 at 22:50, anatoly techtonik techto...@gmail.com wrote:
If you don't want to receive a stupid answer, why don't you read the
link and say what you don't like in this approach in a constructive
manner?
Mercurial is a much smaller project, so it has different needs. It
would
It removes the dependency from msi.py making it easier to do the rest in
subsequent patches.
http://codereview.appspot.com/4080047/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson benja...@python.org wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review system provides a better space for discussion if we are
speaking about
Am 31.01.2011 22:58, schrieb anatoly techtonik:
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote:
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review
Am 31.01.2011 23:05, schrieb anatoly techtonik:
On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 31.01.2011 21:45, schrieb techto...@gmail.com:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to
47 matches
Mail list logo
