jknupp

A shorter, more comprehensible version:

import requests

from bs4 import BeautifulSoup

from urlparse import urljoin

URL = 'http://philadelphia.craigslist.org/search/sss?sort=date&quer...

BASE = 'http://philadelphia.craigslist.org/cpg/'

response = requests.get(URL)

soup = BeautifulSoup(response.content)

for listing in soup.find_all('p',{'class':'row'}):

    if listing.find('span',{'class':'price'}):

        price = int(listing.text[2:6])

        if 100 < price <=250:

            print listing.text

            print urljoin(BASE, listing.a['href']) + '\n'

I never accused him of being a homophobe, I simply stated all that I can glean from the facts: he doesn't believe homosexuals should be allowed to marry.

Notice I never said "He should never be allowed to state his opinion." He's free to do so, and did. And in doing so made a public statement about his views. If you believe basic human rights should be denied to a group of individuals, I have an issue with that.

I agree. I'm not being consistent in my views. I'm going to continue to use JavaScript, but I don't the Eich should be running Mozilla. Humans are complicated.

jeff@jeffknupp.com please

jeff@jeffknupp.com

Sorry, seems like Disqus was serving up spammy ads along with the comments. I've disabled the ads.

The goal was not to convince anyone that they needed to use a web framework. Rather, I hoped to explain to novices exactly what a web framework is and what problems it solves.

No, I mean ZeroMQ takes care of the underlying queue for free (there is an underlying set of queues, which can be persisted if necessary)

Checkout sandman: www.sandman.io or www.github.com/jeffknupp/sandman

ZeroMQ takes care of the queueing. Though I didn't delve into it in depth in this example, you can create quite sophisticated broker-less distributed systems pretty easily with ZeroMQ.

Pickle (or any use of eval) is a security risk only if you're using it in the context of untrusted code. Basically any distributed task queue is going to have that risk if it can execute arbitrary code.

Ah, I'm sorry to hear that. Hopefully, they make their library code more readily available before closing their doors.

For someone who created their account 26 days ago, there's probably a lot you don't know... If enough people didn't find it interesting, it wouldn't be here.

I disagree. I would still have to wait for the API to return before I can proceed with the transaction and display the download page, so doing it synchronously makes more sense. And the overhead introducing Celery or python-rq would add versus the response time difference doing asynchronous email (which I'm using GMail for anyway, so I'm not too worried about it going down) makes the synchronous approach even more attractive.

Both of these have been fixed. Thanks for pointing out the off by one error and redundant session.add()

Sorry, the terminology is confusing. What I replaced are the digital goods checkout services (that use processors like Stripe in the backend). They help you manage and sell digital goods, by, for example, generating a unique token for each purchase so that every customer has a different download URL. Clearly, as seen here, they don't add much value.

I could not agree more. Stripe = insanely awesome payment processor. With all the heavy lifting they do,

I'm now unsure what something like Gumroad's value proposition is, considering I'm basically at feature parity with them (aside from PDF stamping, which I don't do anyway).

I never actually store (or see) any CC information. All of that is handled on Stripe's end.

This is the most useful thing I've heard this (short) year. I've always been looking for a way to make readline globally default to vi mode. Thanks for that.

The contact pages are now fixed. I'll be adding a link to instructions for download/trial of sandman. For now, you can use the Python installer, "pip", to install it via: "pip install sandman"

Contributions are always welcome. I've been making reasonably quick progress on it and it's getting more robust by the day. Already added features include a Django-style admin interface, user-defined HTTP methods per Model, and user-defined, per-method validation.

The two main features needed to make sandman really usable are authentication and the generation of "rel" links automatically from foreign key information. I'm working on authentication as we speak...

The point is, with Django you'd have to painstakingly reverse-engineer a Django Model from your existing database. sandman does all of this without writing any boilerplate code (aside from listing the names of the tables you want included in your API).

The difference in LOC and general frustration is huge.

Your wish is my command. Django-style admin GUI added! Check out the GitHub page for a screenshot.

Authentication is next on my list...

...because they run on Stackless Python.

I'm the original author (and didn't post this) but I fail to see how the article is FUD. In fact, the article makes the exact same point as your fourth paragraph ("Novices would..."). Controlling access to shared data often does lead to issues for many programmers, and just throwing threading at a problem is rarely a good idea.

I'm sorry you didn't find the article useful, but perhaps you're not in the article's target audience. I simply wanted to give Python novices some information and background about the GIL.

That said, the fact that other implementations do not have a GIL isn't relevant to the article; it specifically refers to the cPython implementation. And your observation that multiprocessing avoids the GIL is explicitly mentioned in the article. To say "blocking on I/O gives up the GIL" is true in a very narrow sense but not very interesting. Import any third party package using C extensions and you now need to worry about how well the author manages the GIL.

Author here.

Actually, the reason it hasn't been "solved" yet has much more to do with the cPython implementation rather than the fact that we can just use multiprocessing. There is a ton of globally shared data in the cPython implementation. Retrofitting a locking scheme granular enough to obviate the need for the GIL while at the same time not negatively impacting single-threaded performance is decidedly non-trivial.

The PyPy guys are making decent progress by attacking the problem from another angle: using software transactional memory to automatically resolve data conflicts that arise from multiple threads mutating data simultaneously.

That's confusing the language specification with one of its implementations. In Jython, for example, objects are not "just pointers".

To say that because Python passes pointers-by-value under the hood (which is true for cpython, but not other implementations) is not useful. "Call by value" and "Call by reference" have reasonably precise definitions, and Python fits neither. See http://en.wikipedia.org/wiki/Call_by_sharing#Call_by_sharing for a discussion of the difference.

Call by value would mean that a copy of the value of the argument is passed to the function without involving the original value at all. To say the binding is passed by value is not useful, as all languages would then be considered "call by value", since _something_ needs to be passed into the function, and we can just call it a value.