On Tue, Mar 29, 2016 at 6:54 PM, Sven R. Kunze <srkunze@mail.de> wrote:
That's some post. Thanks a lot for collecting all that stuff.
On 29.03.2016 16:42, Koos Zevenhoven wrote:
[.....]
Good idea. When I suggested extending Paths (and p-strings) to work with URLs, I indeed meant that it would be an instance of (a subclass of) Path, so that you do the same as with filesystem path objects:
p'https://mysite.com/somepage.html'.read_text()
or
(p'https://mysite.com' / page).read_text()
Ah, I see. Well, that's one approach.
On the other hand, I can imagine a lot of people willing to do a "PUT", "DELETE" or "POST" (and the rather unknown other ones). It seems to me that a one-to-one mapping would be easier here instead of retrofitting.
Yeah, if subclassing Path, when the URI object gets instantiated, then the object can have all kinds of specialized methods and behavior. I mean, when the address string starts with 'https://' [*], it can instantiate a HttpsURI object or something, which provides Path stuff like .read_text() as well as more https-specific methods. [*] "https://" does not make a whole lot of sense in (the beginning of) a file-system path, even if pathlib.Path currently pretends that it does.
Although read_text might come in handy as an alias for "GET". :) That is when you don't care if you read locally or remotely. So, I can see room for this.
Yes :). - Koos