glyph:
> Path manipulation:
>
> * This is confusing as heck:
>>>> os.path.join("hello", "/world")
>'/world'
>>>> os.path.join("hello", "slash/world")
>'hello/slash/world'
>>>> os.path.join("hello", "slash//world")
>'hello/slash//world'
>Trying to formulate a general rul
Andrew Dalke wrote:
> glyph:
>
>>Path manipulation:
>>
>> * This is confusing as heck:
>> >>> os.path.join("hello", "/world")
>> '/world'
>> >>> os.path.join("hello", "slash/world")
>> 'hello/slash/world'
>> >>> os.path.join("hello", "slash//world")
>> 'hello/slash//world'
>> Trying
Steve Holden wrote:
> Although the last two smell like bugs, the point of urljoin is to make
> an absolute URL from an absolute ("current page") URL
also known as a base URL:
http://www.w3.org/TR/html4/struct/links.html#h-12.4.1
(os.path.join's behaviour is also well-defined, btw; if any
Andrew Dalke schrieb:
> >>> import urlparse
> >>> urlparse.urljoin("hello", "/world")
> '/world'
> >>> urlparse.urljoin("hello", "slash/world")
> 'slash/world'
> >>> urlparse.urljoin("hello", "slash//world")
> 'slash//world'
> >>>
>
> It does not make sense to me that these should be diffe
Travis Oliphant wrote:
> Paul Moore wrote:
>> Enough of the abstract. As a concrete example, suppose I have a (byte)
>> string in my program containing some binary data - an ID3 header, or a
>> TCP packet, or whatever. It doesn't really matter. Does your proposal
>> offer anything to me in how I mi
Martin:
> Just in case this isn't clear from Steve's and Fredrik's
> post: The behaviour of this function is (or should be)
> specified, by an IETF RFC. If somebody finds that non-intuitive,
> that's likely because their mental model of relative URIs
> deviate's from the RFC's model.
While I didn'
>
> Perhaps the most relevant thing to pull from this conversation is back
> to what Martin has asked about before: "flexible array members". A TCP
> packet has no defined length (there isn't even a header field in the
> packet for this, so in fairness we can talk about IP packets which
> do).
At 01:56 AM 11/4/2006 +0100, Andrew Dalke wrote:
>os.join assumes the base is a directory
>name when used in a join: "inserting '/' as needed" while RFC
>1808 says
>
>The last segment of the base URL's path (anything
>following the rightmost slash "/", or the entire path if
Phillip J. Eby wrote:
> At 01:56 AM 11/4/2006 +0100, Andrew Dalke wrote:
>
>>os.join assumes the base is a directory
>>name when used in a join: "inserting '/' as needed" while RFC
>>1808 says
>>
>> The last segment of the base URL's path (anything
>> following the rightmost sl
Steve Holden 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";, "../../../../")
>
> 'http:/
I was looking for a good pairing_heap implementation and came across
one that had apparently been checked in a couple years ago (!). Here
is the full link:
http://svn.python.org/view/sandbox/trunk/collections/pairing_heap.py?rev=40887&view=markup
I was just wondering about the status of this impl
Brett Cannon wrote:
> On 11/1/06, Stefan Seefeld <[EMAIL PROTECTED]> wrote:
>> Right. Brett, do we need accounts on python.org for this ?
>
>
> Yep. It just requires SSH 2 keys from each of you. You can then email
> python-dev with those keys and your first.last name and someone there will
> i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"Brett Cannon" <[EMAIL PROTECTED]> writes:
> On 11/1/06, Stefan Seefeld <[EMAIL PROTECTED]> wrote:
>>
>> Brett Cannon wrote:
>> > On 11/1/06, Stefan Seefeld <[EMAIL PROTECTED]> wrote:
>>
>> >> Right. Brett, do we need accounts on python.org for this ?
Martin v. Löwis wrote:
>Travis Oliphant schrieb:
>
>
r_field = PyDict_GetItemString(dtype,'r');
>>Actually it should read PyDict_GetItemString(dtype->fields).The
>>r_field is a tuple (data-type object, offset). The fields attribute is
>>(currently) a Python di
On 11/1/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> >
> > Right. Brett, do we need accounts on python.org for this ?
>
> Yep. It just requires SSH 2 keys from each of you. You can then email
> python-dev with those keys and your first.last name and someone there will
> install the keys for you.
repeated from c.l.p : "Feature Request: Py_NewInterpreter to create
separate GIL (branch)"
Daniel Dittmar wrote:
> robert wrote:
>> I'd like to use multiple CPU cores for selected time consuming Python
>> computations (incl. numpy/scipy) in a frictionless manner.
>>
>> Interprocess communica
On 2006/10/20, Larry Hastings wrote:
> I'm ready to post the patch.
Sheesh! Where does the time go.
I've finally found the time to re-validate and post the patch. It's
SF.net patch #1590352:
http://sourceforge.net/tracker/index.php?func=detail&aid=1590352&group_id=5470&atid=305470
I've at
On 11/3/06, Robert <[EMAIL PROTECTED]> wrote:
repeated from c.l.p : "Feature Request: Py_NewInterpreter to createseparate GIL (branch)"Daniel Dittmar wrote: > robert wrote: >> I'd like to use multiple CPU cores for selected time consuming Python
>> computations (incl. numpy/scipy) in a frictionles
Larry Hastings <[EMAIL PROTECTED]> wrote:
> But I'm open
> to suggestions, on this or any other aspect of the patch.
As Martin, I, and others have suggested, direct the patch towards Python
3.x unicode text. Also, don't be surprised if Guido says no...
http://mail.python.org/pipermail/python-30
19 matches
Mail list logo
