Re: [ZODB-Dev] BTrees and ZODB simplicity

2013-07-22 Thread Jim Fulton
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

2013-07-22 Thread Christian Tismer

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

2013-07-22 Thread Stephan Richter
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

2013-07-22 Thread Jim Fulton
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