Women in Technology

Hear us Roar



Article:
  Why I Stopped Coding and Why I'd Start Again
Subject:   It's not the URLs, it's the APIs
Date:   2007-01-24 07:01:23
From:   Dave_Turvene
As a person who continues to code and enjoys
doing it in Python, I think you touch on a number of great points, but a DNS-style lookup of packages is not a significant advancement to me except in the case of small embedded devices, which I no longer work upon.


Here's why:


Currently, I generally (not always, but generally) have to follow this design cycle to integrate python packages, even standard ones:


1. Find a package that meets my requirements and possibly download it
2. Understand the API
3. Extend the API via wrappers, subclassing or decorators for my application
4. Use the custom API in my appl
5. Package everything into a single distribution


Steps #2, #3 and #4 are the big ones. In comparison steps #1 and #5 are relatively trivial.


The major work is BECAUSE everyone has a different interpretation of a "good" API. You mention your frustration with database packages. Taking extremes, the pysqlite, RSDP (from your 2005 article) and ZODB APIs are pretty nice once you learn them but they are radically different.


You seem to have choosen SQL via XML-RPC as the DBMS API of choice and, based upon that, you suggest a python standard library. However, it excludes everything non-XML and non-SQLish. Thus I see another set of "standard" libraries OR just have everyone say "There's only one way to do this", bite the bullet and use your API. Another common API problem is logging - everyone has a different logging interface.


And I didn't even talk about maintaining a logical migration path for "standard package" versions. Just look at the migration of sqlite, pysqlite2 and sqlite3 for an example.


Full Threads Newest First

Showing messages 1 through 1 of 1.

  • It's not the URLs, it's the APIs
    2007-01-24 09:55:42  Brian McConnell | O'Reilly AuthorO'Reilly Blogger [View]

    I agree that this technique does not eliminate the need to understand whatever modules you choose to use in a project.

    The purpose of this is to make distribution much simpler. With this model, you'd just copy your code onto a machine. At runtime, it automagically fetches and caches the libraries it needs. At design time, your development environment would mimic what a runtime environment is going to do with the hyperlinked modules so you'll have an idea how it's going to behave in the real world.

    As you mention, this is particularly relevant to non-PC devices, especially because of the potential to cache and discard infrequently used modules to deal with limited storage, etc. While that's not needed on a PC with 300GB of disk, it's nice to know that if "Hyper Python" or "Hyper ____" became common, you could build apps for either category of device knowing this would be handled for you.