On Tue, Mar 29, 2016 at 6:07 PM, Michel Desmoulin <desmoulinmichel@gmail.com> wrote:
url('http://foo.com').get()
For a ftp url, what would you do ?
Ssh ?
Why path would have them and not Http. Why http and not ftp ? Why ftp and not mailto: ?
That's the nice thing about URI:s. They tell you if it's http or ftp, so the library can decide how to do a read_text() or whatever, if it is something that makes sense for that kind of URI. Already with filesystem Paths you have situations where you can't do some operation, for instance because of permissions, even if the Path points to something that exists, and still those methods exist. They will just fail. That's life. Trying to read_text() on a mailto URI should fail too.
And if we do implement get() for http, then urllib ? Or request ? But then what about http 2 ? What about asyncio ?
Yes, the asyncio / blocking io is a whole other issue. In fact, I started a thread about that almost a year ago, but I think my timing was really bad, since the async/await PEP 492 was just about to be accepted.
This needs to be sorted out first.
Alhough, I do think URLS are very important, as I'm a web dev, integrating p"http://foo.com'.get() seems dangerous. We don't know how the web is going to move, and it's moving fast, while the stdlib is slow.
I completely agree it's important to try to look into the future. However, as long as we believe the meaning of read_text() or get() will not change, how much harm can we do? I'm sure reading a text file or query from a URL is not going to disappear any time soon. - Koos