Differences between revisions 4 and 5
Revision 4 as of 2004-07-20 21:54:26
Size: 2423
Editor: 216-164-63-22
Comment:
Revision 5 as of 2004-07-20 22:15:20
Size: 3034
Editor: kansas
Comment: added a query
Deletions are marked like this. Additions are marked like this.
Line 25: Line 25:
-- KendallClark

Rather than be contrary again, I'll pose a question: what are the real benefits of importing from a URL, and from a URL/URI/URN literal? A URI object is of obvious value, but it's easy to imagine it being created from a string. What value is there in a literal? What can you do at the tokenizing step given a literal? What case is there for importing from a URL, when you take versions and security into account? (And C or Pyrex extensions, multiple installations, fast start-up times, unreliable network connections, etc) Like I mentioned, you can do it in PHP, but no one ever does.

-- IanBicking
Line 26: Line 32:

-- KendallClark

Ideas

Design point: are syntax changes on the table, or not?

Add a basic URL type.

Import hook for importing from URLs (e.g. http://stdlib.python.org/2.3.4/pickle)


Importing a URL is a very bad idea. First, there are security issues, as you are executing code over which you don't have control. Also, you don't generally want libraries to be upgraded behind your back. The standard library gets upgraded, but a lot of work goes into keep that backward compatible -- in other libraries, this isn't the case. You want to make upgrades explicit in that case. Languages that have the ability to import URLs -- like PHP -- almost never use it.

A URL literal doesn't seem particularly useful. It would provide an alternative to, say, url('http://something.com/whatever') (e.g., <http://something.com/whatever>), but since URLs tend to be dynamic or configurable, a literal doesn't add significant value. However, a good URL class would be excellent, maybe a class that has an API similar to the [http://www.jorendorff.com/articles/python/path/ path] module. It would be great if both modules were builtins (or at least in the standard library).

-- IanBicking

Hmm, things seem (or could be) more complex than Ian says. First, we may not mean URLs as much as we mean URIs or URNs. That is, we may want to import the equivalent of logical constants, about which we may or may not be able to learn more info by dereferencing them (in the case of HTTP URLs). Mozart/Oz language does something roughly like this.

Second, we often "execute code over which we don't have control". CPAN lets Perl users do that every day. As does PyPI. Those are manageable issues, whether you do "python setup.py install" or "import <URL>".

Third, my original idea is to start with the stdlib, not arbitrary 3rd party code.

Fourth, I don't know what "URLs tend to be dynamic or configurable" means. Even if true, and I don't think it is, I don't see how that makes a literal of no value.

-- KendallClark

Rather than be contrary again, I'll pose a question: what are the real benefits of importing from a URL, and from a URL/URI/URN literal? A URI object is of obvious value, but it's easy to imagine it being created from a string. What value is there in a literal? What can you do at the tokenizing step given a literal? What case is there for importing from a URL, when you take versions and security into account? (And C or Pyrex extensions, multiple installations, fast start-up times, unreliable network connections, etc) Like I mentioned, you can do it in PHP, but no one ever does.

-- IanBicking

What else?

References

Aaron Swartz's ideas: http://logicerror.com/webizingPython

TBL's original talk: http://www.w3.org/2002/Talks/0206-python/all.htm

Related: /F's idea for XML literals: http://effbot.org/zone/idea-xml-literal.htm

Several languages have support for some kind of XML literal, including XEN, XDuce, o:XML, Comega, and others. More later.

WebizingPython (last edited 2008-11-15 14:01:23 by localhost)

Unable to edit the page? See the FrontPage for instructions.