Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Martin v. Löwis]

> I thought that all that was happening was that BSDDB was becoming a
> separate project.  If one needs BSDDB with Python2.6, one installs it.

No, not in the way you mean it.

> Aren't there other parts of Python that require external modules, such as
> Tk?

It's different. BSDDB (the Sleepycat-then-Oracle implementation) never
was part of Python; this hasn't changed. What *has* changed is that
the bsddb module (i.e. the Python wrapper) is now not part of Python
anymore, either, due to it being maintained separately. This is as if
Tkinter was removed from Python.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Greg Ewing]

Kevin Teague wrote:

There can be subtle differences between a "stock" Python and the  system 
Python on Mac OS X 10.5.


Also there can be different versions of Python installed
in different versions of MacOSX. So if you distribute an app
that relies on the system Python, at the least you have
to test it against all the Python versions it's likely to
encounter, and possibly provide different versions of the
app for different versions of MacOSX.

Another thing to keep in mind is that if you use something
like py2app or py2exe, it doesn't include the whole Python
distribution, just the stdlib modules the app actually uses.
So it's not as bad as including a whole Python installation
for every app.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Jeroen Ruigrok van der Werven]

-On [20080905 12:34], Kevin Teague ([EMAIL PROTECTED]) wrote:
>However, all does not seem to be right with the bsddb module on the  
>system Python 2.5 on Mac OS X 10.5:
>
> >>> import bsddb
[snip]
>ImportError: No module named _bsddb

The bsddb module is built separately from Python within FreeBSD's ports. I
think Apple did the same for Mac OS X.

ports/databases/py-bsddb
ports/databases/py-bsddb3

So for a fair number of systems the 'bsddb' module being an external
package/dependency is already true.

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Honesty is the first chapter of the book of wisdom...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Kevin Teague]

On Sep 4, 2008, at 8:10 AM, C. Titus Brown wrote:


I have to say I've never had problems with a stock install of Python  
on
either Mac OS X or Windows (shockingly enough :).  I think this is  
good

advice for applications that rely on external libraries, but I just
don't see any problems with relying on Python 2.5 to contain all the
things that normally come with Python 2.5.


There can be subtle differences between a "stock" Python and the  
system Python on Mac OS X 10.5. For example, Mac OS X compiles against  
EditLine instead of GNU Readline. From "man python" on Mac OS X:


"""
The  Python  inteterpreter supports editing of the current input line  
and history substitution, similar to facilities found in the Korn  
shell and the GNU Bash shell. However, rather than being implemented  
using the GNU Readline library, this Python interpreter uses the BSD  
EditLine library editline(3) with a GNU  Readline emulation layer.

...
For  example, the rlcompleter module, which defines a completion  
function for the readline modules, works correctly with the EditLine  
libraries, but needs to be initialized somewhat differently:

...
"""

Fairly rare that you'd trip over this minor difference though -  
EditLine is more a problem on Mac OS X when trying to compile your own  
Python, since you need to install and link against GNU Readline.


However, all does not seem to be right with the bsddb module on the  
system Python 2.5 on Mac OS X 10.5:


$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
Traceback (most recent call last):
  File "", line 1, in 
  File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/bsddb/__init__.py", line 51, in 

import _bsddb
ImportError: No module named _bsddb
>>>

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Jeroen Ruigrok van der Werven]

-On [20080904 16:22], C. Titus Brown ([EMAIL PROTECTED]) wrote:
>I agree.  I like bsddb for just this reason and I'd like to continue
>being able to use it!  I think that there are many reasons why having
>such a thing in the stdlib is really useful and I also think it's worth
>exploring the ramifications of taking it out...

And having to install bsddb from an external source disables your use, how?

-- 
Jeroen Ruigrok van der Werven  / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B
Infinite Dreams, I can't deny them, Infinity is hard to comprehend...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Josiah Carlson]

On Thu, Sep 4, 2008 at 5:02 PM,  <[EMAIL PROTECTED]> wrote:
>
>me> I suggested in another message (perhaps on another thread) that
>me> maybe a dbm.sqlite module would be worth having.
>
> http://bugs.python.org/issue3783

I did a similar thing today.  I can post my version later today.

 - Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[skip]

me> I suggested in another message (perhaps on another thread) that
me> maybe a dbm.sqlite module would be worth having.

http://bugs.python.org/issue3783

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Josiah Carlson]

On Thu, Sep 4, 2008 at 10:03 AM,  <[EMAIL PROTECTED]> wrote:
>
>> Compared to sqlite, you don't need to know SQL, you can finetuning
>> (for example, using ACI instead of ACID, deciding store by store), and
>> you can do replication and distributed transactions (useful, for
>> example, if your storage is bigger than a single machine capacity,
>> like my case). If you combine Berkeley DB with Durus, for example, all
>> of this is abstracted and you simply use "regular" python objects.
>
>Titus> I agree.  I like bsddb for just this reason and I'd like to
>Titus> continue being able to use it!  I think that there are many
>Titus> reasons why having such a thing in the stdlib is really useful
>Titus> and I also think it's worth exploring the ramifications of taking
>Titus> it out...
>
> I suggested in another message (perhaps on another thread) that maybe a
> dbm.sqlite module would be worth having.  It would have a dict-ish API like
> the other dict-on-disk modules but use the sqlite module to read (SELECT)
> and write (INSERT and UPDATE) key/value pairs from the underlying database.

I offered to write one of these a couple months ago as an option for
some users who would otherwise think to use bsddb, dbm, or anydbm.
Few people saw that anything like that would be useful, detractors
stating that the expansive options available in bsddb (most of which I
didn't realize existed) made it effectively irreplaceable to the vast
majority of people who actually use bsddb for anything nontrivial.

There wasn't even feigned interest in those use-cases involving
"trivial" disk-persistent dictionaries (of which 100% of my uses have
involved over the last 10 years).

 - Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 07:01:47PM +0200, Jesus Cea wrote:
-> -BEGIN PGP SIGNED MESSAGE-
-> Hash: SHA1
-> 
-> C. Titus Brown wrote:
-> > Since I/we want to distribute pygr to end-users, this is really not a
-> > pleasant prospect.  Also often the installation of Python itself goes
-> > much more smoothly than the installation of separately compiled binary
-> > packages, for all the obvious reasons (compiler/OS versions, lib
-> > versions, etc. etc.)
-> 
-> I agree. I can check the library with Solaris 10 and several flavors of
-> Linux, but I'm particularly worried about Windows support. I'm unable to
-> provide precompiled libs, and 99.999% of windows users don't know what a
-> "compiler thing" is, let alone being able to compile anything by themselves.

I believe I might be able to help you with this.  More off-list, in a
few weeks; if anyone else needs full Windoze access, Watch This Space, as
they say.

(Yes, I know access is not enough -- you really want someone to be
paying attention on Windows, too.  I'm working on a project or two
there; access to large quantities of talented students is opening up
some ideas :)

--titus
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[A.M. Kuchling]

On Thu, Sep 04, 2008 at 09:25:43AM -0700, Bill Janssen wrote:
> Yeah, but bsddb is one of those exploding batteries.  I've used it for
> years, and have had lots and lots of problems with it.  Having SQLite
> in there is great; now we need implementations of anydbm and shelve
> which use it.

What sort of problems?  When I've used BerkleyDB in the past, it
always took a fair bit of experimenting & searching to figure out the
right combination of flags to use (and the BerkeleyDB docs were very
low-level), but once that was done it seemed to work OK.
Incorporating Jesus's docs will help users with that issue; I'm
willing to work on that before 2.6final.

I think the primary annoyance is the instability of the bsddb tests,
and the resulting bad effect on buildbot's usefulness (as we all just
get accustomed to having a patchwork of red randomly mixed in).

So why not just strip down the test cases we run to avoid the
problematic tests?  That won't help Jesus debug on platforms he can't
access, but we could re-enable those tests after 2.7 or provide a
different buildbot target that runs the entire suite.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Jeff Hall]

never mind about the limit... I was thinking SQL Express

On Thu, Sep 4, 2008 at 1:07 PM, Jeff Hall <[EMAIL PROTECTED]> wrote:

> Doesn't SQLlite still have a 4gb cap?
>
> I'd personally prefer an open source solution (if that's Berkeley so be it
> but there's plenty out there... MySQL for one)
>
>


-- 
Haikus are easy
Most make very little sense
Refrigerator
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Jeff Hall]

Doesn't SQLlite still have a 4gb cap?

I'd personally prefer an open source solution (if that's Berkeley so be it
but there's plenty out there... MySQL for one)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[skip]

> Compared to sqlite, you don't need to know SQL, you can finetuning
> (for example, using ACI instead of ACID, deciding store by store), and
> you can do replication and distributed transactions (useful, for
> example, if your storage is bigger than a single machine capacity,
> like my case). If you combine Berkeley DB with Durus, for example, all
> of this is abstracted and you simply use "regular" python objects.

Titus> I agree.  I like bsddb for just this reason and I'd like to
Titus> continue being able to use it!  I think that there are many
Titus> reasons why having such a thing in the stdlib is really useful
Titus> and I also think it's worth exploring the ramifications of taking
Titus> it out...

I suggested in another message (perhaps on another thread) that maybe a
dbm.sqlite module would be worth having.  It would have a dict-ish API like
the other dict-on-disk modules but use the sqlite module to read (SELECT)
and write (INSERT and UPDATE) key/value pairs from the underlying database.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

C. Titus Brown wrote:
> On Thu, Sep 04, 2008 at 03:23:22PM +0200, Jesus Cea wrote:
> -> Brett Cannon wrote:
> -> >> Related but tangential question that we were discussing on the pygr[0]
> -> >> mailing list -- what is the "official" word on a scalable object store
> -> >> in Python?  We've been using bsddb, but is there an alternative?  And
> -> >> what if bsddb is removed?
> -> > 
> -> > Beyond shelve there are no official plans to add a specific object store.
> -> 
> -> If you are storing million of objects, you'd better use a transactional
> -> storage, able to survive diskfulls or code/computer crashes.
> 
> We're using a write-once-read-many pattern of access, and it is simply a
> cache of a separate file (that remains around), so no, we don't better
> use a transactional storage :).

If you can recreate the database in case of problems, and it is mostly
reads, then I would suggest you gdbm. I personally hate SQL and "SQL
fits all" mentality, and the mindset/impedance mismatch between python
and objects, and SQL world, but sure sqlite module could fill the bill
also... if you don't mind mixing two languages and two logics in your
code and your brain :).

> -> I will maintain "bsddb" as a separate (downloadable via PYPI) package
> -> whatever the fate of bsddb in Python stardard library be. So bsddb is a
> -> pretty safe bet, even if you need to install it separately.
> 
> Since I/we want to distribute pygr to end-users, this is really not a
> pleasant prospect.  Also often the installation of Python itself goes
> much more smoothly than the installation of separately compiled binary
> packages, for all the obvious reasons (compiler/OS versions, lib
> versions, etc. etc.)

I agree. I can check the library with Solaris 10 and several flavors of
Linux, but I'm particularly worried about Windows support. I'm unable to
provide precompiled libs, and 99.999% of windows users don't know what a
"compiler thing" is, let alone being able to compile anything by themselves.

> I agree.  I like bsddb for just this reason and I'd like to continue
> being able to use it!  I think that there are many reasons why having
> such a thing in the stdlib is really useful and I also think it's worth
> exploring the ramifications of taking it out...

+Inf

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSMAUeZlgi5GaxT1NAQKM5gQAhEO8OmVvVXr/jp1Hqj7DnxuPb0kabeGF
TjDyiiJutbDKNLZiqegV7nzNpfJBMMZXNXTG70Lbrh05GWdzYcLahHluPzmf3hu6
wPCjv63NijH4OCmhtGmN4vi/C6p5VX1NqktN0evX7FYNJrnoYVKBRSnFdF8aPSbI
wUKKSsihJTw=
=Zv+S
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Bill Janssen]

> I have to say I've never had problems with a stock install of Python on
> either Mac OS X or Windows (shockingly enough :).  I think this is good

I agree.  I just use the stock Python on OS X and Windows.  And it
seems to work well for my rather large and complicated (PIL, PyLucene,
Medusa, ReportLab, SSL, email-4) application.  Clearly Windows, with
its somewhat complicated PATH and DLL issues, might be problematic,
but I haven't seen that yet.

> advice for applications that rely on external libraries, but I just
> don't see any problems with relying on Python 2.5 to contain all the
> things that normally come with Python 2.5.  It seems like you're
> pushing a pretty sharp dichotomy (trichotomy?) --

Yeah, but this is just some random guy on the Python mailing list
(Tony, I apologize for not knowing who you are).  No need to take it
too seriously.

> but it does validate my decade-old decision to
> avoid writing end-user applications in Python, sadly enough.

Well, I don't do that either, but it's because of Python's lack of a
decent built-in GUI toolkit.  Sad.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Bill Janssen]

> I don't think the convenience of "batteries *included*" should be
> underestimated.

Yeah, but bsddb is one of those exploding batteries.  I've used it for
years, and have had lots and lots of problems with it.  Having SQLite
in there is great; now we need implementations of anydbm and shelve
which use it.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 11:01:35AM -0400, Tony Nelson wrote:
-> At 7:37 AM -0700 9/4/08, C. Titus Brown wrote:
-> >On Thu, Sep 04, 2008 at 10:29:10AM -0400, Tony Nelson wrote:
->  ...
-> >-> Shipping an application to end users is a different problem.  Such 
packages
-> >-> should include a private copy of Python as well as of any dependent
-> >-> libraries, as tested.
-> >
-> >Why?  On Mac OS X, for example, Python comes pre-installed -- not sure
-> >if it comes with Tk yet, but the next version probably will.  On Windows
-> >there's a handy few-click installer that installs Tk.  Is there some
-> >reason why I shouldn't be relying on those distributions??
-> 
-> Yes.  An application is tested with one version of Python and one version
-> of its libraries.  When MOSX updates Python or some other library, you are
-> relying on their testing of your application.  Unless you are Adobe or
-> similarly large they didn't do that testing.  Perhaps you have noticed the
-> threads about installing a new Python release over the Python that came
-> with an OS, and how bad an idea that is?  This is the same issue, from the
-> other side.

I have to say I've never had problems with a stock install of Python on
either Mac OS X or Windows (shockingly enough :).  I think this is good
advice for applications that rely on external libraries, but I just
don't see any problems with relying on Python 2.5 to contain all the
things that normally come with Python 2.5.  It seems like you're
pushing a pretty sharp dichotomy (trichotomy?) --

 - Python library/core developers should compile it all.

 - Python app developers can rely on what they install from binaries
   themselves, but not rely on it to be present on anyone else's machine
   or OS.

 - End users should be given a complete clean install of Python in a
   different location for each application they're using, even if those
   applications depend only on the stdlib.

This seems surprisingly complicated to me (and unnecessary, in my
limited experience) -- but it does validate my decade-old decision to
avoid writing end-user applications in Python, sadly enough.  It ends up
being less work to distribute and support a C/C++ app on Windows and Mac
OS X, for crikey's sake!

--t
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Tony Nelson]

At 7:37 AM -0700 9/4/08, C. Titus Brown wrote:
>On Thu, Sep 04, 2008 at 10:29:10AM -0400, Tony Nelson wrote:
 ...
>-> Shipping an application to end users is a different problem.  Such packages
>-> should include a private copy of Python as well as of any dependent
>-> libraries, as tested.
>
>Why?  On Mac OS X, for example, Python comes pre-installed -- not sure
>if it comes with Tk yet, but the next version probably will.  On Windows
>there's a handy few-click installer that installs Tk.  Is there some
>reason why I shouldn't be relying on those distributions??

Yes.  An application is tested with one version of Python and one version
of its libraries.  When MOSX updates Python or some other library, you are
relying on their testing of your application.  Unless you are Adobe or
similarly large they didn't do that testing.  Perhaps you have noticed the
threads about installing a new Python release over the Python that came
with an OS, and how bad an idea that is?  This is the same issue, from the
other side.

>Requiring users to install anything at all imposes a barrier to use.
>That barrier rises steeply in height the more packages (with versioning
>issues, etc.) are needed.  This also increases the tech support burden
>dramatically.
 ...

Precisely why one needs to ship a single installer that installs the
complete application, including Python and any other libraries it needs.
-- 

TonyN.:'   
  '  
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 10:29:10AM -0400, Tony Nelson wrote:
-> At 6:10 AM -0500 9/4/08, [EMAIL PROTECTED] wrote:
-> >>> Related but tangential question that we were discussing on the
-> >>> pygr[0] mailing list -- what is the "official" word on a scalable
-> >>> object store in Python?  We've been using bsddb, but is there an
-> >>> alternative?  And what if bsddb is removed?
-> >
-> >Brett> Beyond shelve there are no official plans to add a specific
-> >Brett> object store.
-> >
-> >Unless something has changed while I wasn't looking, shelve requires a
-> >concrete module under the covers: bsddb, gdbm, ndbm, dumbdbm.  It's just a
-> >thin layer over one of them that makes it appear as if you can have keys
-> >which aren't strings.
-> 
-> I thought that all that was happening was that BSDDB was becoming a
-> separate project.  If one needs BSDDB with Python2.6, one installs it.
-> Aren't there other parts of Python that require external modules, such as
-> Tk?  Using Tk requires installing it.  Such things are normally packaged by
-> each distro the same way as Python is packaged ("yum install tk bsddb").
-> 
-> Shipping an application to end users is a different problem.  Such packages
-> should include a private copy of Python as well as of any dependent
-> libraries, as tested.

Why?  On Mac OS X, for example, Python comes pre-installed -- not sure
if it comes with Tk yet, but the next version probably will.  On Windows
there's a handy few-click installer that installs Tk.  Is there some
reason why I shouldn't be relying on those distributions??

Requiring users to install anything at all imposes a barrier to use.
That barrier rises steeply in height the more packages (with versioning
issues, etc.) are needed.  This also increases the tech support burden
dramatically.

I'm happy to be told that bsddb is too much of a maintenance burden for
Python 2.6/3.0 to have -- especially since it's gone from 3.0 now ;) --
but I don't think the arguments that *it won't matter that it's not
there* have been very credible.  There's a BIG difference between things
that come with Python and things that are add-ons.

Right now, I'm teaching an intro programming course using Python.  It
doesn't seem like the students are going to need to install *anything*
other than base Python in order to play with full networking libraries &
sqlite databases, among other features.  And, for me and for them,
that's really great.

I don't think the convenience of "batteries *included*" should be
underestimated.

--t
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Tony Nelson]

At 6:10 AM -0500 9/4/08, [EMAIL PROTECTED] wrote:
>>> Related but tangential question that we were discussing on the
>>> pygr[0] mailing list -- what is the "official" word on a scalable
>>> object store in Python?  We've been using bsddb, but is there an
>>> alternative?  And what if bsddb is removed?
>
>Brett> Beyond shelve there are no official plans to add a specific
>Brett> object store.
>
>Unless something has changed while I wasn't looking, shelve requires a
>concrete module under the covers: bsddb, gdbm, ndbm, dumbdbm.  It's just a
>thin layer over one of them that makes it appear as if you can have keys
>which aren't strings.

I thought that all that was happening was that BSDDB was becoming a
separate project.  If one needs BSDDB with Python2.6, one installs it.
Aren't there other parts of Python that require external modules, such as
Tk?  Using Tk requires installing it.  Such things are normally packaged by
each distro the same way as Python is packaged ("yum install tk bsddb").

Shipping an application to end users is a different problem.  Such packages
should include a private copy of Python as well as of any dependent
libraries, as tested.
-- 

TonyN.:'   
  '  
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Thu, Sep 04, 2008 at 03:23:22PM +0200, Jesus Cea wrote:
-> -BEGIN PGP SIGNED MESSAGE-
-> Hash: SHA1
-> 
-> Brett Cannon wrote:
-> >> Related but tangential question that we were discussing on the pygr[0]
-> >> mailing list -- what is the "official" word on a scalable object store
-> >> in Python?  We've been using bsddb, but is there an alternative?  And
-> >> what if bsddb is removed?
-> > 
-> > Beyond shelve there are no official plans to add a specific object store.
-> 
-> If you are storing million of objects, you'd better use a transactional
-> storage, able to survive diskfulls or code/computer crashes.

We're using a write-once-read-many pattern of access, and it is simply a
cache of a separate file (that remains around), so no, we don't better
use a transactional storage :).

-> I will maintain "bsddb" as a separate (downloadable via PYPI) package
-> whatever the fate of bsddb in Python stardard library be. So bsddb is a
-> pretty safe bet, even if you need to install it separately.

Since I/we want to distribute pygr to end-users, this is really not a
pleasant prospect.  Also often the installation of Python itself goes
much more smoothly than the installation of separately compiled binary
packages, for all the obvious reasons (compiler/OS versions, lib
versions, etc. etc.)

-> Compared to sqlite, you don't need to know SQL, you can finetuning (for
-> example, using ACI instead of ACID, deciding store by store), and you
-> can do replication and distributed transactions (useful, for example, if
-> your storage is bigger than a single machine capacity, like my case). If
-> you combine Berkeley DB with Durus, for example, all of this is
-> abstracted and you simply use "regular" python objects.

I agree.  I like bsddb for just this reason and I'd like to continue
being able to use it!  I think that there are many reasons why having
such a thing in the stdlib is really useful and I also think it's worth
exploring the ramifications of taking it out...

--t
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brett Cannon wrote:
>> Related but tangential question that we were discussing on the pygr[0]
>> mailing list -- what is the "official" word on a scalable object store
>> in Python?  We've been using bsddb, but is there an alternative?  And
>> what if bsddb is removed?
> 
> Beyond shelve there are no official plans to add a specific object store.

If you are storing million of objects, you'd better use a transactional
storage, able to survive diskfulls or code/computer crashes.

I will maintain "bsddb" as a separate (downloadable via PYPI) package
whatever the fate of bsddb in Python stardard library be. So bsddb is a
pretty safe bet, even if you need to install it separately.

Compared to sqlite, you don't need to know SQL, you can finetuning (for
example, using ACI instead of ACID, deciding store by store), and you
can do replication and distributed transactions (useful, for example, if
your storage is bigger than a single machine capacity, like my case). If
you combine Berkeley DB with Durus, for example, all of this is
abstracted and you simply use "regular" python objects.

If you use bsddb, please consider to subscribe to pybsddb mailing list.
It has pretty low traffic and you can guide bsddb evolution (for
example, prioritize Berkeley DB binding additions).

- --
Jesus Cea Avion _/_/  _/_/_/_/_/_/
[EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBSL/hRZlgi5GaxT1NAQIeLgP/XPj32oLFS54QiHjTKrVKf4Bqc/JqFeJl
rasN/RM4hiqv3naueB90jPn2eMai3exCQXD85ew7YeMdWluNPEX/crBbhfN7n5M8
qP/GLWCqqDKWhPyvlInghQPoJUyv55TrPLsbUslCNyLAGFb79ETHs8MeaXn7Kx9o
+uAc01ifsoA=
=Or2m
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[skip]

>> Related but tangential question that we were discussing on the
>> pygr[0] mailing list -- what is the "official" word on a scalable
>> object store in Python?  We've been using bsddb, but is there an
>> alternative?  And what if bsddb is removed?

Brett> Beyond shelve there are no official plans to add a specific
Brett> object store.

Unless something has changed while I wasn't looking, shelve requires a
concrete module under the covers: bsddb, gdbm, ndbm, dumbdbm.  It's just a
thin layer over one of them that makes it appear as if you can have keys
which aren't strings.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[Brett Cannon]

On Wed, Sep 3, 2008 at 7:56 PM, C. Titus Brown <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 03, 2008 at 04:41:32PM -0700, Raymond Hettinger wrote:
> -> I think this should be deferred to Py3.1.
> ->
> -> This decision was not widely discussed and
> -> I think it likely that some users will
> -> be surprised and dismayed.  The release
> -> candidate seems to be the wrong time to
> -> yank this out (in part because of the surprise
> -> factor) and in part because I think the change
> -> silently affects shelve performance so that the
> -> impact may be significantly negative but not
> -> readily apparent.
>
> Related but tangential question that we were discussing on the pygr[0]
> mailing list -- what is the "official" word on a scalable object store
> in Python?  We've been using bsddb, but is there an alternative?  And
> what if bsddb is removed?
>

Beyond shelve there are no official plans to add a specific object store.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

On Wed, Sep 03, 2008 at 04:41:32PM -0700, Raymond Hettinger wrote:
-> I think this should be deferred to Py3.1. 
-> 
-> This decision was not widely discussed and 
-> I think it likely that some users will
-> be surprised and dismayed.  The release
-> candidate seems to be the wrong time to
-> yank this out (in part because of the surprise
-> factor) and in part because I think the change
-> silently affects shelve performance so that the
-> impact may be significantly negative but not
-> readily apparent.

Related but tangential question that we were discussing on the pygr[0]
mailing list -- what is the "official" word on a scalable object store
in Python?  We've been using bsddb, but is there an alternative?  And
what if bsddb is removed?

It would be very nice to have a moderately scalable (thousands to
millions, if not billions) cross-platform object store backend
distributed with Python.

sqlite could be one choice, but I haven't used it much yet, so I don't
know.

thanks,
--titus

[0] Python graph database for bioinformatics, 

http://code.google.com/p/pygr
-- 
C. Titus Brown, [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com