Fredrik Lundh wrote:
> Andrew Dalke wrote:
>
>
>>>as I said, today's urljoin doesn't guarantee that the output is
>>>the *shortest* possible way to represent the resulting URI.
>>
>>I didn't think anyone was making that claim. The module claims
>>RFC 1808 compliance. From the docstring:
>>
>>
Fredrik Lundh schrieb:
>> urlparse.urljoin("http://blah.com/";, "../")
>>
>> should also give 'http://blah.com/'.
>
> make that: could also give 'http://blah.com/'.
How so? If that would implement RFC 3986, you can
get only a single outcome, if urljoin is meant
to implement section 5 of that RFC.
Andrew Dalke schrieb:
> Hence I would say to just grab their library. And perhaps update the
> naming scheme.
Unfortunately, this is not an option. *You* can just grab their library;
the Python distribution can't. Doing so would mean to fork, and history
tells that forks cause problems in the lon
Andrew Dalke wrote:
>> as I said, today's urljoin doesn't guarantee that the output is
>> the *shortest* possible way to represent the resulting URI.
>
> I didn't think anyone was making that claim. The module claims
> RFC 1808 compliance. From the docstring:
>
> DESCRIPTION
> See
Andrew:
> >>> urlparse.urljoin("http://blah.com/";, "..")
> 'http://blah.com/'
> >>> urlparse.urljoin("http://blah.com/";, "../")
> 'http://blah.com/../'
> >>> urlparse.urljoin("http://blah.com/";, "../..")
> 'http://blah.com/'
/F:
> as I said, today's urljoin doesn't guarantee that the output is
Martin v. Löwis wrote:
> 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 s
Martin:
> It still should be possible to come up with examples for these as
> well, no? For example, if you pass a relative URI as the base
> URI, what would you like to see happen?
Until two days ago I didn't even realize that was an incorrect
use of urljoin. I can't be the only one. Hence, rai
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
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
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
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, 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
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
Steve Holden wrote:
>> 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
Michael Urman wrote:
> On 11/3/06, Steve Holden <[EMAIL PROTECTED]> 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.ur
On 11/3/06, Steve Holden <[EMAIL PROTECTED]> 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";,
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:/
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
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
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'
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
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 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
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
Steve Holden wrote:
> Greg Ewing wrote:
>> Mike Orr wrote:
>> Having said that, I can see there could be an
>> element of confusion in calling it "join".
>>
> Good point. "relativise" might be appropriate, though something shorter
> would be better.
>
> regards
> Steve
The term used in many la
Steve Holden wrote:
> Greg Ewing wrote:
>
>>Having said that, I can see there could be an
>>element of confusion in calling it "join".
>>
>
> Good point. "relativise" might be appropriate,
Sounds like something to make my computer go at
warp speed, which would be nice, but I won't
be expecting a
Greg Ewing wrote:
> Mike Orr wrote:
>
>
>>>* This is confusing as heck:
>>> >>> os.path.join("hello", "/world")
>>> '/world'
>
>
> It's only confusing if you're not thinking of
> pathnames as abstract entities.
>
> There's a reason for this behaviour -- it's
> so you can do things like
>
>
On 01:04 am, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>If you're serious about writing platform-agnostic>pathname code, you don't put slashes in the arguments>at all. Instead you do>> os.path.join("hello", "slash", "world")>>Many of the other things you mention are also a>result of not tr
[EMAIL PROTECTED] wrote:
> Relative
> paths, if they should exist at all, should have to be explicitly linked
> as relative to something *else* (e.g. made absolute) before they can be
> used.
If paths were opaque objects, this could be enforced
by not having any way of constructing a path that
Mike Orr wrote:
> I have no idea why Microsoft thought it was a good idea to
> put the seven-odd device files in every directory. Why not force
> people to type the colon ("CON:").
Yes, this is a particularly stupid piece of braindamage
on the part of the designers of MS-DOS. As far as I
remember,
[EMAIL PROTECTED] wrote:
>>>> 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
> os.path.join are supposed to be is really hard.
If you're s
Mike Orr wrote:
>> * This is confusing as heck:
>> >>> os.path.join("hello", "/world")
>> '/world'
It's only confusing if you're not thinking of
pathnames as abstract entities.
There's a reason for this behaviour -- it's
so you can do things like
full_path = os.path.join(default_dir, fil
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 01:46 am, [EMAIL PROTECTED] wrote:
> >On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >This is ironic coming from one of Python's celebrity geniuses. "We
> >made this class but we don't know how it works." Actually, it's
>
On 01:46 am, [EMAIL PROTECTED] wrote:>On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:>This is ironic coming from one of Python's celebrity geniuses. "We>made this class but we don't know how it works." Actually, it's>downright alarming coming from someone who knows Twisted inside and>out
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On 08:14 pm, [EMAIL PROTECTED] wrote:
> >(...) people have had to spend five years putting hard-to-read
> >os.path functions in the code, or reinventing the wheel with their own
> >libraries that they're not sure they can trust. I started
On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> On 06:14 pm, [EMAIL PROTECTED] wrote:
> >[EMAIL PROTECTED] wrote:
> >
> >> I assert that it needs a better[1] interface because the current
> >> interface can lead to a variety of bugs through idiomatic, apparently
> >> correct usage. Al
On 08:14 pm, [EMAIL PROTECTED] wrote:>Argh, it's difficult to respond to one topic that's now spiraling into>two conversations on two lists.>[EMAIL PROTECTED] wrote:>(...) people have had to spend five years putting hard-to-read>os.path functions in the code, or reinventing the wheel with their own
On 06:14 pm, [EMAIL PROTECTED] wrote:>[EMAIL PROTECTED] wrote:>>> I assert that it needs a better[1] interface because the current>> interface can lead to a variety of bugs through idiomatic, apparently>> correct usage. All the more because many of those bugs are related to>> critical errors such
Argh, it's difficult to respond to one topic that's now spiraling into
two conversations on two lists.
[EMAIL PROTECTED] wrote:
> On 03:14 am, [EMAIL PROTECTED] wrote:
>
> >One thing is sure -- we urgently need something better than os.path.
> >It functions well but it makes hard-to-read and unpyt
On 10:06 am, g.brandl at gmx.net wrote:
>> What a successor to os.path needs is not security, it's a better
(more pythonic,
>> if you like) interface to the old functionality.
Glyph:
> Why?
> Rushing ... could exacerbate a very real problem, e.g.
> the security and data-integrity implications of
[EMAIL PROTECTED] wrote:
> I assert that it needs a better[1] interface because the current
> interface can lead to a variety of bugs through idiomatic, apparently
> correct usage. All the more because many of those bugs are related to
> critical errors such as security and data integrity.
in
[EMAIL PROTECTED] wrote:
> On 10:06 am, [EMAIL PROTECTED] wrote:
> >What a successor to os.path needs is not security, it's a better (more
> pythonic,
> >if you like) interface to the old functionality.
>
> Why?
>
> I assert that it needs a better[1] interface because the current
> interface
On 10:06 am, [EMAIL PROTECTED] wrote:>What a successor to os.path needs is not security, it's a better (more pythonic,>if you like) interface to the old functionality.Why?I assert that it needs a better[1] interface because the current interface can lead to a variety of bugs through idiomatic, appa
On Wed, 01 Nov 2006 11:06:14 +0100, Georg Brandl <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>> On 03:14 am, [EMAIL PROTECTED] wrote:
>>
>> >One thing is sure -- we urgently need something better than os.path.
>> >It functions well but it makes hard-to-read and unpythonic code.
>>
>> I'm
Jonathan Lange wrote:
> Then let us discuss that.
Glyph's references to bike sheds went right over your head, right?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python
On 11/1/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On 03:14 am, [EMAIL PROTECTED] wrote:
> >
> > >One thing is sure -- we urgently need something better than os.path.
> > >It functions well but it makes hard-to-read and unpythonic code.
> >
> > I'm not so sure. Th
[EMAIL PROTECTED] wrote:
> On 03:14 am, [EMAIL PROTECTED] wrote:
>
> >One thing is sure -- we urgently need something better than os.path.
> >It functions well but it makes hard-to-read and unpythonic code.
>
> I'm not so sure. The need is not any more "urgent" today than it was 5
> years ago
Fredrik Lundh wrote:
> Talin wrote:
>
>> I'm right in the middle of typing up a largish post to go on the
>> Python-3000 mailing list about this issue. Maybe we should move it over
>> there, since its likely that any path reform will have to be targeted at
>> Py3K...?
>
> I'd say that any prop
[EMAIL PROTECTED] wrote:
> I am not addressing this message to the py3k list because its general
> message of extreme conservatism on new features is more applicable to
> python-dev. However, py3k designers might also take note: if py3k is
> going to do something in this area and drop support
On 03:14 am, [EMAIL PROTECTED] wrote:>One thing is sure -- we urgently need something better than os.path.>It functions well but it makes hard-to-read and unpythonic code.I'm not so sure. The need is not any more "urgent" today than it was 5 years ago, when os.path was equally "unpythonic" and unr
Talin wrote:
> I'm right in the middle of typing up a largish post to go on the
> Python-3000 mailing list about this issue. Maybe we should move it over
> there, since its likely that any path reform will have to be targeted at
> Py3K...?
I'd say that any proposal that cannot be fit into the
I'm right in the middle of typing up a largish post to go on the
Python-3000 mailing list about this issue. Maybe we should move it over
there, since its likely that any path reform will have to be targeted at
Py3K...?
Mike Orr wrote:
> I just saw the Path object thread ("PEP 355 status", Sept-
I just saw the Path object thread ("PEP 355 status", Sept-Oct), saying
that the first object-oriented proposal was rejected. I'm in favor of
the "directory tuple" approach which wasn't mentioned in the thread.
This was proposed by Noal Raphael several months ago: a Path object
that's a sequence of
55 matches
Mail list logo
