Alexander Belopolsky schrieb:
Multi-segment buffers are only dead because standard library modules
do not support them.
That, in turn, is because nobody has contributed code to make that work.
My guess is that people either don't need it, or find it too difficult
to implement.
In any case, it
Robert schrieb:
Would it be a possibilty in next Python to have the lock separate for
each Interpreter instance. Thus: have *interpreter_lock separate in
each PyThreadState instance and only threads of same Interpreter have
same GIL? Separation between Interpreters seems to be enough. The
Patch #1346572 proposes to also search for .pyc when OptimizeFlag
is set, and for .pyo when it is not set. The author argues this is
for consistency, as the zipimporter already does that.
This reasoning is somewhat flawed, of course: to achieve consistency,
one could also change the zipimporter
On 11/3/06, Steve Holden [EMAIL PROTECTED] wrote:
Having said this, Andrew *did* demonstrate quite convincingly that the
current urljoin has some fairly egregious directory traversal glitches.
Is it really right to punt obvious gotchas like
urlparse.urljoin(http://blah.com/a/b/c;,
On Sat, Nov 04, 2006 at 04:47:37PM +0100, Martin v. L?wis wrote:
Patch #1346572 proposes to also search for .pyc when OptimizeFlag
is set, and for .pyo when it is not set. The author argues this is
for consistency, as the zipimporter already does that.
This reasoning is somewhat flawed, of
On Nov 4, 2006, at 3:15 AM, Martin v. Löwis wrote:
Alexander Belopolsky schrieb:
Multi-segment buffers are only dead because standard library modules
do not support them.
That, in turn, is because nobody has contributed code to make that
work.
My guess is that people either don't need
Michael Urman wrote:
On 11/3/06, Steve Holden [EMAIL PROTECTED] wrote:
Having said this, Andrew *did* demonstrate quite convincingly that the
current urljoin has some fairly egregious directory traversal glitches.
Is it really right to punt obvious gotchas like
Fredrik Lundh schrieb:
However, I find the proposed behaviour reasonable: Python already
automatically imports the .pyc file if .py is not given and vice
versa. So why not look for .pyo if the .pyc file is not present?
well, from a performance perspective, it would be nice if Python looked
Steve Holden wrote:
Ah, but how do you know when that's wrong? At least under ftp:// your
root is often a mid-level directory until you change up out of it.
http:// will tend to treat the targets as roots, but I don't know that
there's any requirement for a /.. to be meaningless (even if it
Paul Chiusano schrieb:
To support this, the insert method needs to return a reference to an
object which I can then pass to adjust_key() and delete() methods.
It's extremely difficult to have this functionality with array-based
heaps because the index of an item in the array changes as items
Hi,
I'm the author of this patch and we are already using it in Python
port for Maemo platform.
We are using .pyo modules mainly to remove docstrings from the
modules. We've discussed about this patch here[1] before.
Now, I agree that the zipimport behaviour is incorrect but I don't
have other
On 11/4/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Fredrik Lundh schrieb: However, I find the proposed behaviour reasonable: Python already automatically imports the .pyc file if .py is not given and vice versa. So why not look for .pyo if the .pyc file is not present?
well, from a performance
On 11/4/06, Osvaldo Santana [EMAIL PROTECTED] wrote:
Hi,I'm the author of this patch and we are already using it in Pythonport for Maemo platform.We are using .pyo modules mainly to remove docstrings from themodules. We've discussed about this patch here[1] before.
Now, I agree that the zipimport
Martin v. Löwis [EMAIL PROTECTED] wrote:
Paul Chiusano schrieb:
To support this, the insert method needs to return a reference to an
object which I can then pass to adjust_key() and delete() methods.
It's extremely difficult to have this functionality with array-based
heaps because the
Fredrik Lundh wrote:
well, from a performance perspective, it would be nice if Python looked
for *fewer* things, not more things.
Instead of searching for things by doing a stat call
for each possible file name, would it perhaps be
faster to read the contents of all the directories
along
On Sun, 05 Nov 2006 14:21:34 +1300, Greg Ewing [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
well, from a performance perspective, it would be nice if Python looked
for *fewer* things, not more things.
Instead of searching for things by doing a stat call
for each possible file name, would it
Greg Ewing schrieb:
Fredrik Lundh wrote:
well, from a performance perspective, it would be nice if Python looked
for *fewer* things, not more things.
Instead of searching for things by doing a stat call
for each possible file name, would it perhaps be
faster to read the contents of all
On 11/4/06, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On Sun, 05 Nov 2006 14:21:34 +1300, Greg Ewing [EMAIL PROTECTED] wrote:Fredrik Lundh wrote: well, from a performance perspective, it would be nice if Python looked
for *fewer* things, not more things.Instead of searching for things by doing
18 matches
Mail list logo
