This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fdrake
Recipients adamnelson, docs@python, fdrake, orsenthil, r.david.murray
Date 2010-05-25.17:53:23
SpamBayes Score 0.005063601
Marked as misclassified No
Message-id <AANLkTikSEnDuwp3WH4wWMJ76bCptrApdFTR6M3vlTVQh@mail.gmail.com>
In-reply-to <1274809314.18.0.171067848435.issue8818@psf.upfronthosting.co.za>
Content
On Tue, May 25, 2010 at 1:41 PM, AdamN <report@bugs.python.org> wrote:
> Although I see that nowhere in the documentation.

It needn't be in the urlparse documentation; the RFCs on URL syntax
apply here.  None of what's going on with the urlparse module is
Python specific, as far as the URL interpretation is concerned.

> It seems to me that in the scenario most people are dealing with, where
> they are getting 'cnn.com' or 'http://cnn.com' but don't know which ahead
> of time, this will be useless.  I don't see who would ever have '//cnn.com'
> without constructing that string specifically for urlsplit.

'cnn.com' isn't a URL, and there's no need for urlparse to handle it
direectly.  That just complicates things.

Doing something above and beyond what the RFCs specify means you need
to really think about the heuristics you're applying.  If there's a
useful set of heuristics that folks can agree on, that's a good case
for a new module distributed on PyPI.

  -Fred
History
Date User Action Args
2010-05-25 17:53:26fdrakesetrecipients: + fdrake, orsenthil, r.david.murray, adamnelson
2010-05-25 17:53:24fdrakelinkissue8818 messages
2010-05-25 17:53:23fdrakecreate