The Artima Developer Community
Sponsored Link

Python Buzz Forum
Conceptually Different

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
maxim khesin

Posts: 251
Nickname: xamdam
Registered: Mar, 2005

Maxim Khesin is developer for Liquidnet. I like C++, python, attend design patterns study group/NYC.
Conceptually Different Posted: Mar 3, 2005 10:16 PM
Reply to this message Reply

This post originated from an RSS feed registered with Python Buzz by maxim khesin.
Original Post: Conceptually Different
Feed Title: python and the web
Feed URL: http://feeds.feedburner.com/PythonAndTheWeb
Feed Description: blog dedicated to python and the networks we live in
Latest Python Buzz Posts
Latest Python Buzz Posts by maxim khesin
Latest Posts From python and the web

Advertisement
One of the main reasons I chose BGL as an insporation for my python graph library is that BGL is build around the idea of Concepts. So how does the 'Concepts' approach to libraries differ from the 'standard' approach? Let me start by describing the 'standard' approach, as it applies to our domain of choice, graph libraries. With this approach you would expect to see a central Graph class with a bunch of functions allowing you to do anything you want with a graph and then a bunch of algorithms functions that operate on this Graph class. There may be separate Graph classes for specific type of a nodes (int, string, w/e) in languages like C or parametrized types, if you are lucky enough to use C++ ;). In a language like Python there is no need to specify the node type (at the cost of some type safety) so the Graph class can rely on the actual types of the parapeters to Graph.add_edge(), Graph.add_vertex() to specify the node type. This is the basically the approach taken by pygraphlib. Taking my Amazon product traversal as a use case what I would be required to do is build up a Graph instance with Amazon data via PyAmazon, then pass the graph to the appropriate algorithm, such as bfs. Of course what I really wanted to do is to traverse the Amazon using bfs in the first place, so we have a sort of circular dependency:
bfs()->Graph instance->graph data->bfs().
I actually did implement an Amazon traversal similar to this one with just pygraphlib before, and the way I solved the problem was basically implementing bfs while I was working with PyAmazon calls, which is obviously suboptimal gives bfs() is already in the library. To be fair, Python's type system is promiscuous enough to pass a PyAmazon graph adaptor to pygraphlib without big problems (other than pygraphlib's bfs does not allow a termination condition), so the biggest difference is in the mindset. Concept-based libraries make a concsious effort to use a minimal interface in the algorithm. This is why it was so easy to adopt PyAmazon to the graph interface required by my bfs implementation - all bfs assumes is graph having an out_edges() method.

Read: Conceptually Different

Topic: das cod Previous Topic   Next Topic Topic: Bloody Brilliant

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use