[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
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 (even
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
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 file name, would it
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 to be
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 all the
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 one,
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 files are
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 much
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 context with the
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
sense that the last of these is
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.
--
Greg
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,
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 specific.
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
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 do you deal
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 of length 1 with
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 stat
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
and expected
20 matches
Mail list logo
