Re: [Python-Dev] Progress on switching Windows build to Berkeley DB 4.7.25...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trent Nelson wrote: | Hi all, | | Jesus, apologies that this has taken so long for me to get back | to, I've been completely and utterly swamped with client work the | past few weeks. However, thanks to a couple of hours spare at | Detroit airport yesterday, I was finally able to make some | progress on updating the Windows Berkeley DB build to 4.7.25. | I've checked in the work I've done so far to | branches/tnelson-trunk-bsddb-47-upgrade. One thing I wanted | to double check with you is the following change: | | Modified: python/branches/tnelson-trunk-bsddb-47-upgrade/Lib/bsddb/test/test_replication.py | == | --- python/branches/tnelson-trunk-bsddb-47-upgrade/Lib/bsddb/test/test_replication.py (original) | +++ python/branches/tnelson-trunk-bsddb-47-upgrade/Lib/bsddb/test/test_replication.py Wed Jun 18 06:13:44 2008 | @@ -94,7 +94,7 @@ | # The timeout is necessary in BDB 4.5, since DB_EVENT_REP_STARTUPDONE | # is not generated if the master has no new transactions. | # This is solved in BDB 4.6 (#15542). | -timeout = time.time()+2 | +timeout = time.time()+10 | while (time.time()= (4,6) : | | Basically, when using +2, the test failed every so often when running the entire test_bsddb3 suite. I picked 10 arbitrarily; it improves things, but it's still not 100%, I still encounter the following failure every so often: [...] | Can you comment on this? Yes. The problem is a race condition between the client and the server in the replication. If you have bad luck, the starting order will be reversed and the sync will fail... temporally. BDB Replication Manager has some configurable timeouts for reconnection, master election, etc. The right thing to do is to configure them in the right way. This work is already done in my SVN version. It will be in the 4.7.2 bsddb release. In the meanwhile, your workaround would be enough, although the test checking will be slower. My intent is to publish 4.7.2 as soon as I have a Python 3.0 compatible version. Hope 2-4 weeks from now. Less if I have help solving some ugly issues. | Apart from this small issue, the other 311 tests pass on x86 and | x64 with flying colours, so nice work, whatever you've been doing ;-) Nice to see the tests passing on MS Windows :-p. I'm a bit surprised, actually O:-). - -- 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 iQCVAwUBSIGrx5lgi5GaxT1NAQI6wQP/f3oDcbPfjHQa6YcSy8KH5DYk971eNMrl Phg0mDmy5XGgzMZArVEexVZTq1ykTBaqJ3S9hjM1RMcnNkTlB+pYS8zJxQ09psYA YDJDnSHzPDDhLsElTzfHs/nIKaAGyEnSpsm3RCdONCJgu0LGnsjgfTmyh2bBZNol IcAd/+dCMVU= =Mh4Y -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Removing bsddb module from py3k (was Re: [Python-3000] No beta2 tonight)
Josiah Carlson wrote: On Fri, Jul 18, 2008 at 11:03 AM, Fred Drake <[EMAIL PROTECTED]> wrote: On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote: It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. It's also entirely possible that the API isn't interesting if you don't support existing databases, for many applications. I see where the confusion was. I'm not suggesting that someone write a new bsddb module, I'm suggesting that we can provide something called, perhaps, on_disk_dictionary, which offers the behavior of bsddb, without using bsddb anywhere, or supporting bsddb files. No, I knew what you were suggesting, I just don't see the point in doing it. If an app depends on bsddb specifically, they can either stick with the 2.x series, or they can move to 3.0 and download the externally maintained pybsddb (modulo any additional licensing checks required by a company's contracts department) or they can switch to a simpler file-based database format like sqlite3. I'm not clear on what problem you are attempting to solve with the idea of a module with the bsddb API but without an actual bsddb backend. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Implementing restricted Python in Zope2
Shane Hathaway wrote: ranjith kannikara wrote: As a student I am not familiar with Restricted Python and python AST implementation.And in need of help to start the Restricted Python implementation. Here is some context for Python-Dev. RestrictedPython is a custom Python compiler that, when combined with a restricted environment, provides a sandbox safe enough to allow partly-trusted people to write and execute scripts on a Zope server. It has been used in Zope 2 for a long time and will have a future in Zope 3. The sandbox is more extensive than what the rexec module provides. The safety of RestrictedPython has been validated in a somewhat formal process with Python 2.4. Ranjith is working to validate it with Python 2.5. He is first working to discover all changes between Python 2.4 and 2.5 that might have affected the safety of a RestrictedPython sandbox. Any changes to the AST, builtin functions, methods of builtin types, etc., need to be evaluated for safety. As others have noted, Python 2.4 didn't really have an AST - it had a concrete syntax tree that it called an AST. Python 2.5 introduced an actual AST written in ASDL and the parsing and compilation process was rewritten on that basis. The most relevant areas of the source tree to compare are the respective Parser subdirectories in 2.4 and 2.5: http://svn.python.org/projects/python/branches/release24-maint/Parser/ http://svn.python.org/projects/python/branches/release25-maint/Parser/ The changes to symtable.c and compile.c in the Python subdirectory between the two versions are also highly relevant. There may be other changes of relevance, but even going over just the changes I mentioned should keep you busy for quite a while (I don't think there was too much of the old compiler left once the AST compiler went into the tree). It's easy to get a diff between files in the two versions using the read-only access to the SVN server: svn diff --old --new (e.g. using the two parser directory URLs given above). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fuzzing bugs: most bugs are closed
Hi, I filled 14 issues about bugs found by fuzzing (see my other email "Play with fuzzing" for more informations). Most bugs are now closed, cool :-) Last bugs: == Trivial open bugs == segfault on locale.gettext(None) - http://bugs.python.org/issue3302 - attached patch is trivial: fix the PyArg_ParseTuple() to block None value, and reject empty domain string for bindtextdomain() (to avoid strange error "OSError(0): success") invalid ref count on locale.strcoll() error - http://bugs.python.org/issue3303 - attached patch is trivial: add "if (rel1)" _multiprocessing.Connection() doesn't check handle - http://bugs.python.org/issue3321 - _multiprocessing.Connection(fd) doesn't check that fd is a valid file handle and so may crash on poll (the "evil" FD_SET() call) - my patch add "|| fstat(handle, &statbuf)" to make sure that the file descriptor is valid == Complex open bugs == block operation on closed socket/pipe for multiprocessing - http://bugs.python.org/issue3311 - close() method sets the file handle to -1 but most methods don't check the handle and so may fail or crash. Especially poll() calls FD_SET((SOCKET)conn->handle, &rfds); with handle=-1 => crash. - my patch creates a new MP error: "return MP_CLOSED_FILE;", used if handle is INVALID_HANDLE_VALUE to block operations (send, receive, poll) on closed files for socket and pipe. bugs in scanstring_str() and scanstring_unicode() of _json module - http://bugs.python.org/issue3322 - scanstring() function crashs if second argument is a big negative integer. There is no attached patch because I don't understand this function enough to fix it correctly, but I suggest to raise a ValueError if end is too small/big invalid object destruction in re.finditer() - or "PyObject_DEL inconsistency if pydebug option is used" - http://bugs.python.org/issue3299 - It's the most complex bug, I prefer to write a new email :-) == Need backport / port to python 3.0 == invalid call to PyMem_Free() in fileio_init() - http://bugs.python.org/issue3304 - patch applied in Python 2.6 (trunk) but not in Python 3000: "i'm assuming that'll be merged into py3k automagically." wrote Gregory P. Smith missing lock release in BZ2File_iternext() - http://bugs.python.org/issue3309 - patch applied in Python 2.6 but "Needs backporting to release25-maint." wrote Gregory P. Smith When all bugs will be closed, I will restart a fuzzing Python ;-) But I also tried with my patches and I was unable to find new bugs, great! Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem with PyObject_DEL in pydebug mode
Hi,
I filled an issue about the crash: "import re; re.finditer("a", {})"
http://bugs.python.org/issue3299
It appears quickly that the bug is specific to Python compiled in pydebug
mode, or to be exact: when Py_TRACE_REFS is defined.
== The Py_TRACE_REFS option ==
The problem is that PyObject_Del(obj) and PyObject_DEL(obj) don't remove obj
from the "object list" (_ob_prev and _ob_next attributes of all objects when
Py_TRACE_REFS is defined). And so obj will be reused later (maybe removed by
garbage collector? or something like that) whereas it's invalid (memory
freed).
PyObject_NEW(obj) and PyObject_NEW_VAR(obj) call PyObject_Init() which
registers the obj to the object list. So a developer can expect that
PyObject_DEL(obj) will remove the object from this list.
PyObject_Del(obj) and PyObject_DEL(obj) are used on object initialization
failure, but also in "dealloc" callbacks.
Classic object destruction is done by Py_DECREF(): when reference count is
zero, dealloc() is called. PyObject_Del/DEL are different because they just
free memory but don't call dealloc() whereas some attributes may be set (and
some other may be uninitialized or NULL).
== Solutions ==
(a) Replace PyObject_Del/PyObject_DEL by Py_DECREF to call dealloc callback
which will call PyObject_Del/PyObject_DEL. I prefer this solution because
dealloc is called and so we make that all attributes are deinitialized.
New problem: dealloc expects that the object is fully initialized (all
attributes are set and are not NULL), which is wrong is initialization fails.
Eg. with re module,scanner_dealloc() calls Py_DECREF(self->pattern); whereas
pattern attribute is NULL. Fix: replace Py_DECREF by Py_XDECREF. But all
dealloc have to be reviewed.
(b) Fix PyObject_Del/PyObject_DEL to remove object from the object list
(c) Create new macro which is PyObject_Del/PyObject_DEL + remove the object
from the list
(d) Never use Py_TRACE_REFS :-)
I wrote many informations in http://bugs.python.org/issue3299.
--
Victor Stinner aka haypo
http://fusil.hachoir.org/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fuzzing bugs: most bugs are closed
On Sat, Jul 19, 2008 at 7:23 AM, Victor Stinner <[EMAIL PROTECTED]> wrote: > Hi, > > I filled 14 issues about bugs found by fuzzing (see my other email "Play with > fuzzing" for more informations). Most bugs are now closed, cool :-) Last > bugs: > > > == Trivial open bugs == > > segfault on locale.gettext(None) > - http://bugs.python.org/issue3302 > - attached patch is trivial: fix the PyArg_ParseTuple() to block None value, > and reject empty domain string for bindtextdomain() (to avoid strange > error "OSError(0): success") > > invalid ref count on locale.strcoll() error > - http://bugs.python.org/issue3303 > - attached patch is trivial: add "if (rel1)" > > _multiprocessing.Connection() doesn't check handle > - http://bugs.python.org/issue3321 > - _multiprocessing.Connection(fd) doesn't check that fd is a valid file handle > and so may crash on poll (the "evil" FD_SET() call) > - my patch add "|| fstat(handle, &statbuf)" to make sure that the > file descriptor is valid > > > == Complex open bugs == > > block operation on closed socket/pipe for multiprocessing > - http://bugs.python.org/issue3311 > - close() method sets the file handle to -1 but most methods don't check > the handle and so may fail or crash. Especially poll() calls > FD_SET((SOCKET)conn->handle, &rfds); with handle=-1 => crash. > - my patch creates a new MP error: "return MP_CLOSED_FILE;", used if handle > is INVALID_HANDLE_VALUE to block operations (send, receive, poll) on > closed files for socket and pipe. > > bugs in scanstring_str() and scanstring_unicode() of _json module > - http://bugs.python.org/issue3322 > - scanstring() function crashs if second argument is a big negative > integer. There is no attached patch because I don't understand this > function enough to fix it correctly, but I suggest to raise a ValueError > if end is too small/big > > invalid object destruction in re.finditer() > - or "PyObject_DEL inconsistency if pydebug option is used" > - http://bugs.python.org/issue3299 > - It's the most complex bug, I prefer to write a new email :-) > > > == Need backport / port to python 3.0 == > > invalid call to PyMem_Free() in fileio_init() > - http://bugs.python.org/issue3304 > - patch applied in Python 2.6 (trunk) but not in Python 3000: > "i'm assuming that'll be merged into py3k automagically." > wrote Gregory P. Smith > > missing lock release in BZ2File_iternext() > - http://bugs.python.org/issue3309 > - patch applied in Python 2.6 but "Needs backporting to release25-maint." > wrote Gregory P. Smith > > > When all bugs will be closed, I will restart a fuzzing Python ;-) But I also > tried with my patches and I was unable to find new bugs, great! > > Victor Thank you Victor - I didn't want to change any underlying multiprocessing code until we had the test suite in a better state (which we do now). Now that beta 2 is out, I will address the multiprocessing ones asap. One suggestion would be to include tests to prove the bugs is fixed if possible (to the patch), so we can add them to the suite. I know that that is not always possible, but it does help. I worry about making code changes without appropriate tests. If anything, a snippet of code "exploiting" the flaw may help generate a test case on my end. Thanks again for doing this. -jesse ___ Python-Dev mailing list [email protected] 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] No beta2 tonight
On Fri, Jul 18, 2008 at 7:43 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: >> >> It's entirely possible that I know very little about what was being >> made available via the bsddb module, but to match the API of what is >> included in the documentation (plus the dictionary interface that it >> supports) shouldn't be terribly difficult. > > Maybe for new databases, but what about people with > existing bsddb files that they need to read? Classic data transition issue. Dump the data with the old software, reload the data with the new software. Both bsddb and sqlite are pretty fast, the latter of which has nice bulk inserts, after-the-fact index creation, ..., which can reduce the time it takes to do the transition. - Josiah ___ Python-Dev mailing list [email protected] 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] No beta2 tonight
On Sat, Jul 19, 2008 at 7:54 AM, Josiah Carlson <[EMAIL PROTECTED]> wrote: > On Fri, Jul 18, 2008 at 7:43 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Josiah Carlson wrote: >>> >>> It's entirely possible that I know very little about what was being >>> made available via the bsddb module, but to match the API of what is >>> included in the documentation (plus the dictionary interface that it >>> supports) shouldn't be terribly difficult. >> >> Maybe for new databases, but what about people with >> existing bsddb files that they need to read? > > Classic data transition issue. Dump the data with the old software, > reload the data with the new software. Both bsddb and sqlite are > pretty fast, the latter of which has nice bulk inserts, after-the-fact > index creation, ..., which can reduce the time it takes to do the > transition. After discussing with Guido off-list about how some companies have come to rely on deep features in bsddb, concerns that these companies wouldn't be able to transition away from bsddb, plus Jesus' picking up the code for 3.0 maintenance, I'm taking the offer to write a wrapper for sqlite off the table. Not because I don't think it could be done, but because no one seems to want what I'm offering (a 95% solution that doesn't require weeks/months of maintenance every release). - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing bsddb module from py3k (was Re: [Python-3000] No beta2 tonight)
On Sat, Jul 19, 2008 at 3:22 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: >> >> On Fri, Jul 18, 2008 at 11:03 AM, Fred Drake <[EMAIL PROTECTED]> wrote: >>> >>> On Jul 18, 2008, at 1:45 PM, Josiah Carlson wrote: It's entirely possible that I know very little about what was being made available via the bsddb module, but to match the API of what is included in the documentation (plus the dictionary interface that it supports) shouldn't be terribly difficult. >>> >>> It's also entirely possible that the API isn't interesting if you don't >>> support existing databases, for many applications. >> >> I see where the confusion was. I'm not suggesting that someone write >> a new bsddb module, I'm suggesting that we can provide something >> called, perhaps, on_disk_dictionary, which offers the behavior of >> bsddb, without using bsddb anywhere, or supporting bsddb files. > > No, I knew what you were suggesting, I just don't see the point in doing it. > If an app depends on bsddb specifically, they can either stick with the 2.x > series, or they can move to 3.0 and download the externally maintained > pybsddb (modulo any additional licensing checks required by a company's > contracts department) or they can switch to a simpler file-based database > format like sqlite3. > > I'm not clear on what problem you are attempting to solve with the idea of a > module with the bsddb API but without an actual bsddb backend. On-disk key -> value dictionary. In every use of bsddb that I've seen (or done myself), that's been the extent of it's use. That's what I *was* offering. But it seems that everyone has had experience with bsddb on a far deeper level (beyond dictionary + cursor access), and would find (like you) absolutely no use in an on-disk dictionary with a sqlite backend (which hasn't had the same maintenance issues as bsddb), which is why I withdrew the offer. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Removing bsddb module from py3k (was Re: [Python-3000] No beta2 tonight)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josiah Carlson wrote: | On-disk key -> value dictionary. In every use of bsddb that I've seen | (or done myself), that's been the extent of it's use. That's what I | *was* offering. But it seems that everyone has had experience with | bsddb on a far deeper level (beyond dictionary + cursor access), and | would find (like you) absolutely no use in an on-disk dictionary with | a sqlite backend (which hasn't had the same maintenance issues as | bsddb), which is why I withdrew the offer. For such a simple application, you can use the already in stdlib "gdbm" module. Just remember it is not transactional, so beware diskfulls, application crashes, etc. - -- 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 iQCVAwUBSIKXKJlgi5GaxT1NAQLmSQP+PEDrOy5AM6IRhIDFriyks0nTpA5a3vYi bgrVRNJYQXTkV43AFD0bUkDFT1VBsROSlSO0jEsSfHXG2FG51TJa7Hp1LCX62ryV H6NtztvqlA5OpTxEcWGPdha0XRueRwjYe/a+cVFXjAo+fXirlIac2W6ZhNJiAehg VP9lxrffQSM= =KV8P -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Change in repr of Decimal in 2.6
Karen Tracey wrote:
Yeah, but the testcases are not quite that simple. They're often
testing return values from functions and as much verifying that the type
is correct as the value, so I think I'd have to change stuff like:
>>> f.clean('1')
Decimal("1")
to:
>>> x = f.clean('1')
>>> print type(x), x
1
right?
>>> f.clean('1') == Decimal('1')
True
Since 'True' is a keyword, and Guido is *very* reluctant to even add
keywords, let alone change their spelling, I think you can depend on
that working indefinitely. Similarly, if you now have
>>> type(a)
you test will fail in 3.0 which instead prints '. But
>>>type(a) is int
True
will continue working.
Doctest has two quite different uses. One is to check text with
interactive examples to make sure there are no mistakes in the examples.
For that, printing representations is usually the natural style. Then
one must accept that representations change faster that object behavior.
The other use is to check code. For that, the more stilted style is
more future-proof. For text doing double duty as a formal reference and
code test, I would go for cross-version dependability.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python-2.6b2.tar.bz missing sig file on web site
Python-2.6b2.tar.bz missing sig file on web site. That's about all the info I have, except that the tgz is also missing the sig file, and that 3.0b2 has it's sig file. Hope this is the correct place to report this. ___ Python-Dev mailing list [email protected] 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-2.6b2.tar.bz missing sig file on web site
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 19, 2008, at 11:01 PM, Charles Hixson wrote: Python-2.6b2.tar.bz missing sig file on web site. That's about all the info I have, except that the tgz is also missing the sig file, and that 3.0b2 has it's sig file. Hope this is the correct place to report this. It is, thanks. Looks like I forgot to svn add those files. Please try again now. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSIK9KHEjvBPtnXfVAQLBdwQAok5D6yqAkfOEHjvq5YEVuOwnLLWz1UbV Y/bH6Q7lxnh4aIKJn2Mty82fLM7MpJQhF7zM+wLwLp2ilqgvRhZ1B9H8ykSErT23 Xpa7NAUzlxlL3Ca5r1jF7G10L+O46IpTz9+F1j5uvY1wXCjK9EP+HctpLzBRf6Hz ng6EyO/cfto= =nPmM -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Change in repr of Decimal in 2.6
On Sat, Jul 19, 2008 at 10:52 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >>> f.clean('1') == Decimal('1')
> True
>
Ah, yes, why didn't I think of that?
>
> Since 'True' is a keyword, and Guido is *very* reluctant to even add
> keywords, let alone change their spelling, I think you can depend on that
> working indefinitely. Similarly, if you now have
>
> >>> type(a)
>
>
> you test will fail in 3.0 which instead prints '. But
>
> >>>type(a) is int
> True
>
> will continue working.
>
> Doctest has two quite different uses. One is to check text with
> interactive examples to make sure there are no mistakes in the examples.
> For that, printing representations is usually the natural style. Then one
> must accept that representations change faster that object behavior.
>
> The other use is to check code. For that, the more stilted style is more
> future-proof. For text doing double duty as a formal reference and code
> test, I would go for cross-version dependability.
>
>
Thanks, I see your point about the different styles. I think we have a
fair number of tests that use the print-style (probably because that's
easiest, and then people see that style everywhere and do the same when
adding new tests) when to be future proof they really should be using the
alternative.
Karen
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
