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 rule for what the arguments to
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 to formulate a general rule for what the
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 different.
Just in case this isn't clear
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 might
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't
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). There
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 no
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 slash /, or the
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;, ../../../../)
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=40887view=markup
I was just wondering about the status of this
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
install
-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 ?
Yep. It just
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 dictionary.
Ok. This
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.
I'll
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 communication is
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=detailaid=1590352group_id=5470atid=305470
I've
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 frictionless
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...
19 matches
Mail list logo
