Log file Viewer

[14:00:29] <MattBowen> morning all

[14:04:18] <aclark> morning MattBowen!

[14:20:12] <MattBowen> Is anyone using Pypy for anything non-hobby?

[14:20:40] <aclark> MattBowen: yes according to hazmat, IIRC

[14:21:13] <aclark> MattBowen: http://chat-logs.dcpython.org/day/dcpython/2011-11-21#16.02.02.hazmat

[14:22:12] <MattBowen> i meant like here

[14:22:25] <aclark> in that case, no AFAIK

[14:26:33] <hazmat> MattBowen, anything in particular your looking at it for?

[14:26:57] <MattBowen> hazmat: no -- honestly i'm asking myself why i haven't looked more closely at it.

[14:27:30] <MattBowen> like, i typically like new tools, but for some reason, i haven't even played with it

[14:27:46] <hazmat> MattBowen, the flip question is what sort of cpu intensive things your doing w/ python that don't have c extensions or that you can easily isolate into an rpc process

[14:28:02] <hazmat> s/rpc/worker

[14:28:27] <MattBowen> that is a good flip question

[14:28:42] <MattBowen> and the answer is, likely none, although i'd have to look at the profiling more closely

[14:29:36] <hazmat> i believe django, flask, and werkzeug can all be run under pypy, albeit only with ctypes based rdbms drivers

[14:29:53] <hazmat> some of the nosql drivers are pure python as well

[14:30:03] <hazmat> not mongo though (bson is a c ext)

[14:30:54] <MattBowen> that's ok; we are, as aclark might day, postgres 4 life here ;)

[14:31:15] <hazmat> MattBowen, there's pure postgresql driver that should work with pypy

[14:31:22] <hazmat> pg8000

[14:31:58] <MattBowen> i like how they named that

[14:33:02] <hazmat> actually.. this one looks like it should work as well ctypes based.. https://bitbucket.org/descent/pypq

[14:34:18] <MattBowen> maybe i should fool with seeing if I can get one of our apps to run under it and see if there's any benefit under our typical workload

[14:34:38] <MattBowen> then at least i'd have a better sense for what would be involved if I ever go "Pypy solves my problem!"

[14:41:08] <aclark> MattBowen: allow me to handle this for you: you haven't looked at it because… who cares? :-) j/k

[14:43:17] <hazmat> a 15-30% performance improvement for non-cacheable things if trivial would make me laugh too ;-)

[14:43:56] <MattBowen> hazmat: that's the trick -- i keep seeing that and am like, I'm foolish for not playing with this. But I feel like no one I know is

[14:44:21] <MattBowen> which seems strange to me, considering how excited people got about server-side javascript (which I realize is non-comparable, but still)

[14:45:48] <hazmat> MattBowen, i only understand serverside js from the perspective of unifying language development.. from most other perspectives i just think callback nightmare

[14:46:03] <hazmat> async networking via coroutine ftw

[14:48:39] <MattBowen> hazmat: it looks like they're getting something like that with fibers in node-land

[14:49:10] <MattBowen> but, that's sorta beside the point -- like, you're right, 15-30% performance increase of non-cacheable things is exciting, and I am surprised more people, myself included, aren't excited

[14:50:15] <hazmat> MattBowen, that would be interesting.. fibers are basically coroutines.. i dig on things like gevent because their basically offering async py with the same

[21:39:27] <aclark> I am flat out done with logging in to shit

[21:39:49] <aclark> after 10+ years ;-)

[21:40:11] <aclark> ssh host, fine. but username/password on a class C full of websites has got to go

[23:21:14] <kennethreitz> aclark: proxy?

[23:23:32] <aclark> kennethreitz: no i mean websites, something browserid might fix

[23:23:42] <kennethreitz> it'll never happen :)

[23:23:50] <aclark> oh it's happening ;-)

[23:24:43] <aclark> not that browserid itself will be the end result. but somebody has to do something…

[23:31:20] <kennethreitz> i guess it doesn't bother me..

[23:31:24] <kennethreitz> oauth, on the other hand....

[23:33:19] <j00bar> mmm... browserid... delicious single point of failure...

[23:47:16] <kennethreitz> j00bar: :)