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
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
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.
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
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
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
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
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
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.
--
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
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
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
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
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
"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
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
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
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
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
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
[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
21 matches
Mail list logo
