Re: [ZODB-Dev] BTrees and ZODB simplicity
On Sat, Jul 20, 2013 at 11:43 PM, Christian Tismer tis...@stackless.com wrote: Third rant, dear Zope-Friends (and I mean it as friends!). In an attempt to make the ZODB a small, independant package, ZODB has been split into many modules. Maybe not as many as you think: persistent, transaction, ZEO, ZODB and BTrees. 5 shrug I appreciate that, while I think it partially has the opposite effect: - splitting BTrees apart is a good idea per se. But the way as it is, it adds more Namespace-pollution than benefits: To make sense of BTrees, you need the ZODB, and only the ZODB! So, why should then BTrees be a top-level module at all? This does not feel natural, but eavesdropping, pretending as something that is untrue. I think: - BTrees should either be a ZODB sub-package in its current state, - or a real stand-alone package with some way of adding persistence as an option. I don't agree that because a package depends on ZODB it should be in ZODB. There are lots of packages that depend on ZODB. I agree with your sentiments about namespace pollution. You and I may be the only ones that care though .3 ;). Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] BTrees and ZODB simplicity
On 22.07.13 13:13, Jim Fulton wrote: On Sat, Jul 20, 2013 at 11:43 PM, Christian Tismer tis...@stackless.com wrote: Third rant, dear Zope-Friends (and I mean it as friends!). In an attempt to make the ZODB a small, independant package, ZODB has been split into many modules. Maybe not as many as you think: persistent, transaction, ZEO, ZODB and BTrees. 5 shrug I appreciate that, while I think it partially has the opposite effect: - splitting BTrees apart is a good idea per se. But the way as it is, it adds more Namespace-pollution than benefits: To make sense of BTrees, you need the ZODB, and only the ZODB! So, why should then BTrees be a top-level module at all? This does not feel natural, but eavesdropping, pretending as something that is untrue. I think: - BTrees should either be a ZODB sub-package in its current state, - or a real stand-alone package with some way of adding persistence as an option. I don't agree that because a package depends on ZODB it should be in ZODB. There are lots of packages that depend on ZODB. This is generally true. In the case of BTrees, I think the ZODB is nothing without BTrees, and BTrees make no sense without a storage and carry those _p_attributes which are not optional. BTrees would make more sense as a standalone package if the persistence model were pluggable. But that is also theoretical because I don't see right now how to split that further with all the C code. That made me think it belongs to ZODB, what else could it support, and who would ever install ZODB without it. I agree with your sentiments about namespace pollution. You and I may be the only ones that care though .3 ;). Yay, actually I care mainly because just trying 'pip install ZODB' spreads out n folders in my site-packages, and 'pip uninstall ZODB' leaves n-1 to pick the names by hand. That's why I want things nicely grouped ;-) cheers - chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] BTrees and ZODB simplicity
On Monday, July 22, 2013 02:11:04 PM Christian Tismer wrote: BTrees would make more sense as a standalone package if the persistence model were pluggable. But that is also theoretical because I don't see right now how to split that further with all the C code. I agree with this sentiment. When I wrote mongopersist, which is a MongoDB store (*not* ZODB storage!) on top of persistent and transaction, BTrees were completely useless, because MongoDB provides its own efficient mapping type. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] BTrees and ZODB simplicity
On Mon, Jul 22, 2013 at 8:11 AM, Christian Tismer tis...@stackless.com wrote: On 22.07.13 13:13, Jim Fulton wrote: On Sat, Jul 20, 2013 at 11:43 PM, Christian Tismer tis...@stackless.com wrote: Third rant, dear Zope-Friends (and I mean it as friends!). In an attempt to make the ZODB a small, independant package, ZODB has been split into many modules. Maybe not as many as you think: persistent, transaction, ZEO, ZODB and BTrees. 5 shrug I appreciate that, while I think it partially has the opposite effect: - splitting BTrees apart is a good idea per se. But the way as it is, it adds more Namespace-pollution than benefits: To make sense of BTrees, you need the ZODB, and only the ZODB! So, why should then BTrees be a top-level module at all? This does not feel natural, but eavesdropping, pretending as something that is untrue. I think: - BTrees should either be a ZODB sub-package in its current state, - or a real stand-alone package with some way of adding persistence as an option. I don't agree that because a package depends on ZODB it should be in ZODB. There are lots of packages that depend on ZODB. This is generally true. In the case of BTrees, I think the ZODB is nothing without BTrees, and BTrees make no sense without a storage and carry those _p_attributes which are not optional. This is true of every class that subclasses Persistent. BTrees would make more sense as a standalone package if the persistence model were pluggable. But that is also theoretical because I don't see right now how to split that further with all the C code. Well, it's definitely possible. Early in the evolution of BTrees, there we ifdefs that turned off dependence on persistence. But even with the dependence on Persistent, their still perfectly usable without storing them in a database. Their use is just a lot more compelling in the presence of a database. ... I agree with your sentiments about namespace pollution. You and I may be the only ones that care though .3 ;). Yay, actually I care mainly because just trying 'pip install ZODB' spreads out n folders in my site-packages, and 'pip uninstall ZODB' leaves n-1 to pick the names by hand. That's why I want things nicely grouped ;-) shrug Maybe you should use virtualenv or buildout so as to leave your site-packages alone. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
[ZODB-Dev] BTrees and ZODB simplicity
Third rant, dear Zope-Friends (and I mean it as friends!). In an attempt to make the ZODB a small, independant package, ZODB has been split into many modules. I appreciate that, while I think it partially has the opposite effect: - splitting BTrees apart is a good idea per se. But the way as it is, it adds more Namespace-pollution than benefits: To make sense of BTrees, you need the ZODB, and only the ZODB! So, why should then BTrees be a top-level module at all? This does not feel natural, but eavesdropping, pretending as something that is untrue. I think: - BTrees should either be a ZODB sub-package in its current state, - or a real stand-alone package with some way of adding persistence as an option. * there is a conclusion following as well. Thanks for audience this far ;-) cheers - chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
