Mailman 3 March 2010 - Python-Dev

OOP On Web
by Pry, Jeffrey March 29, 2010

March 29, 2010

Hello, Nice to meet everyone! I have two files (class.py and object.py). Now, within object.py I create two objects from the class.py file. The class.py file contains the necessary code to make a connection to a FTP server. The two objects pass the credentials, etc. My question is, if I wanted to display a dropdown box on a webpage listing all instances of the object (most likely five servers), how would I do that. Would I do it at the class level, the object level, or at some other level. … [View More]

3 2

Why is nan != nan?
by Mark Dickinson March 29, 2010

March 29, 2010

[Changing the subject line, since we're way off the original topic] On Wed, Mar 24, 2010 at 7:04 PM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson <dickinsm(a)gmail.com> wrote: > .. >> If Python were to do something different then a naively translated >> algorithm from another language would fail. It's the behaviour that >> numerically-aware people expect, and I'd expect to get … [View More]

21 73

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Include/cStringIO.h Include/cobject.h Include/datetime.h Include/py_curses.h Include/pycapsule.h Include/pyexpat.h Include/ucnhash.h Lib/test/test_sys.py Makefile.pre.in Misc/NEWS Modules/_ctypes/callproc.c Modules/_ctypes/cfield.c Modules/_ctypes/ctypes.h Modules/_cursesmodule.c Modules/_elementtree.c Modules/_tes
by M.-A. Lemburg March 29, 2010

March 29, 2010

larry.hastings wrote: > Author: larry.hastings > Date: Thu Mar 25 01:54:54 2010 > New Revision: 79397 > > Log: > Backported PyCapsule from 3.1, and converted most uses of > CObject to PyCapsule. Backporting PyCapsule is fine, but the changes you made to all those PyCObject uses does not look backwards compatible. The C APIs exposed by the modules (e.g. the datetime module) are used in lots of 3rd party extension modules and changing them from PyCObject to PyCapsule is a … [View More]major change in the module API. > Added: > python/trunk/Doc/c-api/capsule.rst > python/trunk/Include/pycapsule.h > python/trunk/Objects/capsule.c > Modified: > python/trunk/Doc/c-api/cobject.rst > python/trunk/Doc/c-api/concrete.rst > python/trunk/Doc/data/refcounts.dat > python/trunk/Doc/extending/extending.rst > python/trunk/Include/Python.h > python/trunk/Include/cStringIO.h > python/trunk/Include/cobject.h > python/trunk/Include/datetime.h > python/trunk/Include/py_curses.h > python/trunk/Include/pyexpat.h > python/trunk/Include/ucnhash.h > python/trunk/Lib/test/test_sys.py > python/trunk/Makefile.pre.in > python/trunk/Misc/NEWS > python/trunk/Modules/_ctypes/callproc.c > python/trunk/Modules/_ctypes/cfield.c > python/trunk/Modules/_ctypes/ctypes.h > python/trunk/Modules/_cursesmodule.c > python/trunk/Modules/_elementtree.c > python/trunk/Modules/_testcapimodule.c > python/trunk/Modules/cStringIO.c > python/trunk/Modules/cjkcodecs/cjkcodecs.h > python/trunk/Modules/cjkcodecs/multibytecodec.c > python/trunk/Modules/cjkcodecs/multibytecodec.h > python/trunk/Modules/datetimemodule.c > python/trunk/Modules/pyexpat.c > python/trunk/Modules/socketmodule.c > python/trunk/Modules/socketmodule.h > python/trunk/Modules/unicodedata.c > python/trunk/Objects/object.c > python/trunk/Objects/unicodeobject.c > python/trunk/PC/VS7.1/pythoncore.vcproj > python/trunk/PC/VS8.0/pythoncore.vcproj > python/trunk/PC/os2emx/python27.def > python/trunk/PC/os2vacpp/python.def > python/trunk/Python/compile.c > python/trunk/Python/getargs.c -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://mail.python.org/mailman/listinfo/python-checkins [View Less]

5 10

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Include/cStringIO.h Include/cobject.h Include/datetime
by Reid Kleckner March 29, 2010

March 29, 2010

On Sun, Mar 28, 2010 at 3:25 PM, Larry Hastings <larry(a)hastings.org> wrote: > M.-A. Lemburg wrote: > > Just as reminder of the process we have in place for such changes: > Please discuss any major breakage on python-dev before checking in > the patch. > > > I'm aware this is a good idea. I simply didn't consider this a major breakage. Recompiling against the 2.7 header files fixes it for everybody. (Except external users of pyexpat, if any exist.… [View More]

1 0

Optional delta argument for assertAlmostEqual
by Michael Foord March 28, 2010

March 28, 2010

Hello all, A user has suggested an optional argument to unittest.TestCase.assertAlmostEqual for specifying a maximum difference between the expected and actual values, instead of using rounding. This sounds great to me as the default implementation of assertAlmostEqual has *never* been useful to me (YMMV). In fact one of the first things I do on setting up a test suite is provide a TestCase that overrides assertAlmostEqual with an implementation that uses a delta rather than rounding. … [View More]

6 6

Mixing float and Decimal -- thread reboot
by Guido van Rossum March 27, 2010

March 27, 2010

I'd like to reboot this thread. I've been spinning this topic in my head for most of the morning, and I think we should seriously reconsider allowing mixed arithmetic involving Decimal, not just mixed comparisons. [Quick summary: embed Decimal in the numeric tower but add a context flag to disallow implicit mixing of float and Decimal.] I tried to find the argumentation against it in PEP 327 (Decimal Data Type) and found that it didn't make much of an argument against mixed arithmetic beyond "… [View More]it's not needed" and "it's not urgent". (It even states that initially Decimal.from_float() was omitted for simplicity -- but it got added later.) We now also have PEP 3141 (A Type Hierarchy for Numbers) which proposes a numeric tower. It has an explicit exclusion for Decimal, but that exclusion is provisional: "After consultation with its authors it has been decided that the ``Decimal`` type should not at this time be made part of the numeric tower." That was a compromise because at the time some contributors to Decimal were fiercely opposed to including Decimal into the numeric tower, and I didn't want to have a endless discussion at the time (there were many more pressing issues to be resolved). However now the subject is coming up again, and my gut keeps telling me that Decimal ought to be properly embedded in Python's numeric tower. Decimal is already *touching* the numeric tower by allowing mixed arithmetic with ints. This causes the anomaly that Mark mentioned earlier: the three values 1, 1.0 and Decimal(1) do not satisfy the rule "if x == y and y == z then it follows that x == z". We have 1.0 == 1 == Decimal(1) but 1 == 1.0 != Decimal(1). This also causes problems with hashing, where {Decimal(1), 1, 1.0} != {Decimal(1), 1.0, 1}. I'd like to look at the issue by comparing the benefits and drawbacks of properly embedding Decimal into the numeric tower. As advantages, I see consistent behavior in situations like the above and more intuitive behavior for beginners. Also, this would be a possible road towards eventually supporting a language extension where floating point literals produce Decimal values instead of binary floats. (A possible syntax could be "from __options__ import decimal_float", which would work similar to "from __future__ import ..." except it's a permanent part of the language rather than a forward compatibility feature.) As a downside, there is the worry that inadvertent mixing of Decimal and float can compromise the correctness of programs in a way that is hard to detect. But the anomalies above indicate that not fixing the situation can *also* compromise correctness in a similar way. Maybe a way out would be to add a new flag to the decimal Context class indicating whether to disallow mixing Decimal and float -- that way programs that care about this can force the issue, while the default behavior can be more intuitive. Possibly the flag should not affect comparisons. There is one choice which I'm not sure about. Should a mixed float/Decimal operation return a float or a Decimal? I note that Fraction (which *is* properly embedded in the numeric tower) supports this and returns a float result in this case. While I earlier proposed to return the most "complicated" type of the two, i.e. Decimal, I now think it may also make sense to return a float, being the most "fuzzy" type in the numeric tower. This would also make checking for accidental floats easier, since floats now propagate throughout the computation (like NaN) and a simple assertion that the result is a Decimal instance suffices to check that no floats were implicitly mixed into the computation. The implementation of __hash__ will be complicated, and it may make sense to tweak the hash function of float, Fraction and Decimal to make it easier to ensure that for values that can be represented in either type the hash matches the equality. But this sounds a worthwhile price to pay for proper embedding in the numeric tower. -- --Guido van Rossum (python.org/~guido) [View Less]

15 87

Issue 6081: format string using mapping rather than kwargs
by Filip Gruszczyński March 25, 2010

March 25, 2010

Hello everyone, I was told to bring this issue to python-dev, but I was reluctant to do this until I was confident I can solve the problem. I have managed to provide the patch that works, so now I can talk about how this should be done, just as Eric told me. Here is the link to the ticket: http://bugs.python.org/issue6081. In the issue Raymond Hettinger proposed adding method to string, that would allow to explicitly pass subscriptable object, from which formatting of a string would be done. … [View More]

4 10

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Include/cStringIO.h Include/cobject.h Include/datetime
by Fred Drake March 25, 2010

March 25, 2010

On Thu, Mar 25, 2010 at 2:16 PM, Larry Hastings <larry(a)hastings.org> wrote: > My understanding is that requiring a recompile is okay This has always been a point of contention. I'm not even sure what the current official position is. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

1 0

PEP 3147, __pycache__ directories and umask
by Barry Warsaw March 25, 2010

March 25, 2010

I have a pretty good start on PEP 3147 implementation [1], but I've encountered a situation that I'd like to get some feedback on. Here's the test case illustrating the problem. From test_import.py: def test_writable_directory(self): # The umask is not conducive to creating a writable __pycache__ # directory. with umask(0o222): __import__(TESTFN) self.assertTrue(os.path.exists('__pycache__')) self.assertTrue(os.path.exists(os.path.join( … [View More]

17 66

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Include/cStringIO.h Include/cobject.h Include/datetime.h Include/py_curses.h Include/pycapsule.h Include/pyexpat.h Include/ucnhash.h Lib/test/test_sys.py Makefile.pre.in Misc/NEWS Modules/_ctypes/callproc.c Modules/_ctypes/cfield.c Modules/_ctypes/ctypes.h Modules/_cursesmodule.c Modules/_elementtree.c Modules/_tes
by M.-A. Lemburg March 25, 2010

March 25, 2010

larry.hastings wrote: > Author: larry.hastings > Date: Thu Mar 25 01:54:54 2010 > New Revision: 79397 > > Log: > Backported PyCapsule from 3.1, and converted most uses of > CObject to PyCapsule. Backporting PyCapsule is fine, but the changes you made to all those PyCObject uses does not look backwards compatible. The C APIs exposed by the modules (e.g. the datetime module) are used in lots of 3rd party extension modules and changing them from PyCObject to PyCapsule is a … [View More]major change in the module API. > Added: > python/trunk/Doc/c-api/capsule.rst > python/trunk/Include/pycapsule.h > python/trunk/Objects/capsule.c > Modified: > python/trunk/Doc/c-api/cobject.rst > python/trunk/Doc/c-api/concrete.rst > python/trunk/Doc/data/refcounts.dat > python/trunk/Doc/extending/extending.rst > python/trunk/Include/Python.h > python/trunk/Include/cStringIO.h > python/trunk/Include/cobject.h > python/trunk/Include/datetime.h > python/trunk/Include/py_curses.h > python/trunk/Include/pyexpat.h > python/trunk/Include/ucnhash.h > python/trunk/Lib/test/test_sys.py > python/trunk/Makefile.pre.in > python/trunk/Misc/NEWS > python/trunk/Modules/_ctypes/callproc.c > python/trunk/Modules/_ctypes/cfield.c > python/trunk/Modules/_ctypes/ctypes.h > python/trunk/Modules/_cursesmodule.c > python/trunk/Modules/_elementtree.c > python/trunk/Modules/_testcapimodule.c > python/trunk/Modules/cStringIO.c > python/trunk/Modules/cjkcodecs/cjkcodecs.h > python/trunk/Modules/cjkcodecs/multibytecodec.c > python/trunk/Modules/cjkcodecs/multibytecodec.h > python/trunk/Modules/datetimemodule.c > python/trunk/Modules/pyexpat.c > python/trunk/Modules/socketmodule.c > python/trunk/Modules/socketmodule.h > python/trunk/Modules/unicodedata.c > python/trunk/Objects/object.c > python/trunk/Objects/unicodeobject.c > python/trunk/PC/VS7.1/pythoncore.vcproj > python/trunk/PC/VS8.0/pythoncore.vcproj > python/trunk/PC/os2emx/python27.def > python/trunk/PC/os2vacpp/python.def > python/trunk/Python/compile.c > python/trunk/Python/getargs.c -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 25 2010) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ [View Less]

1 0