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 thin
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 content
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,
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 sys
"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 b
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
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 p
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 o
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 item
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
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 l
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
>>
>> >>>urlparse.ur
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'
Martin v. Löwis wrote:
> 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
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
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";,
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 in
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
Paul Chiusano schrieb:
> I was looking for a good pairing_heap implementation and came across
> one that had apparently been checked in a couple years ago (!).
Have you looked at the heapq module? What application do you have
for a pairing heap that you can't do readily with the heapq module?
Any
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
20 matches
Mail list logo
