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, raise
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 sense to you? Does it make
sense
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
the *shortest* possible
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 long
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.
Regards,
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:
DESCRIPTION
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
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
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,
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
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.
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
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;,
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
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 if it
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
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
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;, ../../../../)
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,
[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 serious about
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:
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
On 01:04 am, [EMAIL PROTECTED] wrote:[EMAIL PROTECTED] wrote:If you're serious about writing platform-agnosticpathname code, you don't put slashes in the argumentsat all. Instead you do os.path.join("hello", "slash", "world")Many of the other things you mention are also aresult of not treating
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
full_path =
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 patch any
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 languages for this
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
[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 for
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 proposal that
[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, when
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 not so sure.
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,
[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 can lead
[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.
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
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 unpythonic
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 as
On 08:14 pm, [EMAIL PROTECTED] wrote:Argh, it's difficult to respond to one topic that's now spiraling intotwo conversations on two lists.[EMAIL PROTECTED] wrote:(...) people have had to spend five years putting hard-to-reados.path functions in the code, or reinventing the wheel with their
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. All the more
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 to use
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. "Wemade this class but we don't know how it works." Actually, it'sdownright alarming coming from someone who knows Twisted inside andout yet
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
downright
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
49 matches
Mail list logo
