Re: [Python-Dev] bsddb tests disabled by default
On Fri, Sep 19, 2008 at 8:36 PM, Jesus Cea <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Brett Cannon wrote: >> Well, 'time' says the test takes 16.09 sec user and 16.09 sec system >> on my MacBook, but a total execution time of almost 8 *minutes*. That >> is too long to be on by default. > > Uh... That is very strange. Well, it has always been that way for me, so I always assumed test_bsddb3 was just a *really* long test. > A lot of the disk traffic generated by the testsuite is "syncronous". By > default, under unix, the testsuite should be stored in "/tmp", that is > usually a ramdisk or something similar. That is the case under Solaris 10. > > I don't know about MacOS. > Don't think it is: drwxrwxrwt 11 root wheel 374B 19 Sep 20:44 tmp/ > I'm executing the testsuite under linux, with a /tmp backed by a proper > persistent FS (ReiserFS3). This machine is fairly busy, so the testsuite > actual time should be better: > But you could have a faster CPU, more RAM, Reiser could easily be faster than HFS+, etc. There is no way any of these comparisons are going to work. OS X might just plain suck at running test_bsddb3. Only thing I can think of is that Berkeley DB 4.7 is a ton faster than 4.6 or I am running something differently than you: time ./python.exe Lib/test/regrtest.py -uall test_bsddb3 ~/Dev/python/2.x/pristine test_bsddb3 Berkeley DB 4.6.21: (September 27, 2007) Test path prefix: /var/folders/MN/MN-E3HgoFXSKDXb9le7FQTI/-Tmp-/z-test_bsddb3-527 test_bsddb3 still working, be patient... 1 test OK. [48048 refs] ./python.exe Lib/test/regrtest.py -uall test_bsddb3 15.81s user 15.54s system 6% cpu 8:41.56 total -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 tests disabled by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett Cannon wrote: > Well, 'time' says the test takes 16.09 sec user and 16.09 sec system > on my MacBook, but a total execution time of almost 8 *minutes*. That > is too long to be on by default. Uh... That is very strange. Under Solaris 10: """ [EMAIL PROTECTED] trunk]$ time python2.6 test.py -bv Found Berkeley DB 4.7 installation. include files in /usr/local/BerkeleyDB.4.7/include library files in /usr/local/BerkeleyDB.4.7/lib library name is libdb-4.7 running build running build_py running build_ext Running tests from /export/home/pybsddb/trunk/build - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berkeley DB 4.7.25: (May 15, 2008) bsddb.db.version(): (4, 7, 25) bsddb.db.__version__: 4.7.3pre9 bsddb.db.cvsid: $Id: _bsddb.c 620 2008-09-18 14:59:59Z jcea $ py module: /export/home/pybsddb/trunk/build/lib.solaris-2.10-i86pc-2.6/bsddb3/__init__.pyc extension module: /export/home/pybsddb/trunk/build/lib.solaris-2.10-i86pc-2.6/bsddb3/_pybsddb.so python version: 2.6rc2 (r26rc2:66504, Sep 18 2008, 15:51:56) [GCC 4.2.3] My pid: 17223 - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= . - -- Ran 321 tests in 13.510s OK real0m13.786s user0m8.544s sys 0m1.636s """ A lot of the disk traffic generated by the testsuite is "syncronous". By default, under unix, the testsuite should be stored in "/tmp", that is usually a ramdisk or something similar. That is the case under Solaris 10. I don't know about MacOS. I'm executing the testsuite under linux, with a /tmp backed by a proper persistent FS (ReiserFS3). This machine is fairly busy, so the testsuite actual time should be better: """ [EMAIL PROTECTED]:~/mnt/particion_1/python/pybsddb/trunk> time python test.py -bv Found Berkeley DB 4.3 installation. include files in /usr/include/db4 library files in /usr/lib library name is libdb-4.3 running build running build_py running build_ext Running tests from /home/jcea/mnt/particion_1/python/pybsddb/trunk/build - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sleepycat Software: Berkeley DB 4.3.27: (September 9, 2005) bsddb.db.version(): (4, 3, 27) bsddb.db.__version__: 4.7.3pre9 bsddb.db.cvsid: $Id: _bsddb.c 620 2008-09-18 14:59:59Z jcea $ py module: /home/jcea/mnt/particion_1/python/pybsddb/trunk/build/lib.linux-i686-2.5/bsddb3/__init__.pyc extension module: /home/jcea/mnt/particion_1/python/pybsddb/trunk/build/lib.linux-i686-2.5/bsddb3/_pybsddb.so python version: 2.5.2 (r252:60911, Mar 13 2008, 12:51:08) [GCC 4.0.2 20050901 (prerelease) (SUSE Linux)] My pid: 19105 - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - -- Ran 312 tests in 37.984s OK real0m38.718s user0m17.905s sys 0m3.252s """ - -- 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 iQCVAwUBSNRvtplgi5GaxT1NAQKf6QP+P1pYzY02dlgJCKoLLlSjlFwOKa+uWrjK pqbJJFKIf8RTbMWGIutYPr03pdI1T0Y3JadVfHDC/lAc/59BcbOtMhKYFlAFPlik ZEC9oW02zzve0+thwpmxMPeKA6CeLboYW+cGkoUhtGayffQObrrTh0Zi47BcTUL6 e46liag7/ZA= =TCJf -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] Code coverage
On Fri, Sep 19, 2008 at 11:57 AM, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Hello all! > > The code coverage site at http://coverage.livinglogic.de/ was broken for > the last few months. It's fixed again now and runs the test suite once > per day with > > regrtest.py -T -N -uurlfetch,largefile,network,decimal > Thanks, Walter! Hopefully once Benjamin's testing cleanup lands we work on improving our test coverage. -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] What this code should do?
On Fri, Sep 19, 2008 at 9:30 PM, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > On Fri, 19 Sep 2008 18:26:05 +0200, Amaury Forgeot d'Arc > <[EMAIL PROTECTED]> wrote: >> >> Hello Maciej, >> >> Maciej Fijalkowski wrote: >>> >>> Hello, >>> >>> I'm a little clueless about exact semantics of following snippets: >>> >>> http://paste.pocoo.org/show/85698/ >>> >>> is this fine? >>> or shall I fill the bug? >>> (the reason to ask is because a) django is relying on this b) pypy >>> implements it differently) >> >> Note that python 3.0 has a different behaviour; in the first sample, it >> prints: >> A ( ... >> B (, ... >> >> See the subtle differences between >> http://docs.python.org/dev/library/sys.html#sys.exc_info >> http://docs.python.org/dev/3.0/library/sys.html#sys.exc_info >> > > The second example changes its behavior, too. It gives back the NameError > from the exc_info call. I'm having a hard time reconciling this with the > Python 3.0 documentation. Can you shed some light? > > Jean-Paul > I think in python 2.x it's at least against the principle of least surprise. It should not behave differently. The behavior of python 3 though it's even against docs :-/ ___ 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] What this code should do?
On Fri, 19 Sep 2008 18:26:05 +0200, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: Hello Maciej, Maciej Fijalkowski wrote: Hello, I'm a little clueless about exact semantics of following snippets: http://paste.pocoo.org/show/85698/ is this fine? or shall I fill the bug? (the reason to ask is because a) django is relying on this b) pypy implements it differently) Note that python 3.0 has a different behaviour; in the first sample, it prints: A ( ... B (, ... See the subtle differences between http://docs.python.org/dev/library/sys.html#sys.exc_info http://docs.python.org/dev/3.0/library/sys.html#sys.exc_info The second example changes its behavior, too. It gives back the NameError from the exc_info call. I'm having a hard time reconciling this with the Python 3.0 documentation. Can you shed some light? Jean-Paul ___ 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] Code coverage
Hello all! The code coverage site at http://coverage.livinglogic.de/ was broken for the last few months. It's fixed again now and runs the test suite once per day with regrtest.py -T -N -uurlfetch,largefile,network,decimal Servus, Walter ___ 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] Unbound methods (was: ANNOUNCE: CapPython...)
"Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 2:15 PM, Mark Seaborn <[EMAIL PROTECTED]> wrote: > > Yes. The renaming of "im_self" and "im_func" is good. The removal of > > unbound methods is a *big* problem [1]. > > > > Regards, > > Mark > > > > [1] > > http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html > > I don't know to what extent you want to modify Python fundamentals, > but I think this could be solved simply by adding a metaclass that > returns an unbound method object for C.f, couldn't it? I have considered that, and it does appear to be possible to use metaclasses for that. It looks like CapPython could set the new __build_class__ builtin (on a per-module basis), which means that the verifier would not need to require that every class has a "metaclass=safemetaclass" declaration. However, there is a problem which occurs when CapPython code interacts with normal Python code. In Python 2.x, CapPython has the very nice property that it is usually safe to pass normal objects and classes into CapPython code without allowing the CapPython code to break encapsulation: * CapPython code can only use instance objects via their public interfaces. * If CapPython code receives a class object C, it can create a derived class D, but it cannot access private attributes of instances of C unless they are also instances of D. Holding C gives you only limited authority: you can only look inside objects whose classes you have defined. There are some builtin objects that are unsafe - e.g. open, getattr, type - but it is rare for these to be passed around as first class values. In constrast, class objects are often passed around to be used as constructors. Without unbound methods, normal Python class objects become dangerous objects. It becomes much more likely that normal Python code could accidentally pass a class object in to CapPython code. So if Python code defines class C(object): def f(self): return self._foo - then if CapPython code gets hold of C, it can apply C.f(x) to get x._foo of any object. I don't really understand the rationale for removing unbound methods. OK, it simplifies the language slightly. Sometimes that is good, sometimes that is bad. OK, there might occasionally be use cases where you want to define a function in a class scope and get back the unwrapped function. But you can easily get it via the im_func attribute (now __func__). One of the posts in the original discussion [1] said that removing unbound methods brings class attributes into line with builtin methods such as list.append on the grounds that list.append is list.__dict__["append"] is True. I don't agree: list.append already applies type check: >>> class C(object): pass >>> list.append(C(), 1) TypeError: descriptor 'append' requires a 'list' object but received a 'C' It has to do so otherwise the interpreter could crash. The check added by unbound methods makes class attributes consistent with these builtins. Removing unbound methods introduces an inconsistency. Also, what about the "only one way to do it" principle? If you want to define a function that can be applied to any type, there's already a way to do that: define it outside of a class. Regards, Mark [1] http://mail.python.org/pipermail/python-dev/2005-January/050685.html ___ 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] What this code should do?
Hello Maciej, Maciej Fijalkowski wrote: > Hello, > > I'm a little clueless about exact semantics of following snippets: > > http://paste.pocoo.org/show/85698/ > > is this fine? > or shall I fill the bug? > (the reason to ask is because a) django is relying on this b) pypy > implements it differently) Note that python 3.0 has a different behaviour; in the first sample, it prints: A ( ... B (, ... See the subtle differences between http://docs.python.org/dev/library/sys.html#sys.exc_info http://docs.python.org/dev/3.0/library/sys.html#sys.exc_info -- 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] What this code should do?
В Птн, 19/09/2008 в 17:43 +0200, Maciej Fijalkowski пишет: > Hello, > > I'm a little clueless about exact semantics of following snippets: > > http://paste.pocoo.org/show/85698/ > > is this fine? > or shall I fill the bug? > (the reason to ask is because a) django is relying on this b) pypy > implements it differently) It seems ok. The exception is raised in except clause and it doesn't handle by any except. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (09/12/08 - 09/19/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2035 open (+36) / 13696 closed (+24) / 15731 total (+60) Open issues with patches: 652 Average duration of open issues: 715 days. Median duration of open issues: 1793 days. Open Issues Breakdown open 2022 (+36) pending13 ( +0) Issues Created Or Reopened (60) ___ FUD in documentation for urllib.urlopen()09/12/08 http://bugs.python.org/issue3849created raz find_recursion_limit.py is broken09/12/08 CLOSED http://bugs.python.org/issue3850created pitrou patch, easy, needs review IDLE: Pressing "Home" on Windows places cursor before ">>>" inst 09/12/08 http://bugs.python.org/issue3851created serwy patch kqueue.control requires 2 params while docs say max_events (the 09/12/08 http://bugs.python.org/issue3852created ionel.mc Windows SQLite DLL should be built with multithreading enabled 09/12/08 CLOSED http://bugs.python.org/issue3853created ghaering easy Document sqlite3 vs. threads 09/12/08 http://bugs.python.org/issue3854created ghaering Windows installation did not work; tried on two machines 09/13/08 CLOSED http://bugs.python.org/issue3855created MLModel IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b309/13/08 CLOSED http://bugs.python.org/issue3856created MLModel ImportError: No module named test.test_support 09/13/08 CLOSED http://bugs.python.org/issue3857created wplappert make install tries to install files outside of --prefix 09/13/08 CLOSED http://bugs.python.org/issue3858created jjlee test_sys.Sizeof fails on win64 09/13/08 CLOSED http://bugs.python.org/issue3859created amaury.forgeotdarc patch GzipFile and BZ2File should support context manager protocol 09/13/08 http://bugs.python.org/issue3860created hagen distutils CCompiler._compile doesn't require lang keyword argume 09/14/08 CLOSED http://bugs.python.org/issue3861created ikelos test_array fails on FreeBSD7 amd64 09/14/08 http://bugs.python.org/issue3862created robrien patch 2.6rc1: test_threading hangs on FreeBSD 6.3 i386 09/14/08 http://bugs.python.org/issue3863created aimacintyre patch 26.rc1: test_signal issue on FreeBSD 6.3 09/14/08 http://bugs.python.org/issue3864created aimacintyre explain that profilers should be used for profiling, not benchma 09/14/08 http://bugs.python.org/issue3865created effbot int() doesn't 'guess'09/14/08 CLOSED http://bugs.python.org/issue3866created kjohnson What's New in 2.6 doesn't mention stricter object.__init__ 09/14/08 CLOSED http://bugs.python.org/issue3867created spiv patch for review: OS/2 EMX port fixes for 2.6
Re: [Python-Dev] What this code should do?
Maciej Fijalkowski wrote: Hello, I'm a little clueless about exact semantics of following snippets: http://paste.pocoo.org/show/85698/ is this fine? It looks right to me. :-) In the first case the NameError is caught by the except and not re-raised (but still enters the finally after the except block) and in the second the NameError is caught by the finally that does re-raise. What do you think should happen? Michael or shall I fill the bug? (the reason to ask is because a) django is relying on this b) pypy implements it differently) cheers, fijal ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ ___ 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] What this code should do?
Hello, I'm a little clueless about exact semantics of following snippets: http://paste.pocoo.org/show/85698/ is this fine? or shall I fill the bug? (the reason to ask is because a) django is relying on this b) pypy implements it differently) cheers, fijal ___ 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 documentation
+1. I find the offline versions to be vital. Sent from my iPhone On Sep 19, 2008, at 12:20 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin points out that in the past, as part of the release process, we've built separate downloadable documentation. Do we still want to do that for Python 2.6 and 3.0, and if so, how do we go about doing that? I have this feeling that building the documentation is much different now than in the past, and I don't really have a good feel for how it's done now. If you think we should release separate downloadable documentation and can help integrate that into the release project, you just might be a Documentation Expert . Please let me know if you can help. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSNOLBnEjvBPtnXfVAQIQnAQAm6thEThGufep6hzHxBwAN8MTsLb9jxsu Z8GAtX1bdMNOrJczYpU6by0oXPLR2pupnGV1YrAyQyoqpk+K7W8by5Qtg8+ZZcYH GerkqMVtNYn2zY1HhKigivp2JvlqIidRc5D36XS2EJixhZEPcOQDVm34THNQyRJT QasCQwdSAHI= =MbMY -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/python%40rcn.com ___ 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 documentation
On Sep 19, 2008, at 7:20 AM, Barry Warsaw wrote: Martin points out that in the past, as part of the release process, we've built separate downloadable documentation. Do we still want to do that for Python 2.6 and 3.0, ...? Yes, I think so. The downloads are very useful for people who regularly work disconnected from the public internet, or who are constrained by very small pipes. The PDF downlaods are also pretty important for the smaller documents, especially the tutorial. Many people want to walk away from the computer to read through that the first time. If you think we should release separate downloadable documentation and can help integrate that into the release project, you just might be a Documentation Expert . Please let me know if you can help. I think we should, but I'm hoping Georg has some ideas on how best to get the processes integrated. :-) -Fred -- Fred Drake ___ 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] ANNOUNCE: CapPython, an object-capability subset of Python
PyPy offers sandboxing interpreter without compromising language features itself. Here are docs: http://codespeak.net/pypy/dist/pypy/doc/sandbox.html Also, are you aware of directory Lib/test/crashers (in python's svn) which contains some possible ways to segfault cpython? (which can lead to compromise later) Cheers, fijal ___ 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] Python documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin points out that in the past, as part of the release process, we've built separate downloadable documentation. Do we still want to do that for Python 2.6 and 3.0, and if so, how do we go about doing that? I have this feeling that building the documentation is much different now than in the past, and I don't really have a good feel for how it's done now. If you think we should release separate downloadable documentation and can help integrate that into the release project, you just might be a Documentation Expert . Please let me know if you can help. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSNOLBnEjvBPtnXfVAQIQnAQAm6thEThGufep6hzHxBwAN8MTsLb9jxsu Z8GAtX1bdMNOrJczYpU6by0oXPLR2pupnGV1YrAyQyoqpk+K7W8by5Qtg8+ZZcYH GerkqMVtNYn2zY1HhKigivp2JvlqIidRc5D36XS2EJixhZEPcOQDVm34THNQyRJT QasCQwdSAHI= =MbMY -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