Re: [Python-Dev] Not releasing rc1 tonight

[Mark Hammond]

Barry writes:

> In addition, Mark reported in IRC that there are some regressions in
> the logging module.

3772 logging module fails with non-ascii data

Which according to the IRC discussion doesn't apply to py3k.  The fix for
2.6 is quite trivial...

Cheers,

Mark

___
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] [Python-3000] Not releasing rc1 tonight

[skip]

Barry> In addition, Mark reported in IRC that there are some regressions
Barry> in the logging module.

Vinay apparently checked in some changes to the logging module with no
review.  In the absence of obvious bug fixes there that should probably be
reverted.

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)

[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] [issue3769] Deprecate bsddb for removal in 3.0

[skip]

Michele> I do not use bsddb directly, but I use shelve which on Linux
Michele> usually takes advantage of bsddb. Does removing bsddb mean that
Michele> I will not be able to read shelve files written with Python 2.5
Michele> with Python 3.0? That would be quite disturbing to me.

Correctamundo.

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] [Python-3000] Not releasing rc1 tonight

[Facundo Batista]

2008/9/4 Raymond Hettinger <[EMAIL PROTECTED]>:

> Can I go ahead with some bug fixes and doc improvements
> or should I wait until after Friday?

Doc improvements: go ahead.

Bug fixes: the patchs should be revised by other developer.

(I'll be hanging around in #python-dev today and tomorrow, btw, ping
me if I can help you)

-- 
. Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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] C API for gc.enable() and gc.disable()

[Amaury Forgeot d'Arc]

Hello,

Andrey Zhmoginov wrote:
> I don't know if the following question is relevant, but it seems that many
> people here are familiar with Python cyclic garbage collector.
> I see Python [v2.5.2 (r252:60911, Jul 31 2008, 17:28:52)] crashing with
> Segment fault when I extend Python with a very simple module. This behavior
> is observed when I create a thousand of lists (it does not crash with
> 10-100) in the module with the garbage collector turned on. When I turn it
> off - everything is perfect. I suspect that it is my module, but if it is a
> Python bug ( _GC_Malloc? memory leak somewhere?), it may be worth reporting.
>
> The gdb "where" reply is the following:
>
>   #0  0x080d8de9 in PyErr_Occurred ()
>   #1  0x080f508f in _PyObject_GC_Malloc ()
>   #2  0x080f5155 in _PyObject_GC_New ()
>   #3  0x08079c98 in PyList_New ()
>   #4  0xb7f53519 in draw_d_simple () from ./rt/rt_core.so
>   #5  0xb7cf7833 in ffi_call_SYSV () from
> /usr/lib/python2.5/lib-dynload/_ctypes.so
>   #6  0xb7cf766a in ffi_call () from
> /usr/lib/python2.5/lib-dynload/_ctypes.so
>   #7  0xb7cf2534 in _CallProc () from
> /usr/lib/python2.5/lib-dynload/_ctypes.so
>   #8  0xb7cec02a in ?? () from /usr/lib/python2.5/lib-dynload/_ctypes.so
>   #9  0x0805cb97 in PyObject_Call ()
>   #10 0x080c7aa7 in PyEval_EvalFrameEx ()
>   #11 0x080c96e5 in PyEval_EvalFrameEx ()
>   #12 0x080cb1f7 in PyEval_EvalCodeEx ()
>   #13 0x080cb347 in PyEval_EvalCode ()
>   #14 0x080ea818 in PyRun_FileExFlags ()
>   #15 0x080eaab9 in PyRun_SimpleFileExFlags ()
>   #16 0x08059335 in Py_Main ()
>   #17 0x080587f2 in main ()
>
> The crashing python code is:
>
>   from ctypes import *
>   import gc
>   core = CDLL( "./tst.so" )
>   core.a.argtypes = []
>   core.a.restype = py_object
>   #gc.disable()
>   core.a()
>   #gc.enable()
>
> And tst.cpp is:
>
>   #include 
>   extern "C" { PyObject *a(); }
>   PyObject *a()
>   {
>   int n = 1000;
>   PyObject *item;
>   for ( int i = 0; i < n; i++ ) item = PyList_New( 0 );  // Crashes
> here (somewhere in between).
>   return item;
>   }
>
> tst.cpp is compiled with:
>
>   g++ -shared -Wl,-soname,tst.tmp.so -o tst.so tst.o
>   g++ -I /usr/include/python2.5 -Wall -fPIC -o tst.o -c tst.cpp

This has nothing to do with the garbage collection, but with the GIL
(the famous Global Interpreter Lock http://docs.python.org/api/threads.html )

When ctypes calls a CDLL function, it releases the GIL (to let
eventual other threads run)
Your example crashes because it calls python API functions when the
GIL is not held,
and is so invalid.

There are two solutions:
- re-acquire the GIL in your C functions with PyGILState_Ensure() & co
- use ctypes.PyDLL( "./tst.so" ), which does not release the GIL.

Hope this helps,

-- 
Amaury Forgeot d'Arc
___
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] Not releasing rc1 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 4, 2008, at 12:14 AM, Raymond Hettinger wrote:


[Barry]

I'm not going to release rc1 tonight.


Can I go ahead with some bug fixes and doc improvements
or should I wait until after Friday?


Doc fixes are fine.  Please have bug fix patches reviewed by another  
python-dev member.  Bonus points for any bug fix that closes a release  
blocker! :)


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL/cL3EjvBPtnXfVAQKnmgQAlx89LWeq0hEmTRvTGy/DHIYioARqAisG
wJAnZPqinbGI6pkyn0kiwgDOvNzstnFQSZsEFiAFU+iF+nbgkm8agcTf+eLXqCFK
y+o0xXTi7fLXKuaGioY54kz3BcwQH17Ul3X6vRxBdCWYesAe3rIXprnNgt/Euuyy
P5sZLKwfTls=
=b3n4
-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] Not releasing rc1 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 4, 2008, at 3:28 AM, Mark Hammond wrote:


Barry writes:


In addition, Mark reported in IRC that there are some regressions in
the logging module.


3772 logging module fails with non-ascii data

Which according to the IRC discussion doesn't apply to py3k.  The  
fix for

2.6 is quite trivial...


Thanks.  Looks like Vinay committed this.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL/cdHEjvBPtnXfVAQIb7gP9G2o8eSnWWfEmlanwoqiHGxgqUjQtx8Xz
es/Sjclk5KZ2X4I/jITJcOxGDfTT3h7FX9tDQiUaIzZAVB66qyzWc3957bUwqeqS
9HNqfB4OoIa1Ds2+lukXpEPci6eddl2xVFEkejgsfdyS4q2/K1/R6URTPCXnPNiH
zoiXNaEcBcM=
=Zk4M
-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] [Python-3000] Not releasing rc1 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 4, 2008, at 7:08 AM, [EMAIL PROTECTED] wrote:



   Barry> In addition, Mark reported in IRC that there are some  
regressions

   Barry> in the logging module.

Vinay apparently checked in some changes to the logging module with no
review.  In the absence of obvious bug fixes there that should  
probably be

reverted.


Or did he commit Mark's patch from bug 3772?  If so, that would count  
as a reviewed patch.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL/cpnEjvBPtnXfVAQIkSwQApjBbIGgyV3X1oBhBLtRjTZrVDgFXPfRH
XyXtVd1r75PT+24UuqPHWNC9l+/sKnUaYqH3kJbHG2duMyr/duG7j6EIJLzOz+QC
SKwqtQr+WDBR0vpH3Q0wrUzQNXhtDyCjWx84IatRbKRVDUfbDlFQy/jj+SLvRBBR
WGJTAFP1x5g=
=mebg
-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] [Python-3000] Not releasing rc1 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 4, 2008, at 7:31 AM, Facundo Batista wrote:


(I'll be hanging around in #python-dev today and tomorrow, btw, ping
me if I can help you)


Me too, though I'm a bit busy at work.  Ping my nick 'barry' if you  
need any RM-level decision.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL/c2XEjvBPtnXfVAQJ4EQP/SecaG0VRtsezedDRpX+zwmVo6W0n+9EP
rmKH5CWMSTWh53rXySCmE8IS2rrdhoyCZNSy0aERMTGz5JuEh/sw+O5EaxJQMFST
DdYx0aLRVwb62JaQHr7W7YyVWBG5+CQa3BehASFiwsw0dsAp0BpkwW1nIhybkLcW
hXNRzB2gwXI=
=9Mgt
-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)

[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] [issue3769] Deprecate bsddb for removal in 3.0

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michele Simionato wrote:
> I do not use bsddb directly, but I use shelve which on Linux usually
> takes advantage of bsddb. Does removing bsddb mean that
> I will not be able to read shelve files written with Python 2.5
> with Python 3.0? That would be quite disturbing to me.

Seems so.

If bsddb is actually unavailable in Python 3.0, you would need to
download/install it from PYPI. I'm committed to keep bsddb alive, in a
way or another :).

I'm thinking that if bsddb is discarded in Python 3.0, shelve probably
drop it also, so installing bsddb externally will not "magically" make
it available to 3.0 shelve. I can't comment about the python-dev plans here.

PS: Remember that if you are installing bsddb as a separate package, its
name will be "bsddb3", not "bsddb".


- --
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/jJZlgi5GaxT1NAQIzJAP8CiIxpoz553NDr+/1GkAfzs3W6fu1uBuo
XsCmbqkiOMe9fPOBNZnlfoBnGz4C4nlOlOzQV3RexRXBiWKOqUUg4DlJOJtrAMUO
ZNtcz9JyvjzmVNZMezgCsfjkEhzNABbCe9mXHQVCR5zlNZVUKpTW7A06/1eX/gMv
ECJqQta662o=
=6XBZ
-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] [issue3769] Deprecate bsddb for removal in 3.0

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brett Cannon wrote:
>> Also, the reason for removal may yet disappear
>> if jcrea steps in an continues to make updates.
> 
> OK, but none of his changes have received a code review, so if we are
> going to go down the whole "disciplined" route about it being an rc
> then we should back out all of Jesus' changes for both 2.6 and 3.0,
> which puts us back to the same instability issues.

I was wondering if somebody could write a "TO DO" list of things need to
keep bsddb in the stdlib. Then I could work to trying to comply :).

Yes, we are all very busy guys, but still...

- --
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/kPZlgi5GaxT1NAQLu4AP/VSHPYOCQgQYFJsdi2MWXBpyY7TyC5XgT
Ks2uilXru/hsKQcegn8G6z/53Bt0Uu+oXZSQaZ51V8VnwDXEqaZ+GnKK+S2ky9m0
yomgMlKIZZJsOVd6X4HbLtrVYVKX8wQ224X/yCkw27OLzLIE9IDbUzEjC3+/A7mD
9IJu3B6IaLA=
=ZA8p
-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] [Python-3000] Not releasing rc1 tonight

[skip]

Barry> Or did he commit Mark's patch from bug 3772?  If so, that would
Barry> count as a reviewed patch.

The checkin message says issue 3726:

Author: vinay.sajip
Date: Wed Sep  3 11:20:05 2008
New Revision: 66180

Log:
Issue #3726: Allowed spaces in separators in logging configuration files.

Modified:
   python/trunk/Lib/logging/config.py
   python/trunk/Lib/test/test_logging.py
   python/trunk/Misc/NEWS

I noticed because someone else (Brett?) questioned the apparent lack of
review.

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] [issue3769] Deprecate bsddb for removal in 3.0

[Nick Coghlan]

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.

I don't use Python for database work myself, but something I am somewhat
disappointed to lose is the presence of a moderately complicated package
within the Python distribution itself which is making use of the various
2-to-3 migration tools to support both Python 2.x and 3.x with a single
mixed Python-and-C code base (along with automatic conversion via 2to3).

While that will still be visible to some degree due to the presence of
the 2.x version of the bsddb code in Python 2.6, I don't think it will
be quite the same as it would have been with the 3.x version also being
readily available as part of the standard 3.0 install.

Regardless, given that the removal of bsddb from the 3.0 branch is now a
done deal in svn, I suggest that all we can do is monitor how much
feedback we get indicating that the need to download bsddb as a separate
install is a significant hindrance to Py3k migrations. If the feedback
indicates it is necessary, restoring the module for 3.1 certainly isn't
an impossibility, but in the meantime there *are* real benefits to
decoupling the maintenance cycles (those wanting to get the most out of
Jesus's ongoing work in exposing more of the bsddb API are probably
going to want to be using the external pybsddb releases anyway rather
than waiting however many months it ends up being until we get to 2.7/3.1).

There's also a bit of a second shot at this for bsddb supporters, in
that some of the "omnibus" Python distribution providers like
ActiveState and Enthought may choose to include pybsddb once they start
releasing bundles for Python 3.0.

As far as the corporate scenarios go: if a corporate environment is *so*
screwed up as to simultaneously permit a migration from Python 2.x to
3.0 of an internal project that relies on bsddb, while at the same time
banning those performing the migration from installing the 3.0
compatible version of pybsddb, then they have much bigger problems than
which modules and packages we are choosing to include in the standard
library. In my experience, restrictive corporate environments are far
more likely to just disallow migrations to 3.0 altogether (and in many
cases, the decision makers disallowing such migrations probably won't be
wrong - the case for migrating an existing internal app to 3.0 is far,
far weaker than that for using 3.0 for new development).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
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] HTTPS read-only SVN access is denied?

[techtonik]

On Thu, Sep 4, 2008 at 2:08 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>
>> And why not to setup HTTPS for anonymous read and authorized write
>> access? It is not that hard to do and will solve many problems with
>> proxies.
>
> Because it requires setting up a certificate.

Certificate is already set.

$ svn co https://svn.python.org/projects/trunk
Error validating server certificate for 'https://svn.python.org:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: svn.python.org
 - Valid: from Apr 10 00:00:00 2007 GMT until Apr  9 23:59:59 2010 GMT
 - Issuer: http://www.usertrust.com, The USERTRUST Network, Salt Lake
City, UT, US
 - Fingerprint: fc:67:c1:59:f5:57:71:29:f5:13:50:bc:c9:16:f1:74:da:1f:12:98
(R)eject, accept (t)emporarily or accept (p)ermanently? t
Authentication realm:  Subversion repository
Password for 'username':
Authentication realm:  Subversion repository
Username: svn: PROPFIND request failed on '/projects/trunk'
svn: PROPFIND of '/projects/trunk': authorization failed
(https://svn.python.org)

> You can use HTTP to do a read-only checkout.

Well, the main problem is that I can't. As I already said my machine
is behind a proxy that doesn't support required WebDAV extensions for
HTTP protocol - http://subversion.tigris.org/faq.html#proxy

-- 
--anatoly t.
___
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] HTTPS read-only SVN access is denied?

[techtonik]

On Thu, Sep 4, 2008 at 1:48 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>
>> I do not need the whole branch - only a small subset of files related
>> to distutils. I know that bazaar can't do partial checkouts - it can
>> only fetch the whole branch. What about mercurial?
>
> Mercurial can't do it either. But I don't think it matters a lot; unless your
> bandwidth is very low the full clone should be fast enough. Here it takes just
> 150s. for the trunk.

Thanks for support. However, fetching whole branch is not an option, because
Internet is expensive here - even 10Mb tarball costs 20 cents. To make matters
worse I would say that it is more than 0.04% of an average salary.

-- 
--anatoly t.
___
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)

[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

[Oleg Broytmann]

On Thu, Sep 04, 2008 at 03:23:22PM +0200, Jesus Cea 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).

   Let me raise the glove. Compared to bsddb:

-- SQLite is public domain; the licensing terms of Berkeley DB[1] are not
   friendly to commercial applications: "Our open source license ...
   permits use of Berkeley DB in open source projects or in applications
   that are not distributed to third parties." I am not sure if using of
   PyBSDDB in commercial applications is considered "using of Berkeley DB
   in open source projects";
-- SQLite has a pretty stable API and a pretty stable on-disk format; for
   bsddb one needs to do dump/reload on every major release;
-- SQLite implements a subset of SQL - a powerful query language;
-- SQLite is extensible - one can write his/her own functions and
   aggregates, e.g.; PySQLite allows to write these functions in Python;
   PySQLite also allows to write data conversion functions that converts
   between Python and SQL data types;
-- a program can attach a few databases at once thus distributing loads
   between a number of disks, including network mounts.

[1] 
http://www.oracle.com/technology/software/products/berkeley-db/htdocs/licensing.html

> If
> you combine Berkeley DB with Durus, for example, all of this is
> abstracted and you simply use "regular" python objects.

   Durus (and ZODB) has an index of all objects, the index is stored in
memory AFAIK - a real problem if one has millions of objects. Does bsddb
help to mitigate the problem?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] [Python-3000] Not releasing rc1 tonight

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 4, 2008, at 9:45 AM, [EMAIL PROTECTED] wrote:



   Barry> Or did he commit Mark's patch from bug 3772?  If so, that  
would

   Barry> count as a reviewed patch.

The checkin message says issue 3726:

   Author: vinay.sajip
   Date: Wed Sep  3 11:20:05 2008
   New Revision: 66180

   Log:
   Issue #3726: Allowed spaces in separators in logging  
configuration files.


   Modified:
  python/trunk/Lib/logging/config.py
  python/trunk/Lib/test/test_logging.py
  python/trunk/Misc/NEWS

I noticed because someone else (Brett?) questioned the apparent lack  
of

review.


Yep, that's a different issue.  Unless someone wants to vouch for the  
committed patch after the fact, could someone please revert the change  
and contact Vinay to get a proper fix reviewed?  I noticed that he  
says in the tracker issue that what was committed was modified from  
the posted patch.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSL/zMnEjvBPtnXfVAQJY3QP+LNXhx1YGuCHSw/D2n0yVBj1PLLUbgYnp
k/+zWWmvIRc8YSApV1YyYR4iXfqqYFoi1SH0eh7F1k9+2CZ51HHD0p6CZ0Eb1FQ2
405ocxT28R3UR/E0ozxFca3IuNhGPR2FI/BCfsLrdrA3UtHA4XvZMDvM3KxEMarl
9WdYgop/I8Y=
=b6Ry
-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)

[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] Deprecatebsddb for removal in 3.0)

[Raymond Hettinger]

[C. Titus Brown]

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.  


Not credible, not widely discussed, not tested in a beta ...
No alternative provided, no deprecation period before it disappears ...  
The usual deliberative process has been completely bypassed.



Raymond
___
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] HTTPS read-only SVN access is denied?

[Amaury Forgeot d'Arc]

Hello,

2008/9/4 techtonik <[EMAIL PROTECTED]>:
> On Thu, Sep 4, 2008 at 1:48 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>>
>>> I do not need the whole branch - only a small subset of files related
>>> to distutils. I know that bazaar can't do partial checkouts - it can
>>> only fetch the whole branch. What about mercurial?
>>
>> Mercurial can't do it either. But I don't think it matters a lot; unless your
>> bandwidth is very low the full clone should be fast enough. Here it takes 
>> just
>> 150s. for the trunk.
>
> Thanks for support. However, fetching whole branch is not an option, because
> Internet is expensive here - even 10Mb tarball costs 20 cents. To make matters
> worse I would say that it is more than 0.04% of an average salary.

Did you try to open your browser to (for example)
http://svn.python.org/projects/python/trunk/Lib/distutils/
and download the desired files from there?


-- 
Amaury Forgeot d'Arc
___
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] [issue3769] Deprecate bsddb for removal in 3.0

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick Coghlan wrote:
> While that will still be visible to some degree due to the presence of
> the 2.x version of the bsddb code in Python 2.6, I don't think it will
> be quite the same as it would have been with the 3.x version also being
> readily available as part of the standard 3.0 install.

Since 2.6 intention seems to mark this module as deprecated, I guess 2.x
bsddb presence in stock python will finish in 2.7. Moreover, I'm working
just now improving 2.x/3.x conversion code in pybsddb. I think this code
will be available in bsddb 4.7.4, and it will not be integrated in
Python 2.6 (that will include 4.7.3.minor releases, if we keep the
criteria of "only stability and security fixes in 2.6.x").

If the idea is to keep bsddb alive in 2.x, I don't see the point of not
keeping the 3.0 version, because the issues used to justify the removal
persist: I'm the only maintainer, little code review, buildbot issues, etc.

(I would like a comprehensive list, to be able to improve those
deficiencies).

In fact, if we keep bsddb in 2.x, the pressure to keep it in 3.x will be
higher.

> Regardless, given that the removal of bsddb from the 3.0 branch is now a
> done deal in svn, I suggest that all we can do is monitor how much

Any version control system can revert that with a single command :).

All I can say is that current bsddb code (in my personal repository)
passes all tests in current compiled python3.0 binary, called with the
"-bb" parameter flag (the "-bb" flag was something I learned yesterday).

> but in the meantime there *are* real benefits to
> decoupling the maintenance cycles (those wanting to get the most out of
> Jesus's ongoing work in exposing more of the bsddb API are probably
> going to want to be using the external pybsddb releases anyway rather
> than waiting however many months it ends up being until we get to 2.7/3.1).

The cycles are actually decoupled since I toke over the bsddb
maintenance (I've released a new version per month). So the release
cycles are not an issue.

The main issue here is 3.0 support, that I worked over the last couple
of months. It is done now. It couldn't be done faster because I was
learning 3.0 internals on-the-fly (there are NO docs about C module
migration; my experience there could be valuable) and 3.0 was a moving
target (still is). For example, when I left to summer holiday bsddb
worked flawless in Python 3.0b2. It failed in 3.0b3 because threading
renames done in python 3.0.

So, Python 3.0 is not waiting for bsddb to be ready, because it already
is (since yesterday). And future Python releases won't suffer because we
won't have any other major architectural reengineering of Python in a
long long time (I hope!).

That is, future Python releases would take whatever bsddb is available
at that time. No wait. No dependent release cycles. With my current
release schema of "a release per month", I can track python evolution
with little effort. For example, Python 2.5 to 2.6 was pretty painless,
even with the "PyBytes_*" ugliness.

> As far as the corporate scenarios go: if a corporate environment is *so*
> screwed up as to simultaneously permit a migration from Python 2.x to
> 3.0 of an internal project that relies on bsddb, while at the same time
> banning those performing the migration from installing the 3.0
> compatible version of pybsddb, then they have much bigger problems than
> which modules and packages we are choosing to include in the standard
> library.

Agreed. I was thinking about bsddb removal in 2.7.

- --
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

iQCVAwUBSMAEnplgi5GaxT1NAQIrKgP/YAp45HUSG8Q+M355LTVqlcLMLkycpooc
fflW0MlQ3zZV307VBUbGo9urkS6h1pYhYByivApylhVqj8D4x8OEmMZk0lX8cegG
LYSBzs/sBeyxWWva6r5D9/4DsgJe9ZHqaBLMpy6ipPNVtUbMS61VTNovb3wP+f72
EnSIf9k/glM=
=QxRo
-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 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)

[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] Durus memory

[Binger David]

I'm sorry this post is a bit off-topic, but I think I should correct  
this.


On Sep 4, 2008, at 11:54 AM, Oleg wrote:


Durus (and ZODB) has an index of all objects, the index is stored in
memory AFAIK - a real problem if one has millions of objects.



Durus now has an option to store the index in the data file in a form
that is usable directly from disk.  With this option, the in-memory
index is only for objects changed since the last pack.

Durus works fine with millions of objects, as long as you don't have
millions of rapidly-changing objects.

I haven't used the Berkeley DB storage for Durus, but I'm pretty
sure that the Durus/Python side of that would not use
any in-memory index.



___
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)

[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)

[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)

[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] SQLite (was: bsddb alternative)

[Oleg Broytmann]

On Thu, Sep 04, 2008 at 01:07:23PM -0400, Jeff Hall wrote:
> Doesn't SQLlite still have a 4gb cap?

   http://sqlite.org/limits.html

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Oleg Broytmann wrote:
> -- SQLite is public domain; the licensing terms of Berkeley DB[1] are not
>friendly to commercial applications: "Our open source license ...
>permits use of Berkeley DB in open source projects or in applications
>that are not distributed to third parties." I am not sure if using of
>PyBSDDB in commercial applications is considered "using of Berkeley DB
>in open source projects";

I can't comment on this. I'm not a lawyer.

> -- SQLite has a pretty stable API and a pretty stable on-disk format; for
>bsddb one needs to do dump/reload on every major release;

Not at all. The worst thing you would need to do is a "db_upgrade", an
in-place operation. Lately it is pretty harmless and fast (like
upgrading the log format, not the database file format).

A stable fileformat is useful for long term support, but an evolving
format allows improvements. Following your reasoning, Python should be
keep in 1.0 era, for compatibility sake.

> -- SQLite implements a subset of SQL - a powerful query language;

Yes, a declarative language completely unrelated to Python.

> -- SQLite is extensible - one can write his/her own functions and
>aggregates, e.g.; PySQLite allows to write these functions in Python;
>PySQLite also allows to write data conversion functions that converts
>between Python and SQL data types;

bsddb 4.7.4 (available next month) will allow to subclass DB/DBEnv, etc.
objects, so you can implement the logic you wish there. Until that, you
can do proxy/delegation (that is the way I'm doing 3.0 compatibility, BTW).

> -- a program can attach a few databases at once thus distributing loads
>between a number of disks, including network mounts.

That is an OS issue. Any program get the benefice.

The problem is not disk capacity. Any modern machine can scale disk
without bound via iSCSI, for example (god bless ZFS!). The issue is
replication for redundancy, load sharing and high availability. These
things are available in bsddb 4.7.3 (that is, in Python 2.6).

How do you scale traffic demand in SQLite?. I can keep adding machines
to solve read requests, without sharing any disk between them. I can
launch 64 bsddb processes in a single 64 CPU machine to manage
(read/write) a single shared database. I don't know if SQLite can do
that. Berkeley DB can.

>Durus (and ZODB) has an index of all objects, the index is stored in
> memory AFAIK - a real problem if one has millions of objects. Does bsddb
> help to mitigate the problem?

Latest Durus has not that issue, but you always can use another project
of mine:

Berkeley DB Backend Storage Engine for DURUS
http://www.jcea.es/programacion/durus-berkeleydbstorage.htm

This code (with some private enhancements for replication and
distributed transactions) manages a nearly 200 Terabytes Durus
repository without any sweat (~2^35 objects stored there).

In this particular instance, distributed transactions allows me to
partition data between several machines, with no sharing between them,
and replication allows redundancy and routing read requests to a less
loaded machine (the writes goes to the "master" machine, replication
from there is transparent).

SQLite is a good product. I just dislike "SQL fits all" model, as I
already said in another message. Using a SQL storage to save persistent
Python objects is ugly and SQL language is of no use there. You just
need "something" safe, scalable, configurable and being able to give you
opaque objects when an OID (Object ID) is presented. Compare a terabyte
Python "shelve" object, ease of use, transparence, etc., with keeping
the objects in a SQL database server.

Just my opinion, of course.

- --
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

iQCVAwUBSMAdiJlgi5GaxT1NAQJxkwP/emM8dDKbnhxme76Nm3bXhA89NwCgQNQi
ojO0wkVZZ8ypUBNKwGM8PyDzGYoWGnh7VgylGb2bsPt67bCxrHjcXBNPaYrMN/fw
AETLlJUrhu9J17jPWKA+JU1FmC9oX34Ki580qMXI9nR51LVLU/1H6nM+KgA0slnn
uG3xvm5chfk=
=M46E
-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

[Oleg Broytmann]

On Thu, Sep 04, 2008 at 07:40:28PM +0200, Jesus Cea wrote:
> A stable fileformat is useful for long term support, but an evolving
> format allows improvements.

   Once I upgraded Python on a Windows computer... I think it was 2.2 to
2.3 upgrade - and all my bsddb databases stopped working. I cannot call
this "improvement". I didn't have db_upgarde on that computer (or I didn't
know about it). Does PyBSDDB have db_upgrade in the distribution? Does
Python distribution have db_upgrade?

> Following your reasoning, Python should be
> keep in 1.0 era, for compatibility sake.

   Python? No. But persistent data structures? Yes! How many different
pickle data formats there were since Python 1.0? What is the oldest
pickle format modern Python can read? (Just using pickle as an example.)

> > -- SQLite implements a subset of SQL - a powerful query language;
> 
> Yes, a declarative language completely unrelated to Python.

   Sometimes being unrelated to Python is advantage. Written in C,
optimized for its tasks, the implementation of the query language
certainly can outperform Python.

> Using a SQL storage to save persistent
> Python objects is ugly

   No more ugly than any other storage. A matter of taste, I think.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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)

[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] [issue3769] Deprecate bsddb for removal in 3.0

[Brett Cannon]

On Thu, Sep 4, 2008 at 6:35 AM, Jesus Cea <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brett Cannon wrote:
>>> Also, the reason for removal may yet disappear
>>> if jcrea steps in an continues to make updates.
>>
>> OK, but none of his changes have received a code review, so if we are
>> going to go down the whole "disciplined" route about it being an rc
>> then we should back out all of Jesus' changes for both 2.6 and 3.0,
>> which puts us back to the same instability issues.
>
> I was wondering if somebody could write a "TO DO" list of things need to
> keep bsddb in the stdlib. Then I could work to trying to comply :).
>

[Guido already made his public statement in support of removing
pybsddb from 3.0, so this is more just for general benefit of Jesus to
know why I think this all happened; I don't view these as points to
argue over]

* Follow python-dev practices. The biggest example of this was
checking in code during an rc release cycle without code review. That
was stated on python-committers which you should be subscribed to and
paying attention to.

* Maintain bsddb in Python and cut external releases separately. That
would help make bsddb feel more like a stdlib thing instead of
something that just gets dumped in our lap when we get close to a
release.

* Stay on top of the buildbots. test_bsddb has been such a consistent
failure on the buildbots that it has left a very sour taste in the
mouths of many core developers over the years (and I mean years;
Pythonlabs folks are saying how much they remember the bindings being
unstable back in the day).

* Convince some folks that Sleepycat is actually doing a decent job
now. As I believe Fred mentioned and you pointed out with the 4.7.0
release, Sleepycat does not always do solid releases.

* Get another committer to help you maintain the code. When Gregory
stepped down from maintaining bsddb, the code languished with its
traditionally flaky tests until you stepped forward. That suggests to
me that no one really wants to maintain that code but you. Sure,
people want the code to be there, but "want" does not translate to
man-hours to keep the code in good shape.

> Yes, we are all very busy guys, but still...

Yes, we are all busy, including you. And that is what makes bsddb the
largest maintenance headache in the stdlib; you are a single point of
failure for a chunk of code that has garnered a reputation over the
years as being flaky. And I realize the reputation is not your fault,
Jesus. And I understand people wanting bsddb to be there. But from a
core developer's POV, I want to keep the stdlib to code that at least
a couple of core developers would be willing to work on if a bug was
reported in the issue tracker; bsddb has not shown to be such code
base.

And just so people know, I hear the argument about keeping bsddb in
3.0 and then ripping it out in 3.1, but I'm cynical when it comes to
python-dev, so I see that as a potential ploy to keep the code in and
then have a year or so to argue about this all over again with no
change on either side.

Another thing to keep in mind with the whole shelve/dbm.any argument
is that for 3.1 there is nothing saying we can't change shelve and the
dbm package to allow 3rd-party code to register with the dbm package
such that bsddb can be used as needed behind the scenes.

-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

Re: [Python-Dev] bsddb

[Curt Hagenlocher]

On Thu, Sep 4, 2008 at 7:33 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
>
> SQLite is public domain; the licensing terms of Berkeley DB[1] are not
> friendly to commercial applications: "Our open source license ...
> permits use of Berkeley DB in open source projects or in applications
> that are not distributed to third parties." I am not sure if using of
> PyBSDDB in commercial applications is considered "using of Berkeley DB
> in open source projects";

Wow, I hadn't realized that it was such a restrictive license.  When I
see "Berkeley" I think "BSD license".

--
Curt Hagenlocher
[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)

[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

[Python-Dev] 3rd-party dbms

[Oleg Broytmann]

Brett Cannon <[EMAIL PROTECTED]> wrote:
> for 3.1 there is nothing saying we can't change shelve and the
> dbm package to allow 3rd-party code to register with the dbm package
> such that bsddb can be used as needed behind the scenes.

   Many years ago I wrote toy hashes based on ZODB and MetaKit. Registering
them with anydbm was easy:

import anydbm
anydbm._names.insert(len(anydbm._names)-1, ['ZODBhash', 'MKhash'])
# Insert before dumbdbm

   More complex part was to make whichdb to recognize those hashes. I just
monkey-patched whichdb. If I were doing this now I'd do something similar
to atexit module - every hash module will register its own test function,
and whichdb will call them in turn until it finds which db it is.

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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

[Jesus Cea]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Oleg Broytmann wrote:
>Once I upgraded Python on a Windows computer... I think it was 2.2 to
> 2.3 upgrade - and all my bsddb databases stopped working. I cannot call
> this "improvement". I didn't have db_upgarde on that computer (or I didn't
> know about it). Does PyBSDDB have db_upgrade in the distribution? Does
> Python distribution have db_upgrade?

I can't comment about bsddb status before my maintenance era (since
March or so). But current release:

http://www.jcea.es/programacion/pybsddb_doc/db.html#upgrade

"""
[EMAIL PROTECTED] Modules]$ grep -i upgrade *
_bsddb.c:DB_upgrade(DBObject* self, PyObject* args)
_bsddb.c:if (!PyArg_ParseTuple(args,"s|i:upgrade", &filename, &flags))
_bsddb.c:err = self->db->upgrade(self->db, filename, flags);
_bsddb.c:MAKE_ENTRY(nupgrade);
_bsddb.c:{"upgrade", (PyCFunction)DB_upgrade,
METH_VARARGS},
_bsddb.c:ADD_INT(d, DB_UPGRADE);
_bsddb.c:ADD_INT(d, DB_LOCK_UPGRADE);
_bsddb.c:ADD_INT(d, DB_LOCK_UPGRADE_WRITE);
_bsddb.c:ADD_INT(d, DB_LOCK_UPGRADE);
"""

>> Following your reasoning, Python should be
>> keep in 1.0 era, for compatibility sake.
> 
>Python? No. But persistent data structures? Yes! How many different
> pickle data formats there were since Python 1.0? What is the oldest
> pickle format modern Python can read? (Just using pickle as an example.)

Modern bsddb can read relic bsddb data; just do a "db_upgrade".

>>> -- SQLite implements a subset of SQL - a powerful query language;
>> Yes, a declarative language completely unrelated to Python.
> 
>Sometimes being unrelated to Python is advantage.

No argument here. My brain just work that way :).

- --
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

iQCVAwUBSMAwLJlgi5GaxT1NAQIKzgP5AeHeGF52DtGs/KMssduQczPnoH5ndgME
/265foN/qp/GM4kgunoOTPGd9kREVmxgduVaY9yNvVkQNH0WW+t+y41CIcwL36lG
EWXb+9eeAkBm7C0fFLwYZnqDva9/n9Ax7SkXHl+SOerL9Eq6rXzFXyHcTfyZtu8i
uI4q4n7nHQA=
=upd8
-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] 3rd-party dbms

[Brett Cannon]

On Thu, Sep 4, 2008 at 11:59 AM, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
> Brett Cannon <[EMAIL PROTECTED]> wrote:
>> for 3.1 there is nothing saying we can't change shelve and the
>> dbm package to allow 3rd-party code to register with the dbm package
>> such that bsddb can be used as needed behind the scenes.
>
>   Many years ago I wrote toy hashes based on ZODB and MetaKit. Registering
> them with anydbm was easy:
>
> import anydbm
> anydbm._names.insert(len(anydbm._names)-1, ['ZODBhash', 'MKhash'])
># Insert before dumbdbm
>
>   More complex part was to make whichdb to recognize those hashes. I just
> monkey-patched whichdb. If I were doing this now I'd do something similar
> to atexit module - every hash module will register its own test function,
> and whichdb will call them in turn until it finds which db it is.
>

That's what I figured could happen. And give dbm.any a public API to
register with it instead of setting a private attribute.

-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

Re: [Python-Dev] HTTPS read-only SVN access is denied?

[techtonik]

On Thu, Sep 4, 2008 at 5:06 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> >>
>
> Did you try to open your browser to (for example)
> http://svn.python.org/projects/python/trunk/Lib/distutils/
> and download the desired files from there?

Yes, but it's a waste of time. It is SVN that should be fixed unless
somebody name a good reason to disallow r/o anonymous access through
HTTPS .

-- 
--anatoly t.
___
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] patch for Cookie.py to add support for HttpOnly

[Matt Chisholm]

Eighteen months ago, Arvin Schnell contributed a really
straightforward three-line patch to Cookie.py adding support for the
HttpOnly flag on cookies:

http://bugs.python.org/issue1638033

In the last eighteen months, HttpOnly has become a de-facto extension
to the cookie standard. It is now supported by IE 7, Firefox 3, and
Opera 9.5 (and there's a bug open against WebKit to support it):

http://www.owasp.org/index.php/HTTPOnly

Ruby, Perl, and PHP all support creating HttpOnly cookies now too. 

This article explains why HttpOnly is a good way to make cross-site
scripting (XSS) attacks significantly more difficult:

http://www.codinghorror.com/blog/archives/001167.htmllop

Unfortunately this patch appears to have been ignored for the last
year.

The last thing I want is a delay in the release of 2.6/3.0, but
Antoine Pitrou posted on the bug that it will have to wait for Python
2.7/3.1, because it is a feature request.  If I'm not mistaken, that
means no support for HttpOnly until sometime in 2010.

Do we really have to wait two more years to apply a three-line patch
which will bring Python in line with the industry state of the art and
improve security for Python web applications?  Is there a way that
this could go in to 2.6.1/3.0.1? 

-matt


___
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] Not releasing rc1 tonight

[Brett Cannon]

On Wed, Sep 3, 2008 at 8:41 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm not going to release rc1 tonight.  There are too many open release
> blockers that I don't want to defer, and I'd like the buildbots to churn
> through the bsddb removal on all platforms.  Let me first thank Benjamin,
> Brett, Mark and Antoine for their help on IRC tonight.
>
> Here are the issues I'm not comfortable with deferring:
>
>  3640 test_cpickle crash on AMD64 Windows build
> 874900 threading module can deadlock after fork
>  3574 compile() cannot decode Latin-1 source encodings
>  3657 pickle can pickle the wrong function
>  3187 os.listdir can return byte strings
>  3660 reference leaks in 3.0
>  3594 PyTokenizer_FindEncoding() never succeeds
>  3629 Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2
>

I just added issue 3776 to this list: deprecate bsddb/dbhash in 2.6
for removal in 3.0 . There is a patch attached to the issue to be
reviewed.

-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

Re: [Python-Dev] patch for Cookie.py to add support for HttpOnly

[Benjamin Peterson]

On Thu, Sep 4, 2008 at 2:31 PM, Matt Chisholm <[EMAIL PROTECTED]> wrote:
> Eighteen months ago, Arvin Schnell contributed a really
> straightforward three-line patch to Cookie.py adding support for the
> HttpOnly flag on cookies:
>
> http://bugs.python.org/issue1638033
>
> In the last eighteen months, HttpOnly has become a de-facto extension
> to the cookie standard. It is now supported by IE 7, Firefox 3, and
> Opera 9.5 (and there's a bug open against WebKit to support it):
>
> http://www.owasp.org/index.php/HTTPOnly
>
> Ruby, Perl, and PHP all support creating HttpOnly cookies now too.
>
> This article explains why HttpOnly is a good way to make cross-site
> scripting (XSS) attacks significantly more difficult:
>
> http://www.codinghorror.com/blog/archives/001167.htmllop
>
> Unfortunately this patch appears to have been ignored for the last
> year.
>
> The last thing I want is a delay in the release of 2.6/3.0, but
> Antoine Pitrou posted on the bug that it will have to wait for Python
> 2.7/3.1, because it is a feature request.  If I'm not mistaken, that
> means no support for HttpOnly until sometime in 2010.

I think we will try to shorten the release cycle for 2.7/3.1 so that
it is closer to a year.

>
> Do we really have to wait two more years to apply a three-line patch
> which will bring Python in line with the industry state of the art and
> improve security for Python web applications?  Is there a way that
> this could go in to 2.6.1/3.0.1?

Excepting it becoming a security issue, a BDFL or release manager
pronouncement, or the Spanish Inquisition, no, I'm afraid not.
>
> -matt
>
>
> ___
> 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/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] 'warnings' module changes still breaking Twisted, still looking for a fix

[glyph]

With the 2.6 final release impending, the Twisted community buildbot is 
still red, , but there only seems to be one real 
issue: the warn_explicit change.  This seems like it could be a pretty 
minor bit of maintenance to clear up on our end, if Python provided the 
appropriate hook.


The current solution we have in mind for this problem is to build our 
own warnings module , but that is obviously 
inelegant.  While we do want to experiment with our own features for 
deprecation, users of Twisted will (rightfully) expect our "assertWarns" 
to continue covering warnings produced by the Python 2.6 warnings 
system.


The proposed solution to this problem seems to have been 
"warnings.catch_warnings()" , but it 
is insufficient for testing, since subsequent calls to 
"catch_warnings()" will not catch warnings suppressed by duplication 
suppression; without even getting into multiple tests testing the same 
code path, this breaks features like our 'trial' tool's "--until- 
failure" option, which runs a fixed group of tests repeatedly in an 
attempt to flush out buggy tests which have race conditions that cause 
them to fail intermittently.


We thought we'd filed a ticket for this before, but searching around in 
the issue tracker hasn't come up with anything.  JP Calderone has filed 
a new ticket for this problem:  .


Any chance this could be made into a release blocker?  If this one issue 
were fixed, Python 2.6 would be the smallest disruption to Twisted since 
Python 2.0 :-).

___
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] 'warnings' module changes still breaking Twisted, still looking for a fix

[Benjamin Peterson]

On Thu, Sep 4, 2008 at 5:11 PM,  <[EMAIL PROTECTED]> wrote:
>
> With the 2.6 final release impending, the Twisted community buildbot is
> still red, , but there only seems to be one real issue:
> the warn_explicit change.  This seems like it could be a pretty minor bit of
> maintenance to clear up on our end, if Python provided the appropriate hook.
>
> The current solution we have in mind for this problem is to build our own
> warnings module , but that is obviously inelegant.
>  While we do want to experiment with our own features for deprecation, users
> of Twisted will (rightfully) expect our "assertWarns" to continue covering
> warnings produced by the Python 2.6 warnings system.
>
> The proposed solution to this problem seems to have been
> "warnings.catch_warnings()" , but it is
> insufficient for testing, since subsequent calls to "catch_warnings()" will
> not catch warnings suppressed by duplication suppression; without even
> getting into multiple tests testing the same code path, this breaks features
> like our 'trial' tool's "--until- failure" option, which runs a fixed group
> of tests repeatedly in an attempt to flush out buggy tests which have race
> conditions that cause them to fail intermittently.

That's why catch_warning keeps track of the warnings filter too, so
you can call warnings.simplefilter("always") within the context
manager and the filter state will be restored.

>
> We thought we'd filed a ticket for this before, but searching around in the
> issue tracker hasn't come up with anything.  JP Calderone has filed a new
> ticket for this problem:  .
>
> Any chance this could be made into a release blocker?  If this one issue
> were fixed, Python 2.6 would be the smallest disruption to Twisted since
> Python 2.0 :-).
> ___
> 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/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
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] 'warnings' module changes still breaking Twisted, still looking for a fix

[Brett Cannon]

On Thu, Sep 4, 2008 at 3:11 PM,  <[EMAIL PROTECTED]> wrote:
>
> With the 2.6 final release impending, the Twisted community buildbot is
> still red, , but there only seems to be one real issue:
> the warn_explicit change.  This seems like it could be a pretty minor bit of
> maintenance to clear up on our end, if Python provided the appropriate hook.
>
> The current solution we have in mind for this problem is to build our own
> warnings module , but that is obviously inelegant.

And possibly unnecessary if you just want the old pure Python
implementation for testing. It is not hard to force an import of
warnings to use the pure Python version and totally ignore the C
implementation. See test_warnings on how to pull that off. Then you
can do your hack of overriding warn_explicit().

>  While we do want to experiment with our own features for deprecation, users
> of Twisted will (rightfully) expect our "assertWarns" to continue covering
> warnings produced by the Python 2.6 warnings system.
>
> The proposed solution to this problem seems to have been
> "warnings.catch_warnings()" , but it is
> insufficient for testing, since subsequent calls to "catch_warnings()" will
> not catch warnings suppressed by duplication suppression; without even
> getting into multiple tests testing the same code path, this breaks features
> like our 'trial' tool's "--until- failure" option, which runs a fixed group
> of tests repeatedly in an attempt to flush out buggy tests which have race
> conditions that cause them to fail intermittently.
>
> We thought we'd filed a ticket for this before, but searching around in the
> issue tracker hasn't come up with anything.  JP Calderone has filed a new
> ticket for this problem:  .

I am going to discuss technicalities on the issue.

-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

Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix

[glyph]

On 10:18 pm, [EMAIL PROTECTED] wrote:

That's why catch_warning keeps track of the warnings filter too, so
you can call warnings.simplefilter("always") within the context
manager and the filter state will be restored.


Thanks for the pointer - this is interesting.  I misunderstood the way 
the warnings filter worked.  It looks like this combination of features 
may in fact be all we need.  It would be nice if application code could 
otherwise "officially" keep track of the warnings filter (my 
understanding is that 'filters', despite the public-looking name, is 
private, since it is absent from the documentation?) but that doesn't 
sound like a release blocker.

___
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] 'warnings' module changes still breaking Twisted, still looking for a fix

[glyph]

On 10:35 pm, [EMAIL PROTECTED] wrote:

It is not hard to force an import of
warnings to use the pure Python version and totally ignore the C
implementation. See test_warnings on how to pull that off. Then you
can do your hack of overriding warn_explicit().


Benjamin Peterson's recommendation sounds like the winner (since we need 
to do *something* different in 2.6 anyway).  Forcing the import leads to 
a bunch of import-ordering problems, since the testing tool itself wants 
to emit warnings, and self-test, and then it has to import the module 
_and_ set an attribute on the SUT module...


Thanks for the tip, though.
___
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] 'warnings' module changes still breaking Twisted, still looking for a fix

[Brett Cannon]

On Thu, Sep 4, 2008 at 3:39 PM,  <[EMAIL PROTECTED]> wrote:
> On 10:18 pm, [EMAIL PROTECTED] wrote:
>>
>> That's why catch_warning keeps track of the warnings filter too, so
>> you can call warnings.simplefilter("always") within the context
>> manager and the filter state will be restored.
>
> Thanks for the pointer - this is interesting.  I misunderstood the way the
> warnings filter worked.  It looks like this combination of features may in
> fact be all we need.  It would be nice if application code could otherwise
> "officially" keep track of the warnings filter (my understanding is that
> 'filters', despite the public-looking name, is private, since it is absent
> from the documentation?) but that doesn't sound like a release blocker.

If you are after an API to return an opaque object that represents the
filter and be able to use that opaque object to reset the filter at a
later point (along with a matching reset function), then create an
issue for 2.7/3.1 and assign it to me as I was thinking about doing
that myself and would love to get Twisted's input on it.

_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] Can/should built-in functions get __get__?

[Terry Reedy]

One of the nice features of 3.0 is that differences between classes 
defined in C and Python (other than speed) are mostly erased or hidden 
from the view of a Python programmer.


However, there are still sometimes surprising and quite visible 
differences between 'functions' written in C and Python.  Can these be 
better unified also?


In particular, built-in functions, in spite of of being labeled 
'builtin_function_or_method', are not usable as methods because they 
lack the __get__ method needed to bind function to instance.


[Q. Any reason to not shorten that to 'built-in function'?]

So, as a c.l.p poster discovered, within a class statement,

__hash__ = lambda x: id(x) # works, while the apparently cleaner
__hash__ = id # raises TypeError: id() takes exactly one argument (0 given)

[Irony: trivial lambda wrapping, lambda x: f(x) has been described here 
as useless and diseased, but is seems that casting 'built-in function' 
to 'function' is not so completely useless. ;-]


In this case, __hash__ = object.__hash__ is available, as is 
object.__repr__, but this is not true in general for C functions.


The difference between a C function and a C method wrapper is 
tantalizingly small:


>>> i = set(dir(id))
>>> h = set(dir(object.__hash__))
>>> i-h
{'__module__', '__self__'}
>>> h-i
{'__objclass__', '__get__'}

Similarly, for
>>> def f(): pass

>>> ff = set(dir(f))
>>> ff - i
{'__defaults__', '__annotations__', '__kwdefaults__', '__globals__', 
'__closure__', '__dict__', '__code__', '__get__'}


the only un-obvious difference is __get__,

So I cannot help but wonder: is this is essential? or could it be 
removed but has not yet?  Could the object wrapper for C functions get a 
__get__ method so they become methods when accessed via a class just 
like Python functions do?


Terry Jan Reedy

___
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] Can/should built-in functions get __get__?

[Christian Heimes]

Terry Reedy wrote:
One of the nice features of 3.0 is that differences between classes 
defined in C and Python (other than speed) are mostly erased or hidden 
from the view of a Python programmer.


However, there are still sometimes surprising and quite visible 
differences between 'functions' written in C and Python.  Can these be 
better unified also?


In particular, built-in functions, in spite of of being labeled 
'builtin_function_or_method', are not usable as methods because they 
lack the __get__ method needed to bind function to instance.


Python is far too late in the release cycle to introduce a drastic 
change. The issues has been discussed about half a year ago and we 
decided against changing PyCFunction.


But it was a good thing that you've raises your concern. I totally 
forgot about the new instancemethod type. My code is still in 
classobject.c but it's not exposed to Python level. IIRC the 
Pyrex/Cython guys are in need of such a feature.


Patch:

--- Python/bltinmodule.c(revision 66222)
+++ Python/bltinmodule.c(working copy)
@@ -2301,6 +2301,7 @@
SETBUILTIN("frozenset", &PyFrozenSet_Type);
SETBUILTIN("property",  &PyProperty_Type);
SETBUILTIN("int",   &PyLong_Type);
+   SETBUILTIN("instancemethod",&PyInstanceMethod_Type);
SETBUILTIN("list",  &PyList_Type);
SETBUILTIN("map",   &PyMap_Type);
SETBUILTIN("object",&PyBaseObject_Type);

Result:

$ ./python
Python 3.0b3+ (py3k:66222M, Sep  5 2008, 02:24:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class Example:
... id = instancemethod(id)
...
>>> example = Example()
>>> example.id() == id(example)
True

Christian

___
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] Not releasing rc1 tonight

[Brett Cannon]

On Wed, Sep 3, 2008 at 8:41 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm not going to release rc1 tonight.  There are too many open release
> blockers that I don't want to defer, and I'd like the buildbots to churn
> through the bsddb removal on all platforms.  Let me first thank Benjamin,
> Brett, Mark and Antoine for their help on IRC tonight.
>
> Here are the issues I'm not comfortable with deferring:
>
>  3640 test_cpickle crash on AMD64 Windows build
> 874900 threading module can deadlock after fork
>  3574 compile() cannot decode Latin-1 source encodings
>  3657 pickle can pickle the wrong function
>  3187 os.listdir can return byte strings
>  3660 reference leaks in 3.0
>  3594 PyTokenizer_FindEncoding() never succeeds
>  3629 Py30b3 won't compile a regex that compiles with 2.5.2 and 30b2
>

And because I can't stop causing trouble, I just uploaded a patch for
issue3781 which solidifies warnings.catch_warnings() and its API a
little bit more. Really simple patch.

-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

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] Can/should built-in functions get __get__?

[Terry Reedy]

Christian Heimes wrote:

Terry Reedy wrote:
One of the nice features of 3.0 is that differences between classes 
defined in C and Python (other than speed) are mostly erased or hidden 
from the view of a Python programmer.


However, there are still sometimes surprising and quite visible 
differences between 'functions' written in C and Python.  Can these be 
better unified also?


In particular, built-in functions, in spite of of being labeled 
'builtin_function_or_method', are not usable as methods because they 
lack the __get__ method needed to bind function to instance.


Python is far too late in the release cycle to introduce a drastic 
change.


Of course.  I should have been clear that I was asking for 3.1.

> The issues has been discussed about half a year ago and we

decided against changing PyCFunction.


I did't remember that.  Was it a permanent or provisional decision.

But it was a good thing that you've raises your concern. I totally 
forgot about the new instancemethod type. My code is still in 
classobject.c but it's not exposed to Python level. IIRC the 
Pyrex/Cython guys are in need of such a feature.


Patch:

--- Python/bltinmodule.c(revision 66222)
+++ Python/bltinmodule.c(working copy)
@@ -2301,6 +2301,7 @@
SETBUILTIN("frozenset", &PyFrozenSet_Type);
SETBUILTIN("property",  &PyProperty_Type);
SETBUILTIN("int",   &PyLong_Type);
+   SETBUILTIN("instancemethod",&PyInstanceMethod_Type);
SETBUILTIN("list",  &PyList_Type);
SETBUILTIN("map",   &PyMap_Type);
SETBUILTIN("object",&PyBaseObject_Type);

Result:

$ ./python
Python 3.0b3+ (py3k:66222M, Sep  5 2008, 02:24:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> class Example:
... id = instancemethod(id)
...
 >>> example = Example()
 >>> example.id() == id(example)
True


I consider that 2nd best but it will solve the problem once one is aware 
of it.  I am thinking of suggesting a new paragraph for the Built-in 
Functions sections warning of differences between built-in functions and 
function instances.


Terry

___
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