Re: [pypy-dev] gdbm
Hi Dan, first: thanks for your help :-) On 16/11/10 03:17, Dan Stromberg wrote: Yes, the dbm module in pypy is basically like the bsddb module in cpython. cpython includes modules for bsddb, gdbm, and more. I tend to prefer gdbm over bsddb, because I've seen bsddb databases get corrupt too many times - EG, when a filesystem overflows. bsddb might be a little faster though; I've never compared their performance. So, if I understand correctly you are saying that we should rename our dbm.py to bsdb.py, and write a new dbm.py which can use either bsdb or gdbm? Sounds fine, do you feel like implementing it? :-) Moreover, I also agree with amaury that your code is very similar to the one in the current dbm.py, so we should maybe try to refactor things to share common parts between the twos. ciao, Anto ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni anto.c...@gmail.com wrote: On 16/11/10 03:17, Dan Stromberg wrote: Yes, the dbm module in pypy is basically like the bsddb module in cpython. cpython includes modules for bsddb, gdbm, and more. I tend to prefer gdbm over bsddb, because I've seen bsddb databases get corrupt too many times - EG, when a filesystem overflows. bsddb might be a little faster though; I've never compared their performance. So, if I understand correctly you are saying that we should rename our dbm.py to bsdb.py, and write a new dbm.py which can use either bsdb or gdbm? I think it's anydbm that can use whatever among dbm, bsddb, gdbm and dumbdbm, as it sees fit. TTBoMK, it's not until python 3.x that dbm becomes a sort of unifying module hierarchy. Sounds fine, do you feel like implementing it? :-) Moreover, I also agree with amaury that your code is very similar to the one in the current dbm.py, so we should maybe try to refactor things to share common parts between the twos. I'd be happy to. Would sharing based on inheritance or a more functional approach be preferred? ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
Hi, On Tue, Nov 16, 2010 at 5:27 PM, Dan Stromberg drsali...@gmail.com wrote: So, if I understand correctly you are saying that we should rename our dbm.py to bsdb.py, and write a new dbm.py which can use either bsdb or gdbm? I think it's anydbm that can use whatever among dbm, bsddb, gdbm and dumbdbm, as it sees fit. TTBoMK, it's not until python 3.x that dbm becomes a sort of unifying module hierarchy. Yes, in Python 2.x, dbm.py is very specifically an interface to the Unix dbm library (see e.g. man dbm_open). At the level of C, the gdbm interface is some kind of extension of that. It's not related to bsddb, which has a very different interface. Would sharing based on inheritance or a more functional approach be preferred? I think either is fine (or even not sharing at all if it turns out to be too much of a mess in practice). A bientôt, Armin. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On 04:27 pm, drsali...@gmail.com wrote: On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni anto.c...@gmail.com wrote: Sounds fine, do you feel like implementing it? :-) Moreover, I also agree with amaury that your code is very similar to the one in the current dbm.py, so we should maybe try to refactor things to share common parts between the twos. I'd be happy to. Would sharing based on inheritance or a more functional approach be preferred? No, avoid inheritance where possible. Composition is preferred. As for functional, I don't really know what approach you're describing with that word. Jean-Paul ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Release 1.4
Hi Phyo, On Fri, Nov 12, 2010 at 9:18 PM, Phyo Arkar phyo.arkarl...@gmail.com wrote: Is python-mysql gonna work in 1.4 ? i cant wait to run my webserver via pypy-jit Yes, you can use the CPython C extension module. It's a feature that already worked more or less since PyPy 1.3. See explanations in http://morepypy.blogspot.com/2010/06/pypy-13-released.html . Note that _mysql.c first needs a small patch in order to work, which is here: http://codespeak.net/svn/pypy/trunk/pypy/module/cpyext/patches/mysqldb.patch . Armin ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Tue, Nov 16, 2010 at 8:47 AM, Armin Rigo ar...@tunes.org wrote: Hi, On Tue, Nov 16, 2010 at 5:27 PM, Dan Stromberg drsali...@gmail.com wrote: So, if I understand correctly you are saying that we should rename our dbm.py to bsdb.py, and write a new dbm.py which can use either bsdb or gdbm? I think it's anydbm that can use whatever among dbm, bsddb, gdbm and dumbdbm, as it sees fit. TTBoMK, it's not until python 3.x that dbm becomes a sort of unifying module hierarchy. Yes, in Python 2.x, dbm.py is very specifically an interface to the Unix dbm library (see e.g. man dbm_open). At the level of C, the gdbm interface is some kind of extension of that. It's not related to bsddb, which has a very different interface. Well, there's related, and then there's related. bsddb provides a bunch of operations, including a basic hash facility. The API is not intended to be the same as gdbm or ndbm (gdbm has a native interface and an ndbm compatability interface), but the concept is similar between the 3 for one part of bsddb - the part the cpython uses. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Tue, Nov 16, 2010 at 8:38 AM, exar...@twistedmatrix.com wrote: On 04:27 pm, drsali...@gmail.com wrote: On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni anto.c...@gmail.com wrote: Sounds fine, do you feel like implementing it? :-) Moreover, I also agree with amaury that your code is very similar to the one in the current dbm.py, so we should maybe try to refactor things to share common parts between the twos. I'd be happy to. Would sharing based on inheritance or a more functional approach be preferred? No, avoid inheritance where possible. Composition is preferred. Due to performance? Or flat is better than nested - as more of a philosophical issue? I'm not arguing for inheritance, just wanting to understand the reasoning behind it. As for functional, I don't really know what approach you're describing with that word. I mean something like what you'd do in Lisp, ML or Haskell (not that I know any of those that well). I suppose in this case it would mean functools.partial() as a decorator, or perhaps a wrapper around functools.partial() used as a decorator. Then again, maybe functools.partial() imposes its own performance penalty? That's part of why I'm wondering if avoiding inheritance is a performance-related goal. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Wed, Nov 17, 2010 at 00:24, Dan Stromberg drsali...@gmail.com wrote: On Tue, Nov 16, 2010 at 8:38 AM, exar...@twistedmatrix.com wrote: On 04:27 pm, drsali...@gmail.com wrote: On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni anto.c...@gmail.com wrote: Sounds fine, do you feel like implementing it? :-) Moreover, I also agree with amaury that your code is very similar to the one in the current dbm.py, so we should maybe try to refactor things to share common parts between the twos. I'd be happy to. Would sharing based on inheritance or a more functional approach be preferred? No, avoid inheritance where possible. Composition is preferred. Due to performance? Or flat is better than nested - as more of a philosophical issue? I'm not arguing for inheritance, just wanting to understand the reasoning behind it. I answer on this because it is a general topic. Preferring composition over inheritance is a general design principle, not intended to improve performance; of course, there are cases where inheritance is good, so it needs to be further qualified; but in a very simple way, inheritance is often used where it is not appropriate. One of the reasons which come to my mind is that inheritance implies closer coupling between subclasses and superclasses. If you look for composition vs inheritance on Google, you will find quite a few articles. One which looks good is this one: http://www.artima.com/designtechniques/compoinh4.html (you can also browse the whole article, I link to page 4 because it's more interesting). That article also points out that you might get some performance overhead with composition instead of inheritance, which is the opposite of what you said, and that makes some sense; however, in many cases the overhead can be removed by an optimizer through inlining, and that's one reason not to worry. The other reason not to worry is that the overhead is anyway minor and thus design issues are more important - doing otherwise would be premature optimization. If you have a lot of experience with hard data which taught you that you should avoid something upfront, and that data is still valid, then you can avoid something upfront - and that's not the case here, because when you change your target implementation, you'll need to recheck about how it optimizes, and that takes long. As for functional, I don't really know what approach you're describing with that word. I mean something like what you'd do in Lisp, ML or Haskell (not that I know any of those that well). I suppose in this case it would mean functools.partial() as a decorator, or perhaps a wrapper around functools.partial() used as a decorator. Then again, maybe functools.partial() imposes its own performance penalty? That's part of why I'm wondering if avoiding inheritance is a performance-related goal. I can't comment in detail on this, because I just had a look at the code - but performance shouldn't be the main goal. Anyway, it looks like most differences are about calling clearerr or not, and about the module name in strings; probably one could abstract that away through some other technique. Bye! -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] Release 1.4
Oh thats cool ! THanks a lot i will try! On 11/17/10, Armin Rigo ar...@tunes.org wrote: Hi Phyo, On Fri, Nov 12, 2010 at 9:18 PM, Phyo Arkar phyo.arkarl...@gmail.com wrote: Is python-mysql gonna work in 1.4 ? i cant wait to run my webserver via pypy-jit Yes, you can use the CPython C extension module. It's a feature that already worked more or less since PyPy 1.3. See explanations in http://morepypy.blogspot.com/2010/06/pypy-13-released.html . Note that _mysql.c first needs a small patch in order to work, which is here: http://codespeak.net/svn/pypy/trunk/pypy/module/cpyext/patches/mysqldb.patch . Armin ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
Re: [pypy-dev] gdbm
On Wed, Nov 17, 2010 at 1:24 AM, Dan Stromberg drsali...@gmail.com wrote: On Tue, Nov 16, 2010 at 8:38 AM, exar...@twistedmatrix.com wrote: On 04:27 pm, drsali...@gmail.com wrote: On Tue, Nov 16, 2010 at 4:17 AM, Antonio Cuni anto.c...@gmail.com wrote: Sounds fine, do you feel like implementing it? :-) Moreover, I also agree with amaury that your code is very similar to the one in the current dbm.py, so we should maybe try to refactor things to share common parts between the twos. I'd be happy to. Would sharing based on inheritance or a more functional approach be preferred? No, avoid inheritance where possible. Composition is preferred. Due to performance? Or flat is better than nested - as more of a philosophical issue? I'm not arguing for inheritance, just wanting to understand the reasoning behind it. I think one of the points is that those are originally not related in CPython. And someone somewhere *will* use this and complain. People do crazy stuff with Python. As for functional, I don't really know what approach you're describing with that word. I mean something like what you'd do in Lisp, ML or Haskell (not that I know any of those that well). I suppose in this case it would mean functools.partial() as a decorator, or perhaps a wrapper around functools.partial() used as a decorator. Then again, maybe functools.partial() imposes its own performance penalty? That's part of why I'm wondering if avoiding inheritance is a performance-related goal. ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev ___ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
