[Off-list]
Brett Cannon wrote:
[...]
>
> Hopefully my import rewrite is flexible enough that people will be able
> to plug in their own importer/loader for the filesystem so that they can
> tune how things like this are handled (e.g., caching what files are in a
> directory, skipping bytecode f
Michael Urman writes:
> 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 (eve
Steve:
> > I'm darned if I know. I simply know that it isn't right for http resources.
/F:
> the URI specification disagrees; an URI that starts with "../" is per-
> fectly legal, and the specification explicitly states how it should be
> interpreted.
I have looked at the spec, and can't figure o
Hi Martin,
Yes, I'm familiar with the heapq module, but it doesn't do all that
I'd like. The main functionality I am looking for is the ability to
adjust the value of an item in the heap and delete items from the
heap. There's a lot of heap applications where this is useful. (I
might even say most
On Sun, Nov 05, 2006, "Martin v. L?wis" wrote:
> 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 fi
On 11/5/06, Andrew Dalke <[EMAIL PROTECTED]> wrote:
>
>I agree that supporting non-filesystem directories (zip files,
>CSV/Subversion sandboxes, URLs) would be nice, but we already have a
>big enough project without that. What constraints should a Path
>object keep in mind in order
"Paul Chiusano" <[EMAIL PROTECTED]> wrote:
>
> > It is not required. If you are careful, you can implement a pairing
> > heap with a structure combining a dictionary and list.
>
> That's interesting. Can you give an overview of how you can do that? I
> can't really picture it. You can support a
Andrew Dalke schrieb:
> I have looked at the spec, and can't figure out how its explanation
> matches the observed urljoin results. Steve's excerpt trimmed out
> the strangest example.
Unfortunately, you didn't say which of these you want explained.
As it is tedious to write down even a single on
On 11/5/06, Steve Holden <[EMAIL PROTECTED]> wrote:
[Off-list]Brett Cannon wrote:[...]>> Hopefully my import rewrite is flexible enough that people will be able> to plug in their own importer/loader for the filesystem so that they can> tune how things like this are handled (
e.g., caching what file
Aahz schrieb:
> Maybe so, but I recently dealt with a painful bottleneck in Python code
> caused by excessive stat() calls on a directory with thousands of files,
> while the os.listdir() function was bogging things down hardly at all.
> Granted, Python bytecode was almost certainly the cause of mu
Martin:
> Unfortunately, you didn't say which of these you want explained.
> As it is tedious to write down even a single one, I restrain to the
> one with the What?! remark.
>
> urlparse.urljoin("http://blah.com/a/b/c";, "../../../..") # What?!
> > 'http://blah.com/'
The "What?!" is in cont
Andrew Dalke schrieb:
urlparse.urljoin("http://blah.com/";, "..")
> 'http://blah.com/'
urlparse.urljoin("http://blah.com/";, "../")
> 'http://blah.com/../'
urlparse.urljoin("http://blah.com/";, "../..")
> 'http://blah.com/'
>
> Does the result make sense to you? Does it make
> sens
Mike Orr wrote:
> .abspath()
> .normpath()
> .realpath()
> .splitpath()
> .relpath()
> .relpathto()
Seeing as the whole class is about paths, having
"path" in the method names seems redundant. I'd
prefer to see terser method names without any
noise characters in them.
--
Martin v. Löwis wrote:
> That should never be better: the system will cache the directory
> blocks, also, and it will do a better job than Python will.
If that's really the case, then why do discussions
of how improve Python startup speeds seem to focus
on the number of stat calls made?
Also, ca
Me [Andrew]:
> > As this is not a bug, I have added the feature request 1591035 to SF
> > titled "update urlparse to RFC 3986". Nothing else appeared to exist
> > on that specific topic.
Martin:
> Thanks. It always helps to be more specific; being less specific often
> hurts.
So does being more
Travis Oliphant wrote:
> In NumPy, the data-type objects have function pointers to accomplish all
> the things NumPy does quickly.
If the datatype object is to be extracted and made a
stand-alone feature, that might need to be refactored.
Perhaps there could be a facility for traversing a
datat
On Nov 4, 2006, at 3:49 AM, Martin v. Löwis wrote:
> Notice that at least the following objects are shared between
> interpreters, as they are singletons:
> - None, True, False, (), "", u""
> - strings of length 1, Unicode strings of length 1 with ord < 256
> - integers between -5 and 256
> How d
On 11/5/06, James Y Knight <[EMAIL PROTECTED]> wrote:
>
> On Nov 4, 2006, at 3:49 AM, Martin v. Löwis wrote:
>
> > Notice that at least the following objects are shared between
> > interpreters, as they are singletons:
> > - None, True, False, (), "", u""
> > - strings of length 1, Unicode strings
Guido van Rossum wrote:
> I don't know how you define simple. In order to be able to have
> separate GILs you have to remove *all* sharing of objects between
> interpreters. And all other data structures, too. It would probably
> kill performance too, because currently obmalloc relies on the GIL.
Greg Ewing schrieb:
>> That should never be better: the system will cache the directory
>> blocks, also, and it will do a better job than Python will.
>
> If that's really the case, then why do discussions
> of how improve Python startup speeds seem to focus
> on the number of stat calls made?
A
Andrew Dalke schrieb:
>> I find there is a difference between "urllib behaves
>> non-intuitively" and "urllib gives result A for parameters B and C,
>> but should give result D instead". Can you please add specific examples
>> to your report that demonstrate the difference between implemented
>> an
21 matches
Mail list logo
