Mailman 3 March 2010 - Python-Dev

OOP On Web
by Pry, Jeffrey 29 Mar '10

29 Mar '10

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. Forgive me if this is a somewhat basic question. Thank you for your help! Jeffrey Kevin Pry ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Why is nan != nan?
by Mark Dickinson 29 Mar '10

29 Mar '10

[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 complaints from >> those people if it changed. > > Numerically-aware people are likely to be aware of the differences in > languages that they use. Sure. But I'd still expect them to complain. :) Here's an interesting recent blog post on this subject, from the creator of Eiffel: http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civili… Mark

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 29 Mar '10

29 Mar '10

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

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 28 Mar '10

28 Mar '10

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. Google doesn't show any, though this is not proof that they don't exist.) > > If you suggest that any breakage with previous versions is worth mentioning, no matter how small, then I'll remember that in the future. Certainly the Python community has had many thrilling and dynamic conversations over minutae, so I guess it wouldn't be that surprising if this were true. I'm curious what is considered reasonable/unreasonable breakage. If this breakage just requires a recompile, then doesn't it just introduce an ABI incompatibility? Aren't those allowed every minor (point) release? Or do people believe that this is more than an ABI change? Reid

1 0

Optional delta argument for assertAlmostEqual
by Michael Foord 28 Mar '10

28 Mar '10

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. The implementation would be effectively: assert abs(actual - expected) < delta This has the advantage that it allows things like: self.assertAlmostEqual(timeStamp, expected, delta=datetime.timedelta(seconds=5)) The issue is this would make the signature of assertAlmostEqual (and its negative counterpart): def assertAlmostEqual(self, first, second, places=7, msg=None, delta=None) Note that delta comes after msg, which is different to other assert methods. To put delta before msg would be backwards incompatible with existing uses passing arguments positionally. In Python 3.2 we can make delta a keyword argument. Passing both places and delta would be an error (TypeError). Anyway, unless there are strenuous objections I intend to do this. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

6 6

Mixing float and Decimal -- thread reboot
by Guido van Rossum 27 Mar '10

27 Mar '10

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

15 87

Issue 6081: format string using mapping rather than kwargs
by Filip Gruszczyński 25 Mar '10

25 Mar '10

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. Two questions arise: 1) whether add such functionality at all? 2) how the method should be called? Should formatting options based on *args be kept (like using {0} in formatted string) or not and how argument should be passed. Eric suggested passing only mapping and only adding *args, if that is found useful by users; I have though about having both mapping and *args, which would keep it similar to the old formatting. Another option is to have *args and one keyword with the mapping (instead of kwargs). I would appreciate any advice on this topic, even if this ticket would be dismissed altogether, as I would like to learn as much as possible on practices on developing Python. -- Filip Gruszczyński

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 25 Mar '10

25 Mar '10

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 25 Mar '10

25 Mar '10

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( '__pycache__', '{}.{}.pyc'.format(TESTFN, self.tag)))) The __pycache__ directory does not exist before the import, and the import machinery creates the directory, but the umask leaves the directory unwritable by anybody. So of course when the import machinery goes to write the .pyc file inside __pycache__, it fails. This does not cause an ImportError though, just like if today the package directory were unwritable. This might be different than today's situation though because once the unwritable __pycache__ directory is created, nothing is going to change that without explicit user interaction, and that might be difficult after the fact. I'm not sure what the right answer is. Some possible choices: * Tough luck * Force the umask so that the directory is writable, but then the question is, by whom? ugo+w or something less? * Copy the permissions from the parent directory and ignore umask * Raise an exception or refuse to create __pycache__ if it's not writable (again, by whom?) Or maybe you have a better idea? What's the equivalent situation on Windows and how would things work there? -Barry [1] https://edge.launchpad.net/~barry/python/pep3147 P.S. I'm down to only 8 unit test failures.

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 25 Mar '10

25 Mar '10

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

1 0